Humans (and I suppose most other animals) instinctively try to avoid pain. This usually makes sense.

Stepping on legos hurts. So we instinctively try to avoid stepping on legos. This instinct drives us who live in lego households to look more carefully for legos before stepping, and to adopt habits like putting legos away (or hopelessly asking the kids to do so) after they’re used.

But sometimes this instinct to avoid pain causes us to do things that are against our best interest.

If you’ve ever had an ingrown toenail, you know what I’m talking about. Clipping the offending toenail is often very painful. But avoiding that pain leads to more pain in the long run.

We have a similar problem when it comes to building software. In particular, when it comes to how we respond to the possibility of bugs or other systemic problems. When a customer finds a bug, it’s painful. Maybe not physically, but it’s at least not a pleasant experience to learn that the software you built isn’t working properly.

Our instinctive response to this situation is often to try harder to prevent bugs from getting in front of our customers. We go through extra code reviews. We employ armies of “QA” testers. We wait until off-peak hours to deploy our changes.

As with avoiding ingrown toenail treatment, many of these instinctive behaviors are counter-productive. They may help alleviate short-term pain, but they increase long-term pain.

In most cases, we’re much better off focusing on practices and techniques that respond to pain when it occurs, rather than trying to avoid the pain directly. Let’s admit that bugs are painful, but then rather than avoiding the pain, let’s make sure we’re prepared to address that pain as quickly as possible when it does occur. (Because it will occur!)