To go to an analogy, architecture or civil engineering. Not everybody can be a Frank Lloyd Wright, and more importantly there are lots more schools, mass produced suburban houses apartment complexes, highway overpasses and public restrooms that need to be designed than world class museums.
They don't need to be done with huge flourish or be terribly forward looking. They just need to be designed and built competently, not fall over and not have a leaky roof. There's nothing wrong with this state of affairs. Civilizations are largely built out of boring run-of-the-mill stuff.
Likewise, average developers don't need to build operating systems, or complex thread schedulers. They need to build the 30 foot boring overpass or utility box of the software world. And in many ways that's more important.
I agree with what you're saying, but there's a crucial difference: in software, the "boring run-of-the-mill stuff" can be automated. There's an interesting problem there, even if the application is macroscopically boring. If someone has a genuinely boring job (as opposed to an ill-matched job, or possibly a job not worth doing) then that indicates a lack of automation-- perhaps the programmer's fault (he's not skilled or courageous enough to do it) and possibly a manager's fault (for not budgeting time to do things properly).
That, I think, is the hardest thing about managing programmers, in which I include the increasingly important long-term job of managing one's own career. There are very few macroscopic indicators of what work is actually interesting (and more importantly, what projects fit which individuals).
If you asked me, at age 19 when I knew very little about software, whether it'd be more interesting to work on a game or work on an OS or a compiler, I'd have said the game based on the project's macroscopic attractiveness. Of course, most experienced programmers would prefer to work on the OS. If you're trying to hammer some C++ legacy garbage from another project into usefulness, the fact that it's "for a game" doesn't mean very much.
What I actually find is that there's only a very slight correlation between macroscopic and day-to-day "interestingness" in work (which is why it's so hard for managers to tell which projects are interesting). More important is the work environment-- whether you have the autonomy and creative control to solve problems in a decent way and make the work interesting.
I can see your point re: boring solved via automation.
However, there is still a tremendous class of software that can't (or hasn't yet been) automated e.g. boring enterprise integration mush, or accounting software, or whatever CRUD app the company needs to meet xyz goal for the year.
Sure there have been some efforts to automate or semi-automate some of this but the solutions are often more cumbersome or boring than the original. There are probably tens of millions or lines of code written for this kind of stuff every year.
Sure if you look at a high-enough-level most of these look like the same thing (and thus easy to automate) -- CRUD apps basically. But the truth is that this just hasn't happened yet because the devil is in the often excruciating details.
The developers who end up doing this kind of work do critical stuff, it's the equivalent of building a working sewage system in a growing city, not sexy but utterly critical. No amount of programmer astronauts are going to keep the poop flowing away form the population.
Still, if anybody could solve that kind of boring software development (something that can't be done with sewage systems), it'd be a multi-billion dollar company almost overnight.
They don't need to be done with huge flourish or be terribly forward looking. They just need to be designed and built competently, not fall over and not have a leaky roof. There's nothing wrong with this state of affairs. Civilizations are largely built out of boring run-of-the-mill stuff.
Likewise, average developers don't need to build operating systems, or complex thread schedulers. They need to build the 30 foot boring overpass or utility box of the software world. And in many ways that's more important.