>E.g. in emergency coding I automatically assume I'll inevitably make mistakes due to haste, so I run a lot of sanity "is 1+1 still 2, do I remember that right?" checks.
That's a great point. I've been in such emergency situations multiple times earlier in my career, when I was a system engineer (mainly Unix field support work) at a large hardware vendor. I used to do the same as what you say (double-check many things, sometimes even triple-check, particularly the more important changes I was making via some script or command), and I know it helped prevent me many times, from making mistakes that could have been serious, in a high-pressure and high-stakes situation (where said situation was often because of data loss with no backups or something equally bad). And in many cases, I was successful in solving the problem / restoring the data / etc. Also saw, and in some cases, prevented colleagues from making, such mistakes. Was too late to prevent them in other cases (sometimes by a few seconds, like once when I was a bit too late while trying to grab a colleague's wrist off the keyboard when they were typing a command (as root, natch) that could cause irrecoverable damage (and sometimes did). And this in live production environments on multi-user Unix systems, e.g. in a factory environment.
A real-life example of what I said in the last few lines above:
A colleague and me were in the computer room of an auto parts factory that had such a multi-user Unix system deployed in production. As part of some maintenance / problem-solving procedure, he types (as the Unix superuser):
# init 0
(which shuts down the Unix system automatically, with no delay or warning) on the main console, without thinking of informing all the live users in production to stop and save their work - on the shop floor, stores, accounts dept., etc. You can guess what happened next - dozens of calls on the intercom from highly irate workers from all those depts., in colorful language ...