IT is not a factory, it builds factories.
I believe a lot of developer/management conflict stems from a lack of terms for what we call manager. A McDonald’s manager supervises employees to ensure they’re following a process that produces a product. Failure to adhere to the process is obvious, the process is assumed to be valid as a given, and failure to produce the outcome is obvious.
Whereas a programmer is employed to develop processes that a machine will follow. A manager over this employee may have a process for the programmer to follow, it may be obvious whether this programmer is following the process, but it is uncertain if the process is valid and will connect specific actions to prescribed outcomes and the outcomes themselves may be non-obvious.
But we call both people in these roles “managers”, despite them being very different.
Programmer, in this machines analogy, is a different type of manager. One that presides over machines, and not people. But these machines are turned loose on the world, left to their own devices and not watched over by the programmer.
This is either profoundly insightful of absolute bollocks, but I don't think I'll be able to tell which before the next 5 years.
However this doesn't mean this notion isn't possible absolute bollocks, as another commenter suggested, just that someone else will join me in embarrassment if I realize this is silly in a few years... which is better than being embarrassed alone!
Programming isn't work, it's meta work, you come up with a list of instructions once, and then the computer does the work 24/7 indefinitely. Meanwhile you go on to write another set of instructions for something else. If you ever write the same set of instructions more than once, you're basically doing it wrong. So it's hard to know how long things will take, because you're always doing something new. You never do something more than once.