500 Words — Day Thirty-Seven: Decisiveness
The nice thing about having a beer or two is that is really reduces the amount of hesitancy that one may have when taking an action. That can also be a bad thing, but at least in my experience I haven’t really struggled too much with impulsive decision making. My issue has always been the call to action. Decisions can take a lot of thought and effort especially when those decisions have consequences down the road. However, the fear of potential consequences can lead to situations where the fear of potential downside prevents one from realizing any potential upside from taking action.
There’s a nice little theory about drinking and programming that there’s a specific point with enough alcohol in your system you reach peak coding productivity. This was nicknamed the Ballmer Peak after Steve Ballmer, former CEO of Microsoft. But it does make a little bit of sense. Again, back to the earlier point about decision making. Decision making is hard and programming is the ultimate arena of design trade-offs and decision making. I’ve seen young developers get overwhelmed in the presence of tough decisions within complex systems. Sometimes you just got to commit and make a decision even though it is not the optimal one. And with the aid of a little alcohol, the theory seems like it could be plausible given alcohol’s ability to lessen the weight of future consequences. Apparently there is also a study that supports this claim with respect to problem solving.
But returning to the importance of decisiveness, quick decision making is important when making adjustments to a quickly changing environment. While fast decision making can lead to suboptimal design in an engineering environment, slow decision making can lead to the overdesign and is less robust to an environment that changes. Or to put more simply, if you are doomed to fail, it is preferable to fail faster rather than to fail slower. However, to avoid moving toward reckless decisiveness, one always need to be cognizant of the consequences of failure. If you are writing a small program, you can afford to be more decisive as the consequence of failure is the lost of a couple of hours. If you are designing a satellite worth millions of dollars, there may still be moments where decisiveness is necessary, but there are still components of the design that need cautious and careful thought.
The benefits to quicker decision making are an increase in productivity and an ability to react to failure quicker. The drawbacks are that the probably of failure increases which may undermine those gains in productivity. It may be that code written under the influence may work but may be so hard to comprehend and expand that it may end up being worthwhile to start over. At the end of the day, the key takeaway here is to be ready to take action when appropriate and to always keep restraint with drinking a good amount of alcohol. Everything, including fast decision making is good in moderation.
