Testing to prevent normalization of deviance

In my other life, I’m an avid climber and spend a lot of my time outdoors scaling mountains over rock and ice. When I’m outside, I never take safety for granted and am constantly assessing each moment for potential risks. What happens if I fall? What if that block of ice suddenly cuts loose? It’s often easy to do because the consequences of a climbing accident are monumental – I’ve lost more than one friend from climbing.

As a result, I have certain precautions to help me prevent a fatal climbing accident. I have a checklist to make sure I bring the right gear when I go outdoors. I make sure I have a first aid kit, some rescue gear, and a competent climbing partner. When the risks are too high, I turn back and tell myself I’ll climb that mountain another day.

So why don’t I hold myself to the same standards for coding? I was watching a video about the normalization of deviance and it’s role in the Space Shuttle Challenger Disaster. If you’re unfamiliar with the concept, it explains how high-pressure situations cause you to take shortcuts. And after some dumb luck, you convince yourself that taking shortcuts doesn’t have any consequences until that one moment when your luck runs out. And then I got to thinking about how I could apply this to my daily life. With climbing, the application is obvious, but what about coding?

 

 

Recently, I’ve been messing around with small coding projects in my spare time without any real plan or goal except to learn. It’s incredibly easy to just checkout a new branch and hack away unhindered by guidelines or tests. The consequences for doing so are relatively low with coding; nobody is going to die if you don’t write tests. But ultimately, I’ve found that coding without any real plan only creates problems. If you lower your expectations and take shortcuts in order to build something quickly, bugs will inevitably plague you down the road. Experienced coders probably know this and take measures to prevent themselves from going down this path.

So today I’m going to try and make a commitment to always code with a plan. That doesn’t mean that I won’t stop tinkering with projects without tests. And it certainly won’t prevent me from making mistakes. But I think it’s good to try and remember that being a skilled coder means understanding the consequences of your actions in the future and holding yourself to the highest standards possible.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s