Errors Are There to Help You

Photo by visuals on Unsplash. (Source)

A few months ago I was helping a student with CSS animations, and we were pairing remotely on an online code editor. We set up our keyframes, defined our animation duration, created our div, hit save, and…nothing moved. We couldn’t figure out why. We tried tinkering with the CSS, changing the animation properties, refreshing, simplifying the keyframes. No luck.

At the end of class we found this block of CSS at the bottom of our file:

body { 
  background: url(");
}

We had inadvertently written this at the beginning of the pairing session and had forgotten about it.

Recognizing our silly mistake, I thought to myself, why didn’t the editor tell us about this?

Whatever HTML or CSS you give to a web browser, it won’t complain: it will try its best to render something reasonable on the screen. In our case, neither the online code editor nor the browser alerted us that there was something wrong. If it had thrown an error, we would’ve been spared a lot of frustration.

This made me think about how errors in software are like pain signals in the physical world—they are built in to help you navigate and survive. Pain is unpleasant, but it’s a useful mechanism that helps you avoid significant damage to your body. At first glance, it may seem beneficial to be completely incapable of feeling pain, but this condition can cause all sorts of problems.

In software, an error is there so that you as the developer can solve the problem before it gets into production and propagates to your end user, at which point a mistake is far more consequential.

But as novice developers, we often think of errors as bad—indications that we’ve done something wrong and are being punished for it. This association is exacerbated by the fact that errors are written in jarring red text or all caps, giving them an especially reproachful sting. The only reason they’re expressed this way is to get our attention. Errors need to stand out, and what better way to stand out than by giving the developer a subtle jolt of anxiety.

In fact, we don’t just want error messages to stand out, we want them to give us a clear idea of what we did wrong. A great programming language or framework will give you precise errors that help you fix your problem quickly. So rather than

Segfault: you broke something and I have no idea why

You want to get something closer to

TypeError: you can't access a 'radius' property on type Square

So errors are built with the developer in mind, and if designed well, they can be very helpful.

We can use this to do some cognitive reappraisal. We need not view errors as malevolent entities out to hurt our feelings and derail our careers. You can view the next error you encounter as a source of wisdom. That TypeError that’s showing up for the 12th time has your best interests at heart — it derives joy and a sense of purpose from preemptively surfacing bugs and giving your users a better experience.

So the next time you see an error, don’t be upset. Say to the error: Thank you error, for guiding me to the right path.