https://en.wikipedia.org/wiki/1999_Martha's_Vineyard_plane_c...
> The probable cause of the crash was "the pilot's failure to maintain control of the airplane during a descent over water at night, which was a result of spatial disorientation".
At some point there's not much else to do. Pilot exceeded their training and flew into the water. You could try to prevent that with more and more autopilots and warnings, but at some point pilots have to be able to fly the thing on manual and need to have the actual training for the conditions. I doubt the modern NTSB would be able to say anything better.
The prompts that you have setup also won't stop you from doing a `sudo shutdown -r now` in production quickly one day on autopilot (and typing sudo doesn't help much at all because it is now so common and you probably do that on preprod as well). STOP AND THINK is still going to be the best tool in your toolbox.
And in addition to having been a system administration since the early 90s (and worked at Amazon for 5 years) I'm also a cave diver. There's a variety of different methods in cave/technical diving to avoid breathing the wrong gas at the wrong depth. The best one is probably just to simply label all your bottles with your MOD, always analyze your gas and have a gas analysis sticker on the tank that matches the MOD sticker, then to always go through gas switching procedure with your buddy and validate MOD and analysis sticker every time you do a gas switch (even if you think you're not carrying any gas that is outside of the range where you're diving that day). Alternatives like different colored regulators or carrying gas on different sides run into trouble with exceptional procedures when regulators fail or tanks wind up getting dropped and picked up and put on the wrong side. You can then wind up following "correct" gas switching procedure at the gas switch time and still die. The best solution anyone has come up with has just been to always verify gas contents before sticking it into your mouth -- stop and think every single time. Adding anything else is generally creating more of an overcomplication that causes more additional secondary problems than it solves.
> a better design would have prevented the mistake.
You still need to show that a "better" design actually does stop the mistakes. Does having the stars and forks listed in the message really do that much or do people who are autopilot not reading still just hit submit? Has anyone really measured that?
I do not share your unbridled optimism that the perfect UI/UX design is out there which solves all problems and has no unintended consequences, and one of the unintended consequences I think is social which is that we learn to expect that if we screwed up that someone else should have stopped us.
And I learned that early growing up on systems where deletion was largely permanent and people didn't have backups (although I did get paid some money in high school to manually undelete files on an Apple floppy disk that someone else had nuked by accident), so I learned to think through permanent actions early. And I didn't learn to blame someone else for my own failure. I leveraged that at Amazon and ran all kinds of nasty commands in prod on a daily basis and never destroyed the company (all of that was done in the service of standardizing the configuration management of the systems and in the long run reducing the amount that prod needed to be touched, but early Amazon had a chicken-and-egg problem with a massive production deployment and no good standardization).
Modern accident investigators avoid the words "pilot error", as the scope of their work is to determine the cause of an accident, rather than to apportion blame.
And from the NTSB:
The NTSB does not assign fault or blame for an accident or incident; rather, NTSB investigations are factfinding proceedings with no adverse parties and are not conducted for the purpose of determining the rights, liabilities, or blame of any person or entity."
https://www.ntsb.gov/investigations/process/Pages/investigat...
> should have been for the author to STOP AND THINK when deleting
I've been doing system administration and programming since the early 90s. One of the first things I learned from a grey beard at the time was after typing a destructive command, take my hands away from the keyboard and read back what I just typed before pressing enter. It was a great lesson and has saved me from a lot of mistakes.
Guess what? I still occasionally make mistakes. Because I'm human.
So another thing I learned was to make any shells on production systems be visually distinct. All my production machines have a red shell prompt. That's saved me from even more mistakes than reading back commands. And it protects more than just me, but anyone else who logs into those machines. (Yes, ideally, no one is ever logging into a production machine.)
The problem with "STOP AND THINK" is that it requires every person to learn that lesson individually. Meanwhile, if you accept that human behavior is what it is and design around it, you can save many people from mistakes in the first place.
There's a saying: do you want to be right or do you want to win? Personally, I want to win (i.e. be effective). Winning means accepting humans are fallible and doing my best to design systems for them instead of holding them at fault in cases where a better design would have prevented the mistake.