The best managers are the ones who know they don't know how to do your job so they get out of your way. The worst are those who don't know how to do your job and get in the way. Those who know how to do your job at least don't get in the way when they help.
Hm, not sure. My first boss 'managed' by assigning tasks to people and recording start/finish date in an Excel sheet. Multiple week projects were the same as one-day fixes of they made it on to the sheet. I was 'managed' by having my task completion times compared to 15yr developers, and given no feedback other than to work faster.
We also had a lot of slowdown because we were stuck on a shitty off-the-shelf program he bought. He went for this one instead of the more usable competitor because it was cheaper. If he could get developers to build a working tool in the cheap product by holding them 'accountable' in his Excel sheet, he could push for the product to replace the more expensive competitor and gain some reputation in the corporation.
In the end, most of the project was a horrific failure. His best employees left, and control of the project was transferred to another manager inside of a year or two.
I think a lot of this could have been avoided if my boss had any idea about what he was managing.
It doesn't matter. What matters is success. A good developer will be more successful in the marginal projects, and cheaper in the very worthwhile projects, but that is just a matter of dollars on the bottom line. The best developer in the world cannot save a stupid idea. The worst developers just ups how insanely profitable, and how long he need to wait a project must be before it is successful.
The above assumes a single developer. If you have a team of developers it quickly becomes obvious. In fact a boss who knows nothing about programming is probably better able to judge if someone is doing a poor job in these cases: those who know the new guy see him trying to get up to speed, while the boss sees a bigger picture by comparing to others. (a good developer will be making useful contributions on the second day, while a bad one will flounder for a couple weeks before the others will give up on teaching him the project)
>If you have a team of developers it quickly becomes obvious. In fact a boss who knows nothing about programming is probably better able to judge if someone is doing a poor job in these cases
I've been on such teams and that isn't what happens. This is:
* Team mates do not like badmouthing their coworkers unless they do not like them. Hence, if a coworker complains about another coworkers' performance its as likely to be due to a personal problem as it is performance. Most coworkers also won't know each others' wages so they are in an even poorer position to judge relative performance.
* Managers without technical chops are incapable of distinguishing hard tasks from tasks that are being done badly or easy tasks and tasks that are being done well. They are incapable of distinguishing quality engineering from hackjobs that will blow up in 6 months. They will either default to just assuming every developer is more or less equally productive or use terrible proxies for productivity (like how late each developer stays at work or their scrum 'velocity').
* Good performers who do not have their achievements recognized will leave for better paid positions, leaving mediocre and poor developers. The quality of the product takes a dive. Profitability may also take a dive as a result if the industry is competitive and the quality of the software matters.
