I disagree. Great engineering is when you propose and implement (or lead a team implementing) a complex, novel and valuable piece of engineering. Linus is a great engineer, key people working on database systems are great engineers etc. What you're describing is "just" competent engineering.

Most engineering problems aren't up the engineers to invent or propose. What you're describing sound more like product design. A lot of companies face a problem such as "We need a bridge an we have X money for it". The engineering is in meeting spec with those constraints. The great engineering is doing that and not baking in a hidden cost of support, maintenance etc.

In civil engineering world, great engineering would be proposing a novel design of a bridge (for example, a first large bridge built out of steel) and delivering it. Of course, most situations don't require novel designs, you just need competent implementation of something that is an industry standard.

In software world, you can also satisfy 99.9% of cases with existing approaches. You mostly don't need great engineers for that.

> In software world, you can also satisfy 99.9% of cases with existing approaches. You mostly don't need great engineers for that.

Unlike other engineering disciplines, software has a constant pressure for pseudo novelty and fad adoption. One dimension of "greatness" is resistance to those temptations and pragmatism in the face of constant change. In that regard, lower quality engineering talent often correlates with increased tech churn and defects, even given a simple business domain.

Tl;Dr engineering excellence doesn't only imply innovativeness, it also implies discipline.

In other words: Systems that do things simply and directly are great, and often exciting, technology.