I am curious, is this a common and similarly frustrating experience for non-programmers? Are managers of, say, car technicians or accountants just as clueless about their subordinates?
In my experience no, but that doesn't necessarily mean they were better managers.
The specific problem with programming is it's pretty much invisible - the end result, when well done, hides the enormous levels of complexity it takes to create it. It's just 'another website' or whatever.
That's compounded by the problem that, in the U.S. at least, managers seem to think their job is having influence/power over people, and telling them/making do things. In fact, management is supposed to be a support role. Managers should be creating an environment that enable their employees to do their job as best as possible.
In my experience -many- managers exist to please the person above them, and think very little (or, at best, simply are unable to see) how their actions effect their employees happiness and productivity.
Having worked in the service side of a BMW dealership, the service manager there was a tech who got promoted into the position. He was the go-to guy whenever there was a hard technical problem to solve. Some companies Do It Right, others don't.
A friend of mine is a pipeline engineer, and he said all their middle management (his boss, his boss's boss, and possibly higher up) are mostly promoted from engineers.
Their team lead is generally the most experienced/capable person on the team.
As I read these comments, I was imagining a non-technical supervisor sitting down a programmer on a relatively small project to learn how their work is done, from start to finish. The project should be short enough for the manager or like person to see it completed over a few sessions, including the overview, the draft, and the testing and problem-solving.
The programmer would explain the goal of the new project, like so: "We need to design a module that talks to the what-what the customer is using. It has to do three things: it must take an order from the what-what, then perform the appropriate action, and finally receive information back from the central system."
"So, we begin with the first part of the module: the part that will take an order from the what-what. It needs to listen for a message from the unit the customer is interacting with. Then, it needs a rule concerning what to do with each order, that is, what instructions to follow."
Once the basic form and actions of each section are established, then he or she can explain in more detail the actual working parts: "Now we need to step through the list of orders. With each order, we will check our rule set and perform the appropriate action. Once there are no more orders, we will tell the computer (or program) we are finished and it can proceed to the next step, which is receiving information back from the central system."
Throughout, the programmer only needs to explain conceptually the work he is doing: Even the difficult or intricate concepts (details of network connections, perhaps) he may illustrate. The details of the actual programming language do not need to be explained for this purpose. (That is, he does not need to say, "Now we write 'Blob userOrders = new (Blob)' to create a new blob", or "We will receive the orders from the customer into an array ("What's that?") and step through them with a 'for' loop.") He or she might use a pen and paper to draw a diagram of the module as they design it.
Once the manager has the overview of the system and knows how it is supposed to work, perhaps they can follow the writing of tests for it: "We will send it some simple test orders to see if it follows them correctly....And now we will give it an illogical order--did we check for a bad order?"
Finally, the manager or supervisor can join the programmer as he or she goes back to the code to identify the source of the trouble. (More details could be added here.)
The programmer does not need to oversimplify, but as they go deeper into the project together, the programmer can explain more technical details. Previously, these details would have been distracting, overwhelming, or incomprehensible to the the person they are teaching, but now they enable them and are necessary to see what the program is doing at this level, and why the problem occurred as it did.
Could this be a realistic scenario, in certain cases at least?
"Could this be a realistic scenario, in certain cases at least?"
No, the supervisor's primary motivation is to avoid blame while gaining power. If they know how everything works, there is no deniability when their plan fails. The game they play is to promise the impossible to their bosses in hopes of promotion and blame the 90% that didn't go to their plan on the programmers while trying to take full credit for the 10% that was pulled off by heroic coding. To this end, no supervisor will be caught in a 'code' conversation. If they understood software engineering they would be on the hook for the 90% as well.
Where an honest supervisor needs to learn the fundamentals of software engineering is at the school and then later as a software engineer. You can get a BS in software engineering in many places and go on to obtain a Masters in technology management. Also work 5-10 years in deliberate practice as a software engineer. There is no 'sit down for an hour and learn software engineering' just like there is no 'sit down for an hour and learn how a nuclear reactor works'. What you are talking about is remedial training, but none of these guys would go for it. Their philosophy is that people willing to do technical work are simple fools to be exploited. Usually they are very glib about the idea that they skipped all the hard technical stuff.
