At the same time, I remember last year someone interviewed a bunch of non-software engineers who later got into software [1]. A good number of these folks actually do feel like software is still engineering.
[1] https://www.hillelwayne.com/post/are-we-really-engineers/
They rarely have reviews, don't have tests, rarely do something equivalent to pair programming etc.
The flip side is that traditional engineering is generally easier to reason about and with a lot of experience you can tell if something is wrong. Doesn't apply so much in software.
E: no testing might be an overstatement, but I think it's closer to no tests than an abundance of tests. Engineers tend to not get their hands dirty, which basically leaves computer simulations.
You can tick all the boxes and still do a shit job that either doesn't meet requirements or fails. It happens more often than you might think.
I've been working on airliner design and have ordered, specified, and reviewed a fair number of mechanical tests. Yet I've never actually built and ran the test rig myself, it's a full time job for specialists.
Difference is with software engineering, you seldom find yourself in court if you decide to skip the unit tests or code review...
Even if you're a chartered/accredited/licensed you personally may not have to. It could be someone else in the company, which shifts the liability.
For a given product, we had a custom PCB with FPGAs and the circuit board guys needed to follow a tons of design rules, then ran a ton of signal integrity and electronic interference simulations etc.
I was in the team who wrote the algorithms and 'software' for FPGA, we worked out the best approach using math on pen and paper, wrote a working prototype in MATLAB, designed the digital logic, implemented a high level but bit-accurate C++ model, and only then started on the HDL implentation, which we verified against the C++ one.
If you ever looked at how MATLAB, the HDL compiler, and the formal verification tool are implemented, even "mechanic" seems like way too much fancy title. The very old phrase "if architects designed buildings like developers built software, the first woodpecker would have caused the downfall of western civilization" comes to mind.
I am a software consultant who has worked in CAD software, which gives me quite some insight in this topic (software developers vs non-software engineers). Ironically, most of the time what's causing the problem is non-software engineers working on these tools, since engineers don't effectively translate their methodology into software (they don't see it as necessary, they don't understand the sources of complexity, they don't have training, etc.) , resulting in a very cowboy attitude to software development.
The amount of review and testing that goes into a single design industrial design is massive by comparison, since you cannot fix a 400 million dollar assembly as easily as code.
In the physical sciences, 'bug's often mean you will injure or kill an employee. The standards are extremely high.
In my time as an electrical engineer, there were many cases where I would book a flight to visit another company/site or consult with an academic/consultants. Also I would fly people in regularly to look at our plant. I never needed approval to bring in external reviewers and pay out billable hours. That sort of practice is unthinkable in software engineering.
For example, another commenter mentioned aviation. I would fully expect that industry to be more rigorous with both their software and physical engineering.
> since you cannot fix a 400 million dollar assembly as easily as code
Have you never seen these projects go wrong? I find that people often imply that things don't break and projects don't fail in traditional engineering when that actually seems to happen more often than most people would think.
For example, a ~$30M council parking building project in my city had to be demolished midway through the project because they messed up the design and it was structurally unsound.