Skimmed through, and it sort of confirms my own experience: when a problem isn't approached with an engineering mindset, the resulting work also doesn't qualify as engineering.

The article seems to make some fairly confusing statements. Why is the bar higher for software engineering, than that of civil engineering otherwise? Statements such as:

> "there is no objective reality inside software"

> "if there are many solutions to the same problem, which one is "better"?"

Is the exact same subjective goal that a objective engineering constraint has in any other engineering field. There are many ways to design and build a bridge, but the engineering aspect of it needs to model reality and account for it in such a way that the bridge to build conforms to said requirements, in a provable way. That's why engineers can be held responsible when mistakes are made.

Software Engineering can be done in the same way. This, however, depends entirely on the culture. My first decade in the field, I was fortunate to only be exposed to en environment and culture that developed software in a provably correct way, or at the very least, aspired to. The latter decade, not so fortunate. With the advent of generative AI, it's become far worse. The challenge is to carve out enough space outside the purview of "management" that wants problems solved with particular tools, regardless of applicability to said problems, and it's becoming insurmountable. Signal to noise disappearing. The idea of buying land and tending to a farm, evermore appealing.

I wonder if the author perhaps has not worked on software that comes with actual engineering constraints. There are plenty of software systems where <if it doesn't work as it should>, people die.