>And when you have 50 small things? Or when the one small thing turns out to have been bigger than you thought, and you waste time trying to do the work that the engineers are probably more familiar with because one of them has been working on the same thing for months? Or when you have managing to do?
Well, of course a manager shouldn't make a small fix is managing work takes all the time. And the manager would make better time estimates and be familiar with the code if he actually did code 30% of the time.
>This is what design reviews are for.
I don't think they're sufficient, but do help. Kinda like reading code from a keynote describing a new language doesn't really make you learn it, it'll give an overview to 99% of people.
>I don't necessarily ride bikes over the years. But I understand it well enough to look at a bike and see how it works, or tell someone else where to go and how to ride it.
I agree with you. Note that if that bike is transformed into an airplane in five years, knowing how bikes work doesn't help much explaining how airplanes work.
>Like a manager?
Yes, I'm not against a person who is named 'manager' (titles don't really matter), but I think the manager should do some coding on the project.
>What 'rest of the time'? You mean when they're not fulfilling the first obligation you gave to them, which is managing work?
Yes, I mean that. A good manager will not micro-manager, and if the team is not huge and the organization is not flawed, there will be time for some coding.
>Why not just let them focus on the engineering? Why give them extra crap to do when somebody else was already tasked with managing the work?
It can be efficient. Often an engineer knows some managing work to do. If the engineer won't do the managing, he has to communicate the work to the manager. This communication takes time, which could be used to quickly do the small managing job.
>You can't automate managing work. That's why it's called "management". Because you have to do work to manage it.
Of course you can. Managing work has been automated a lot. Just because not all managing work has been automated doesn't mean it hasn't been automated. A lot of things that managers did 50 years ago are now automated. Hell, most experts had a personal secretary working under them just to make things work, because everything had to be done manually.
>Or because the organization is just big and the workload is high.
Yes, situations differ.
>Programming has not been "reinvented" in the last 40 years. It's pretty much the same, with some languages and tools re-addressing the same issues that were seen decades ago. Programming evolves, but so far it has never changed so much that an old programmer can't figure out what's going on with a new language or tool or system after looking at it for a while.
This is just arguing against rhetoric.
>When you're a manager, you don't sit in an ivory tower and stick your fingers in your ears and expect to know what the hell is going on. You are constantly reading documentation released from teams within the company and become aware of changes between releases, hopefully well before they come into effect. You can even set up and maintain a development environment to run unit tests to verify your application works, reviewing build reports, and so on.
Good. That may not be optimal.
>I think the reason so many people underestimate what takes up a manager's time is mostly they're people who never learned how to be a manager; they're often glorified team leads with the privilege to fire someone. It does a disservice to the people who have skills that don't apply to programming.
Your argument is "you're wrong because you're bad".