Boeing 737 MAX crash and the rejection of ridiculous data

All that video really shows is that if you do it wrong it doesn't work. Not all that shocking

Regardless, my assessment is based on most juniors I've worked with. By their third year most seem to have already grasped the need to test for boundary conditions, and to ensure proper error handling for GIGO failure. Any 1 year+ with at least FizzBuzz levels of understanding can be handheld toward it with the right nudge, and in fact, the less experience they have the more eager and likely they tend to be to pick up on error handling since they haven't yet developed sufficient skills to be able to get their head around the "test you don't need to write" because the result can be inferred from a test at another level of the system (a frequent coping strategy that starts creeping it's way in with increased levels of familiarity with a complex system).

Any problem grokking the above points is usually solved with an impromptu exercise and lecture where I have the junior play the part of a computer until they realize just how much the computer "doesn't know", and has no capacity to derive from reasoning, unless it's actually coded/implemented to. I've not yet had a junior who failed to grasp this to some degree (though a recent one is giving me a run for my money), and become capable within a couple months of inferring two to three-function away error states to test for. Within the year, I can typically point them at an arbitrary code block and get back a reasonable testing surface.

Which brings me to my next observation, where I think you may be attempting to make a point:

If I run into juniors of 1-3 years experience who need coaching to fully understand what I explained above, then perhaps the average programmer is not capable of inferring what I claim.

To which all I can say is, my observation may be skewed, because I'm a bloody paranoid polyglot of a tester when it comes to safety critical systems. Even when I was pre-collegiate programming calculators, the more someone else actually depended on something, the greater the lengths I'd go through to test things before cutting them loose with anything I was producing for them. The THERAC-25 postmortem is bedtime reading for me, and I've pushed myself to understand computer science and software engineering as more than mere 'coding'.

If the argument then, is that I'm an atypical representative of my software composing brethren, then I'd like to know why in the $deity's name we're not triple-checking safety critical code at system integration time, seeing as we can assume this level of inattention to detail by the average programmer. Especially given as the languages these types of systems are implemented in are typically not the most 'friendly' languages.

This suggests cultural issues, undue pressure to fast-track approval, disincentive to raise red flags that could impede delivery, or an "over-the-wall" hyper siloing of expertise/responsibility that lead to the least experienced in complex system implementation being blindly trusted by those who had the experience to realize something was horribly wrong.

If the above doesn't assuage any concerns relating to my experience, I'm afraid not much else will.

The problem is much more complicated than this and requires thinking end to end about 1) what the purpose of the system is, 2) when and how it should operating, 3) how much control it should have, 4) how it's activity is made visible to the pilot when it performs any control, 5) how and under what conditions it should automatically disable itself, or 6) be able to be manually disabled, and 7) how the pilot is made aware of all of these situations in a way that doesn't cause confusion in potentially complex scenarios involving other failures and alarms going off, and 8) proper training so the pilot can manage the plane when the characteristics have changed after the system is disabled. Oh, and 9) in this case since it's impossible for a pilot to manually trim a 737 when it's above a couple of hundred knots, making sure an electronic trim assistance function is available in this scenario (which it wasn't due to tragic idea to overload the use of the trim runaway cutout switches).

And I am probably missing a bunch of things, which is part of the point.

However if you kill the power to the trim motor and then turn it back on MCAS will blindly add more trim on top of the trim it previously added. It doesn't remember how much trim it's already applied.