Move Fast without Breaking Things
I&#x27;d add: <i>think before you code</i>. Programming is hard because thinking is hard. If you don&#x27;t use tools to help you think rigorously you&#x27;re going to ship software with bugs regardless of how good your unit tests are or any other strategy you use to cope with poorly designed software.<p>I don&#x27;t believe <i>not thinking</i> is going to help you move faster. You&#x27;re just going to spend most of your time fixing the problems you hadn&#x27;t thought of before you started shipping code. And yet this is what we&#x27;re encouraged to do. We&#x27;re asked to fix the bugs, do the least amount of work to get it to go, and fix the problems later. We&#x27;re asked to not think and just code. There are probably a handful of people in the world who can write complex systems in code with consistently correct results. The rest of us need to be more mindful.<p>We have wonderful tools available to us that can exhaustively check our designs. Using a system like TLA+ allows you to model your system in some pseudo-code and comes with a program that will exhaustively check your code for dead-locks, invariant violations, termination, etc. I&#x27;ve seen it used to find errors in graduate students&#x27; <i>binary search</i> algorithms 9 out of 10 times. Imagine what it can do for non-trivial components of your application.<p>Part of moving fast is knowing how to avoid making errors in the first place. The only way I know how to do that is to <i>think</i>. You can&#x27;t do this properly in code alone. You need higher-level tools to check your assumptions and find holes in your thinking.<p>You don&#x27;t see structural engineers slapping together the first thing that works and patching the building later when parts of it fall down. You don&#x27;t sign waivers before crossing a bridge that claim no responsibility on behalf of the designers if it falls down while you&#x27;re on it. Nor do you see engineers accepting more money from people to build private bridges that are less likely to fall down. So why do software engineers have no such liability for their creations?<p>Why not take a few hours to write a proper specification for your distributed locking mechanism and save yourself days or weeks worth of debugging -- or worse -- liability suits when your mistakes harm the interests of your customers or the public at large? Why not use tools that check your thinking so that you can chase more interesting optimization and performance problems?