> Engineering is not about never making mistakes. Forgetting a semi-colon is common, and any software engineering process that depends on people never forgetting something that trivial is fatally flawed. When you make a mistake in vehicle control software, there should be many layers of failsafes to catch it, such as: the compiler, automated unit tests, automated acceptance tests, code review, manual feature testing (with a simulator), manual release testing (with a simulator), integration testing on a vehicle that has been immobilized, integration testing on a closed track, and production environment trials.
> Keep a few mistakes between yourself and disaster. One mistake is a very slim margin.
This is all spot-on. In a related vein, I used to despise any mention of "Systems Engineering", and then I worked in the development of complex systems. "Systems Engineering" is really about mindset, tools, and processes to impose coordinated rigor in the engineering of a given system. There is no Theory of Systems Engineering in the same way there are theoretical underpinnings in Mechanical, Civil, Electrical, Aerospace Engineering, etc. Elevating it academically to a fully-fledged field of engineering in the same way as these is the irritating part. However, the likelihood is extremely high that with any large and complex physical system that embodies a strong degree of correctness, good systems engineering practice was integral to its development.
I do not think the majority of software development today corresponds to real engineering practice for any rigorous definition of "engineering". In general, it is much closer to the practice of a craft, like fine carpentry or auto body work (c.f., Eric Sink). What you describe, very aptly, with multiple "mistakes between yourself and disaster" and an embrace of rigor, verification, and deliberate effort undertaken to compensate for the lack of inherent rigor in things like our programming languages, is engineering. Writing lots of code does not make one a "software engineer" any more than building a table in my wood shop makes me a mechanical or civil engineer. If you cannot explain how you develop systems where the implementation in code is just the final manifestation of a design, and that you specifically have systems in place to compensate for or screen out implementation flaws (especially the ones your implementation tools cannot eliminate by construction, e.g., many of today's commonplace programming languages) and logical flaws, then you are not practicing software engineering.
Our ability to construct large and complicated systems in software today far outstrips our ability to rigorously guarantee that the software satisfies correctness properties. This is fundamentally unlike what systems engineering with traditional physical engineering disciplines can provide. I think what Germany is doing is here is right, and fundamentally different than all the stuff going on in the U.S. with Tesla, Uber, Waymo, etc., that seem to be doing huge amounts of ad-hoc implementation, with no consensus on high-level properties the implementations should verifiably satisfy. The raging debates in the U.S. seem to be about whether or not states should allow systems to be tested on public roads rather than what the provable properties of these systems should be.