Engineer is a whole other thing from the steam age, my BSc was in Math, worked fine to get me in.

As a mechanical engineer, I would beg to differ. When you strip away all the fancy math, engineering is ultimately about critical thought and solving problems/achieving functionality with limited resources. As one of my professors liked to say, "Anyone can build a bridge to support a load, but only an engineer can design a bridge that just barely holds that load."

Engineering is an ancient domain that goes back to the very beginnings of civilization and continues to grow with our needs as we progress. Where once it was just mechanical, we now have domains like electrical, materials, and biomedical engineering. If we've hit a point where we need engineers who specialize in software, why shouldn't we welcome in a new domain?

While it does feel weird calling software developers 'engineers', that is arguably what they do. It's no less reductionist to suggest they are just programmers than it is to suggest that mechanical engineers are simply CAD and Excel jockeys. There's a layer of comprehension about the systems in play and how they can be manipulated that gets lost in the reduction.

My only real sticking point about software engineers where I tend to push back is that Professional Engineer is a legally protected title and indicates licensure, at least in the US. It requires the right degree(s) and several years of work supervised by a PE to qualify for that licensure. The importance of the PE license is that you are recognized as an authority in your field- for good or ill. You can make big decisions, but you will also be held accountable if something goes wrong.

In my experience, many software engineers brush aside the importance of those types of qualifications because their field wasn't quite as rigorous to enter. As we continue to develop a society where software mistakes can absolutely kill people (e.g. self-driving vehicles, robots, automated decision tools in medicine and insurance, etc) or cause massive economic damage, it's critical that we decide how software engineers play a role in preventing those things and how we hold them accountable when they don't.

Any shaved ape can code. One thing that distinguishes worthwhile coding from crap is adherence to engineering principles. Nitpicking about the semantics of the word "engineer" avoids the incontrovertible fact that empirically derived principles and best practices exist and that software engineering is a thing.

Coincidentally, my MSc is in mathematics and statistics, after a dual BSc in math and physics, so we're from similar starting points. My education as a software engineer and later as a systems architect only came once I began coding. There's a considerable body of empirical knowledge in the literature (along with too much irreproducible fluffy bullshit), but in my experience, the general awareness of that knowledge is worse among the newer generation of coders than older ones. I suspect that's because they generally assume that the toolchain and processes do it for them.

The widespread adoption of Scrum has been another source of knowledge loss: it's used in a number of situations where it does more harm than good, and even where it could succeed, it's often misapplied (partially because some agile principles are impossible to implement in most real-life organizations, so misapplication is the only posssible kind of application). There are times when architecture and design matter greatly, and some agile practicioners seem to actually believe that they can be done on the fly or major shortcuts can be taken. "We're not doing waterfall!" You know what? I've been in the business since before some of those fools were born, and I've never done a waterfall project. It was already an anti-pattern in Fred Brooks's 1970 magnum opus. Agile vs waterfall was always a false dichotomy. It's just that some of the OG agile people were too ignorant to know that, or too self-interested to admit it.