Read the error message

This post is brought to you — indirectly — from a boss I loved working for, on a project which almost killed me, at a company which I had to walk away from to restore my mental health.

I learned a great many things from my boss (and yes, we are still friends). I learned about level 80 in World of Warcraft. I learned how using the static keyword in just the wrong place in your C# code can render even the best-designed security useless. I learned that working 16 hours a day for six days a week is a recipe for burnout.

And I learned how to read an error message.

My boss got upset with us one day on The Project From Hell. Tempers were frayed, tensions ran high, and other euphemisms were euphemisming. In short, we were all grumpy, and as expected on a project of this nature we kept making obvious mistakes and wasting our energy chasing our tails.

Obvious? Well, yes. It turns out that the answer to a particularly common issue we were running into was explained in the first line of the stack trace of the code that kept crashing. I’m not exaggerating for the sake of this story. The actual problem was explained in the first sentence of the error, in the very first line.

The thing about errors is that our eyes gloss over and we try and close the message as quickly as possible to make it go away. Exceptions make us feel bad, like we did something wrong. What we tend to forget though is that computers don’t know what we’re thinking. They do what we tell them to, and not what we want them to do. If programming were wishful thinking, I wouldn’t have needed to spend 16 hours a day doing it.

With a few exceptions (pun intended), error messages in Microsoft products are surprisingly well-written. Not only do they tell you what went wrong; in some products they will tell you where it went wrong, even down to the line and character in your code. Considering how complicated a code compiler is, this is very impressive.

Aside: the Rust language compiler is incredibly good at telling you what you’re doing wrong, how you’re doing it wrong, and how to make it right. Check it out if you want to see a modern approach to writing cross-platform code.

It’s very easy to shut down your brain when you see an error on the screen and ask someone else. It’s easy to close the message, click on the X, close the window. But here’s a funny thing I worked out after my boss got upset with us on that day in early 2008. He was right. The error message told us what we were doing wrong, and after a short chat with my boss, also how to fix it.

When my father was still alive he would make me look up a word in a dictionary if I didn’t know it, and then I would have to write it down in a notebook. It seemed mean at the time that he just didn’t tell me, but I learned how to use a dictionary very quickly as a result.

If you’re reading this, chances are you have spent several years using a computer. In that time, you may have seen hundreds, if not thousands or even millions of error messages. The next time you see one — and your first instinct is to ask someone else — I would like to challenge you to figure it out yourself. Chances are you’ll learn from it a lot better than relying on someone else.

Please: read the error message. Parse it in your mind. Break the sentence into components and understand each one. Even simple things will make a big difference in your work as a developer or database administrator, if you can tell the difference between an invalid operation exception and a null reference exception.

Of course, I don’t have an issue with you asking for help if you’re stuck. That isn’t the same thing. But at least give it a minute or two and think it through. You’ll thank me, like I thank my ex-boss.

(Image source)