On failure

Some reflections on the idea of what it is that we do as software engineers.

Alex Strick van Linschoten


November 21, 2021

I’ve been working as a machine learning engineer now for a few months now. If there’s one thing that I have found characterises my experience so far, it’s failure. Software fails; we even have a word for that: bugs. Learning new things might also be characterised as departing from a state of failing to understand.

There hasn’t been a week that’s gone by since I started where I didn’t encounter some kind of failure, usually my inability to understand why something was behaving in a particular way. My last post was about debugging, and finding ways to move forward in the face of failure is a key aspect of that process.

Failure isn’t fun. My initial reaction to hitting something I don’t understand is not one of glee and excitement at getting this opportunity to solve some kind of problem. But maybe it should be. It occurred to me this week that actually failure is sort of the name of the game. Solving hard problems is exactly what software engineers get paid to do. If it were just easy, it’d be a different kind of work.

Two posts by Julia Evans are pretty great on how a lot of being able to do this kind of work is about mindset. Ellen Ullman covers similar territory in ‘Life in Code’ and ‘Close to the Machine’.

The point is this: we are paid to confront this failure. This is the work. Thinking that it’s a distraction from the work — some kind of imaginary world where there are no blockers or failing tests — is the real illusion.