Isn't the bane of human existence the realization of how clueless we were 5 years ago and blocking out the realization that we are currently clueless compared to our 5 years in the future self? Of course if you are not, that means you won't learn anything substantial in the next 5 years.

I assume that open source has removed some of the demand for great documentation. If you need that last bit of information, they probably expect you to open the source code. When that wasn't an option, the documentation was essential.

Dave B

Why does it have to be one or the other? One class could model a physical object like a car while another could model an operation such as a database transaction, file operation, or something more complex. At the end of the day it is about using the tools to minimize the cost of solving problems. And concepts like encapsulation and polymorphism frequently are the best tools for the job.

If you are choosing to spend the opportunity cost of reading books that don't improve your ability to show value to your current or future employer, then your destroyed career wasn't the decision to read, it was your choice of what you read.

What an interesting thread. I investigated these technologies many years ago and am surprised by how little has changed based on the responses provided. After thinking through why, I speculate that the only two potential reasons are that either the solution space has been perfected OR the demand for the service was waned. Based on the responses to this thread, I don't think it is because it has been perfected. It having waned makes perfect sense since there are far fewer places where anyone needs or wants paper. But clearly you found a few. Thinking through how I would solve those scenarios without using a hated report writer, I might create a domain specific solution if applicable. Have you considered a document editor, such as MS word, that either supports templating out of the gate, provides an "addin" infrastructure where you can perform your own template application, or uses a file format that can easily be modified programmatically to insert data from the source into template fields. Modifying and printing a document where the format can be changed by the author using tools they already know how to use might be appreciated. Of course this ignores the entire specification of the datasets the reports are run against. But if those are fixed or can be controlled in another manner, then this might work out.

My personal opinion for coding or any heavy review/typing is a split keyboard. I use the KinesisGaming and it has been an amazing improvement. The next level up of split keyboards are at a price point beyond what I am willing to spend at the moment. Although, editing outside of an editor that allows the use of JKHL and other shortcuts probably should push me to go next level. Reaching for those arrow keys is like slamming on the breaks at 90 miles per hour. Shortly after I improved my development speed significantly by not using the mouse for anything other than casual use of the computer or an editor, the realities of the strain on the body of holding your hands together on a keyboard for extended periods of time started to kick in. This basically restores the physical strain to that of someone who keeps their left hand on the keyboard and their right hand on the mouse 90% of the time.

Without more context, it is hard to know if your boss was correct or if you were correct in this instance. IMO every project needs to be tailored to its audience and the answer as to if step by step dialog boxes are applicable will vary greatly depending on the audience, the frequency a user will use the UI, and the learning curve just to name a few factors. Who I can say is most often wrong is the person who believes there is always a specific way to do something such as "always create a step by step dialog experience" or "never create a step by step dialog experience". And frequently more junior developers who don't yet have the lay of the land are more likely incorrect by following some "basic rule" someone previously taught them (or they developed) without educating them on the required context for the rule to apply. A good example in this case is the interview step through UI in Turbo Tax. For those of us who fill out a tax form once a year, this is a great interface. Imagine though if you worked at H&R Block and you filled this out every 30 minutes for 8 hours a day. That would be a horrible interface. Same job, same information, different user.

You:

... but at managers who read only "industry news" and blogs and watch videos and attend conferences so they can then return to their flocks and extoll the latest piece of rubbish as the ... ... When mostly, we're better off using the tried-and-true tools we're used to.

Until you are not better off using the tried-and true tools. Doing things as you used to (a.k.a. if it ain't broke, don't fix it.) leaves you susceptible to being wiped out as exponentially more efficient ways of accomplishing the same task are developed and being used by your competition.

Me from before:

Even worse, with so many tools out there and the true cost/value/issues only being truly known once YOU invested the time to learn the tool, we tend to "follow the herd" or an authority, which also allows us to be manipulated into acting outside of the best use of our time.

In your opinion, what's a manager to do?

I think the biggest problem here is that we tend to: - Assume we are the target audience that the tools we try to use were built for. - Assume anything we don't understand about why it works the way it does must be a flaw with the creator and not our understanding of the use cases and issues the tool was built to address. (i.e. in this case, the security of running a default application from the current path) - Assume that whatever we currently know should be sufficient to maximize productivity, or at least be efficient, with most tools we try to use. Those that have familiarity with a tool and are already 10x the speed of a newer (non vested) user are constantly demanding features and enhancements to gain another exponential 10x that you will likely not ever get to as a "casual" part time user of a tool. Each addition adds complexity, learning curve, and the likely failure to adopt a tool of new users. A tool that intentionally limits its complexity for new or casual users does so knowing that it is capping the productivity of its power users. In the end, you can't "win" (win = your stated desire) unless you find tools meant for exactly what you require now and in the future, that contain little more and little less than you need, and that have minimized all complexity beyond YOUR requirements. And there needs to be enough of you to justify the creation (AND MAINTENANCE) of such a tool. i.e. the value obtained must significantly justify the learning cost. Even worse, with so many tools out there and the true cost/value/issues only being truly known once YOU invested the time to learn the tool, we tend to "follow the herd" or an authority, which also allows us to be manipulated into acting outside of the best use of our time. And the true cost is not if you know the tool. It is the cost of making sure that everyone on your team now and in the future knows the tool in addition to the other tools they must know. In the end, specialization, massive dedicated learning in your specialization, teaming with other specialists, and understanding the true cost of fad tools and frameworks may be the best way to "win". But who wants to be dependent on someone else?

Dave B

I think you already have some good answers here. The following are my general rules for this sort of situation. No code, string, or logic that ever needs to be kept in sync should ever be duplicated via copy and paste. It will get out of sync if you do. And trying to keep it in sync will drive up the cost of the development/debug cycles despite the "increased complexity" of someone updating a single pasted copy. To facilitate this, apply the following in order: When 'magic strings' are required, they are put into constants and referenced so one can't be changed without breaking compilation. If you KNOW that you are only going to have 2 or 3 versions of whatever you are maintaining, simple if then else logic is perfectly fine as you haven't violated the primary rule of not duplicating any code/logic/markup that needs to be kept in sync and more importantly in all likelihood, you want a future developer to consider the impact on the other uses of the logic rather than being able to ignorantly get things out of sync by updating one form and not the other. When code can be placed in a function and effectively called from each required location, do this. When composition/aggregation can be used to capture the logic into a reusable component, do this. When the above are not possible, consider inheritance and/or a metadata driven approach. NOTE that all of these rules only apply assuming you are coding in a language that can be compiled or linted (well), such as a traditional language (C,c++,java,c#,Typescript,...), annotated python, ... These would not ALL apply to vanilla JS, non-annotated python, lua, or other similar languages that only break at runtime and require developers to create tests to replace what a compiler and linter mostly does for a good code base. Further, they assume that performance is not a concern.

Dave B

A lot has changed since the 80s. That is when I started college also. Some things are easier and some are more difficult. And not all programming positions are equal. Many get by by learning the syntax of HTML5, Javascript, Typescript, CSS, and SASS and then a popular framework like ReactJS or Angular and find happy lives grinding out web applications. Much of this type of developers time gets sunk in learning the latest framework, as the frameworks don't tend to last very long, and then rewriting/updating their code as frameworks and dependencies change in uncontrollable manners. While I tend not to trust developers who are self taught or come from a boot camp, it is primarily because most I have worked with tend to learn their trade skin deep, don't know what they don't know, and don't learn better ways to do something unless they become aware that they way there were doing it will not be supported any longer or is not trendy. That being said, this distrust is primarily because of what self taught & boot camp programmers tend to focus their learning effort on. At some point all of us are self taught since these technologies are constantly evolving. How you teach yourself if what is important. If you want to fully learn this technology stack (for the front end), might I suggest starting with: Learn web development | MDN[^] and once you have exhausted what mozilla has to offer on these sets of technologies, you should move onto RFCs to hopefully be one of the self taught people who know the technologies from the bottom up and not only by being able to replicate what they have seen in a tutorial or in a google search. If you go this path, you should make sure you use Typescript. An alternative path that also costs you nothing, outside of the cost of a book in some cases, that will allow you to see if you still have what it takes to get into more serious computer science topics is to take advantage of OCW at: Electrical Engineering and Computer Science | MIT OpenCourseWare | Free Online Course Materials[^] Here you can "take" the same classes that bright young students accepted to MIT take to enter this field. Based on the amou

Yes, Associates Degree.

While I agree with other commenters that you won't get anyone good with any experience for that price tag, you might try hiring a recent high school graduate that went to vocational school (Technical Education) for programming and expect to direct him to self train on VB.net and take some of your time learning to code. Not to put a damper on your ideas, but we just had to pay 120K for someone with an AD who tested extremely well and so far seems very bright.

Dave B

Nagy Vilmos wrote:

The ticket has been reopened as "the user doesn't want to change their workflow"...

In my experience, you should always question the "game of telephone" between yourself and 'the user'". In an organization of even a meager size, especially if there are multiple "support groups" in "multiple organizations" between the end user and the "developer/product designer", then both ends have a good chance of getting bad information. The end user and the developer/designer typically understand the nitty gritty details of the job, issues, and potential solutions and everyone else has a skin deep understanding. That lack of in depth knowledge causes the links in the telephone chain to miscommunication information and insert their own ignorant perspective to "help" the situation along having no idea the damage they are causing. Then again, your project is just one of 10 those "helpers" with skin deep knowledge are probably handling and can't justify the time to get the in depth knowledge you can.

honey the codewitch wrote:

So if anything it seems a matter of education? Knowing what C++ will generate and what it won't.

Perhaps this is the biggest issue. The level of knowledge one has to earn to know how to make the compiler generate what they want and even more importantly, know what the compiler will generate when reading someone else's code. This knowledge has a cost (potentially a high cost) that needs to be maintained by the organization through the expense of time and paid experience of every developer reading or maintaining the code. That expense must be offset by the reduction in cost of using C++ features that eliminate writing boilerplate code and organizing code. I suspect with the far simpler rules/capabilities of C code, you have to look at a lot less code you didn't write to understand exactly what it is doing without resorting to using a debugger or looking at assembly. My current opinion is that the decision of C versus C++ would come down to the project size and the pool and expense of developers you want maintaining the code. Imagine a "C++ developer" jumping into a project that required diagnosing a set of code that used partial and full template specialization a few levels deep and being asked to refactor it. Could they do it? The statements "I know C++" and "I know C" carry two different levels of trust. I would trust most people who claim to know C and I can easily test their knowledge. With C++, the question for me becomes, what parts of C++ do you know and how well do you know each?

Dave B

I think effectiveness has to come down to how an older developer spent his career and the base knowledge they started with. Knowledge turnover in this field is extremely high. Understanding the core principles allows one to gain further knowledge more effectively. Where those who learn formulas to work with a technology that will become obsolete within 5 years are in trouble from day one. (i.e. boot camp and problem based self taught victims) The vast amount of knowledge required to truly be effective and make critical design decisions spanning many technologies takes years to acquire. And this may be a point where your interest and your employer's interests diverge. They need you to get the project done and know an investment in you may not be around in 2 years. You have a future you need to protect. So it is easy to see how so many would become stranded. So an older developer who learned how to "work in a technology" that has become obsolete and did not aggressively acquire new skills and knowledge is in serious trouble when you consider the impact of life, family, and degeneration. Degeneration also varies greatly based on ones attention to exercising ones mind. On the other hand, one who started with a good foundation and aggressively fed their knowledge is probably in a position to "out develop" 30 "new kids" based on the ability to make proper decisions and not waste time hunting for information or going down bad paths due to a lack of experience. In essence, there is no "standard" for effectiveness over age. It depends on the individual. Then again, those who are hiring might have their own personal agenda also based on how the new hire will impact their own future. Make sure you are an asset and you will never have anything to worry about.

Dave B

I am actually implementing a production application in Blazor with an ASP.NET core backend. All of our previous web development was done in Angular with some large typescript libraries we developed. The iteration time to make a change in your source code, rebuild it, and then restart your test from scratch in the browser is very painful. They claim to be working on this, but as far as I know, it is not done yet and I question how much they will be able to accomplish. The workflow with angular using typescript and a development server is much faster and quicker to iterate on. To circumvent some of this, we have created a complete POC html only application first to get the layout of what is required and then just mapping that HTML into the Blazor application so that we are never iterating on the SASS or HTML of the application within Blazor. I think they will have to move the compiler to the browser to accomplish this and then handle incremental compilation. Another issue, that I have to admit I don't fully understand what they can do about it yet, is the download. As I understand it, you are downloading a version of the .NET runtime meant to run inside of WASM and then downloading all of the assemblies that your application uses. MS claims to be working on a way to remove the unneeded parts of the application kind of like the linker does in a native build. I have been developing in .NET for some time, and because so many of its patterns are based on reflection, it can make getting this removal of only the parts you are actually not using after reflection is taken into account very tricky. I suppose they could dictate an attribute of what not to remove. I am not 100% up to speed on their efforts to remove the unused parts of the application. So perhaps they have some interesting tricks up their sleeves. One of the reasons I almost always desire compiled languages over interpreted ones is that the compiler eliminates many bugs and wasted test cycles. I have noticed that many times my razor files will compile, but fail at runtime due to an issue I feel the compiler should have caught. I believe Angular and Typescript did not have this issues especially if you did a complete build. This makes me a little less happy about Blazor. On the positive side, the C# experience, dependency injection, and type safety that C# developers have become accustomed to are all in tact (if you ignore the .razor files). And once the application is downloaded, it is lightning fast in its execution. The robustnes