> The ratio of software engineers working in novel design spaces compared to plumbing style work is best guess ~1:5

Google has something 25,000 developers. You think Google has 5,000 people working on novel design spaces? That number sound way, way too high. By at least an order of magnitude.

And Google at least has customer facing technology compared to the thousands of companies whose developers only work is, say, integrating HR systems or deploying SAP or maintaining some legacy billing system.

> You think Google has 5,000 people working on novel design spaces?

Yes.

Maintaining a bridge is in general not novel. There are clearly established best practices that have stood the test of time.

Maintaining a ridiculous tangle of millions of lines of code is novel. There are no best practices on par with other engineering fields. We are at the stage of rough heuristics in most parts of software dev.

One day there will be broad and consistent over time agreement on how to handle large software projects. But we aren't there yet.

IBM's S/360 was millions of lines of code in the 1970s. Managing millions of lines of tangled code is not novel. It is older than most HN readers.

Novelty is a byproduct of immaturity. To take another field that matured recently, mechanical and in particular aerospace. You can see a lot of crazy airplane designs from the 1920s through the 1940s. There was a lot of novelty back then and it was an exciting field to work in. Now airplane designs look very standard, and for good reason. The field matured and figured out the best and most economical designs. Novelty is a temporary state, and most novel designs are figuring out how not to do things.

You're mistaking complacency and lack of innovation for maturity.

Very few software engineers are working in novel design spaces. Even 1:1000 is probably being generous. FWIW, this is true of conventional engineering too, but even more so.

A software engineer having no idea how to build something doesn’t make it novel, it just indicates inexperience or ignorance in all but a vanishingly small number of cases.

In practical systems, you won’t find much novelty outside the rare frontiers of performance optimization, systems software architecture, the occasional bit of weird silicon with unusual computational properties, and some narrow algorithm domains that have never been adequately developed e.g. compression and AI. Almost no software development can justify even thinking about these types of things and they virtually never do.

Conventional engineering is worse because the laws of physics constrain almost everything to boring well-explored solutions. In some cases, we’ve pretty much done exhaustive exploration of what is possible.