As a student of history, I remember learning that the Prussian military was one of the first to make a major point of drawing up and constantly revising war plans in a time of peace.
Since then of course, every major power has embraced this discipline because when a crisis occurs — as it inevitably does — fortunate favors the prepared as well as the bold.
As I pondered this, I realize how relevant it is in when it comes to software development.
I understand that there is always a fine line to be walked between rapid development and premature optimization, but somewhere in the middle is a place where it pays off to have well thought out process of what you will do when there is an emergency.
I think that as programmers, we have an epistemic responsibility to conceive of the most likely failure scenarios, and have a plan of how to fix it.
It can be as simple as writing excellent documentation or diagramming the flow of the domain logic and possible problem areas.
It can also be done by having a simple checklist of what to check first when Murphey strikes.
The point is to remove as much cognitive load as possible during a crisis so you can focus on solving the problem at hand.
This concept is not new, but I think when you grok it and make it as much a part of your toolbox as writing tests, it will make you a better programmer all around.