No, precisely the opposite should be said of engineers. Engineering is about reusing well-known techniques to achieve repeatable, predictable results whose timelines can be estimated. Engineering is not art. When civil engineers build new buildings or bridges (and I'm talking about your common building or bridge, not some iconic project), do they try to innovate and undertake to do things in some new-fangled way every time? No, because this would be extremely costly and dangerous and would render useless much of the past work that's been done testing materials and loads and so forth. When a method is known of constructing a bridge or an overpass that is both safe and economical, a good engineer should just keep doing that, with perhaps some adaption as appropriate on a case-by-case basis.

If software developers would stick with tried-and-true tools instead of inventing new frameworks to solve the same old problems and immediately obsoleting the "old" way of doing things each time, we'd have much less legacy code and likely would be much better at estimating software development tasks, and wouldn't have to solve the same problems over and over again.

You're right about traditional engineers whose work has been going on for quite some time now. We more-or-less figured out the "correct" way to build a bridge or an on-ramp or most anything physical and tangible.

However, your last point is not valid because you're under the fallacy we ever got the framework problem "correct". Who is to say that Django is better than RoR or visa-versa? Software is still a very new craft; you can't say that about masonry. Actually your fallacy stems even further. You're assuming software is predictable. There's degrees of predictability, but most programming starts out as a trek into the unknown. Sure, you might grab a familiar lamp like [Framework X] to shed light along the way, but really you don't know for sure what you're in for. If you did (or do), then you probably spent an insane amount of time spec'ing everything out perfectly. I have no problem with this, but there's even some dissonance between spec & code and the further out that spec gets, the greater the dissonance.

Software will always be kinda crazy in my opinion, but I reckon we're getting better with these agile approaches that embrace the unpredictability. In the TDD approach, you have to come up with tests first. This can usually give the programmer or architect a much clearer picture than "step 1: build web app" which will transfer over into their estimates.

If we stuck with tried and true we'd all be writing in assembly and Cobol. I remember what it was like in 1981, thankfully we continuously move forward. Building a bridge on the other hand is only barely different than the Romans in many ways.

Depends on what you mean by that, I guess. There is no such thing as software engineering. If there is software that can do what you want it to do, just use it. You don't need to build it again, like you'd have to do with a bridge.

I am currently developing something very new, and the road to where I want to go is plastered with new concepts I invented. Half of what I need to do is inventing new mathematics as well (in the form of making up new definitions, theorems, and proofs of these theorems) so that I know what exactly my software is doing.

Will a computer one day be able to do what I am doing? I definitely hope so. In fact I'd love to have a computer at my side right now that could prove this freaking theorem I am working on right now. I am pretty sure it is true, but I will need 2 or 3 more days until I am really sure. It would be nice if a computer could tell me in a second if it is true (or not), together with a proof.

No software ever does exactly what we want it to do, because we are all different and have different demands on our programs. Even the author of a program is usually never truly "finished" with their program, and always find new things to add or behaviors to tweak. That's why software engineering is a thing.

I'd guess at some point computers will become a literal brain prosthetic - instead of writing code by tapping words with your fingers, you'll have the cognitive enhancement offered by a programmable computing machine integrated directly with your conscious awareness.

Wow, ok then. What I love about the quote is the notion that a practitioner who is "great" can do something that no one has ever done before while acknowledging that you can be "good" with just the skills to re-do what has been done before.

I do separate in my mind engineers that can take a blank sheet of paper and create something completely new, and engineers can really only start from something that already is, or a close to what they want, and morph it into something else.

I think the opposite is true of engineers.