I've been doing this kind of work for decades
So have I. And I my specialty is in R&D of industrial control systems. Although I have never sent anything into space, I have been designing controls that if they crash, or even if they crash-then-recover, must do so in a graceful manner to avoid causing damage to equipment, or even injury or death.
For instance, one of my first embedded projects was a controller for a dynamic balancing machine. This particular dynamic balancer happened to be spinning-up Flywheels for Caterpillar Earth-Movers. Each flywheel was about 4 ft. in diameter, and weighed about a ton (literally). Then we spun it up to 1800 RPM, and figured out where the imbalance(s) were.
I figured out REAL early on (and without a "team") that if I "watchdogged" (or otherwise found myself back at the start of the code), that I couldn't just ASSUME that I could re-initialize Ports, Data-Direction Registers, etc; but rather had to "look around" at various inputs to see WTF was the REAL state of the machine, THEN try to do an ORDERLY shutdown and restart. Never once caused a flywheel to act like a Frisbee...
BTW, at that time, I was 20 years old, and completely self-taught.
So sorry; just because you are an "engineer", doesn't automagically make you a better Developer. Stupid is as Stupid Does.
Oh, and then there was the Project where I was contracted to develop a "Failover" system for Handicapped vans. Worked a treat. Never failed to detect input/output mismatch or switchover to the backup systems, and in far less time than a human driver could detect the failure, let alone reach for the "switch to the backup" switch while trying to keep their out-of-control van from flying into the ditch...
This is rocket science we're talking about. It's hard.
So are a LOT of embedded industrial control tasks. And MOST of them don't really allow-for a simple "Reset" in the middle of a Run-condition without "Very Bad Things"(tm) happening.
Moral of the story: You don't need a degree; you need an IQ. And experience.