Errors are Not Failures

This post was originally published on blog.charliemeyer.co

This week, I’m working on a rewrite of Pickcode’s backend using Prisma and NestJS. The details aren’t important, but it goes without saying that I don’t really know what I’m doing. Throughout the process, I encounter an error every 15-20 seconds. To an outsider this may sound frustrating, but it’s not – it’s how I work best.

Programming is about making systems that work – they have an intended behavior, and anything other than that intended behavior is a failure. These failures almost always come with an error, so we have the following relationship: failure implies error. The converse is not true. An error is not a failure, at least relative to the programmer’s true goal of building a working system.

Beginners often get this relationship wrong. Errors are RED and BAD and SCARY. Seeing something RED and SCARY feels like a setback, but it isn’t: it’s information. It’s information that is incredibly helpful towards implementing your end goal. As mentioned, in working on my backend rewrite, I encountered errors every 15 seconds or so, mostly with a smile on my face. Avoiding seeing error messages should not be your goal while programming, it should be seeing and fixing errors as fast as possible. [1]

I hated chemistry labs in high school. [2] If you screw up a titration, you actually have felt a setback, and you’ve used up some of the finite supply of your chemicals. In programming, you are given an unlimited number of errors and nobody is charging you for them. Errors might be my favorite thing about programming. Errors are free. Errors are not failures.

[1] Your IDE and compiler should be giving you these errors. If your language or IDE doesn’t give a lot of errors, invest some time in improving your tooling

[2] No offense to Ms. Porter, she was awesome