I'm a hacker, always have been. Took a detour to be a PhD scientist, and another one to be a "software engineer", but I'm a hacker. And this hacker can tell you: most (95%) of software "engineering" is not engineering, but more or less the equivalent of telling anecdotes about your grandparents experiences while arguing you have a solution to covid.
That said, there's 5% of software engineering out there that is engineering; read the RISKS mailing list archives if you want to see some examples (and counterexamples).
If software engineers were engineers, testing would be a higher priority, and visible regressions would happen rarely, if at all.
> If software engineers were engineers, testing would be a higher priority, and visible regressions would happen rarely, if at all.
That would mean they were doing their jobs badly. All engineering requires balancing priorities such as physical strength (or in software, correctness), and cost. An engineer who overbuilds everything 10x will quickly be out of work.
When correctness matters less than business results, then your role has passed from engineering into business. Software is somewhere in the middle. Software engineers are often informally expected to own the results without owning the profits.
Cost is an important constraint in engineering. Nearly every engineering project has cost as a component of the engineering process as omitting it yields projects that cannot be completed.
If you could create and patch buildings incrementally like software, you don't think people would do that?
Correctness in itself is not a meaningful goal. If something works well enough to meet the needs of the user, being more 'correct' doesn't necessarily provide more benefit.
The difference between a "software engineer" and a real engineer like a civil engineer is that when a manager type tells a civil engineer to ignore safety or standards for profit reasons, a civil engineer gets to tell them to fuck off
You, as a software engineer, should also tell your manager to fuck off if they are making bad decisions. No one is inherently above you. If they're the kind of management to never listen to you then that doesn't make you less of an engineer, that makes them shitty managers to ignore these important principals behind their systems
Many companies have a culture of continuous deployment that often means "bugs happen, its part of life around here". You would go against the whole mantra of the company and industry. Not easy to tell the boss to fuck off.
It’s even more strict than that. A non-engineer is not allowed to be a supervisor of a civil engineer. This is why civil engineers work in a firm structure: the entire chain of command is made up of civil engineers. Any company who wants engineering work done must contract with a firm. This makes any potential conflicts of interest external rather than internal.
This is also why most defense companies are run almost entirely by engineers. Even though they're not required to be, they organize themselves that way to ensure a culture of design excellence. It's better to fail to deliver a product than to deliver a product that will kill people.
Boeing ended up getting run by bean counters with the eventual expected results where the bean counters wanted to charge for a safety feature. Magically, the planes with the safety feature (every single plane sold to USA, Canada, and EU based airlines) had no issues. The ones sold to nations where they were trying to save money, had the issues that we all know of today.
As for how Tesla is structured, well it's Musk at the top who delegates everything and spends his time on Twitter trying to boost the stock price to hit his quarterly stock price goals. As for if they're managed by engineers, I have no clue.
> If software engineers were engineers, testing would be a higher priority
Many classes of engineers don't have the chance to test their designs. They have to know it will work ahead of time. The closest analogy in CE/CS might be formal methods, which (as I suspect you would agree) are sorely under-utilized.
That said, there's 5% of software engineering out there that is engineering; read the RISKS mailing list archives if you want to see some examples (and counterexamples).
If software engineers were engineers, testing would be a higher priority, and visible regressions would happen rarely, if at all.