The Pleasure of Hunting Bugs

Horizon is one of the longest running programs on British television. One episode from 1981, titled The Pleasure of Finding Things Out, features an interview with Richard Feynman (you can watch it on BBC iPlayer or Vimeo). In it he talks about his love of science and how his father instilled in him a distrust of authority and a desire to find out how the world really works. Other than a couple of lines from the interviewer, it's essentially an extended monologue from the legendary scientist and teacher.

During the interview, he gives one of my favourite metaphors of the scientific method, comparing it to a game of chess. Imagine watching one small corner of the board while a game is being played and trying to determine the rules from what you observe. As the game progresses, we build up a list of rules; pawns cannot move backwards, bishops always remain on the same colour and so on. In time, we think we understand all the rules of the game. Then, something unexpected happens that breaks our rules; like castling, or a pawn becoming a queen. We now need to update our rules to accommodate this new knowledge of the world. We can never be certain that we have uncovered all the rules, only that the rules we have fit the game as we know it. There is always the possibility that something new will come along that breaks those rules.

I don't know a great deal. I have a limited intelligence … I don't know the world very well.

Richard Feynman

When we write software, it reflects our mental model of how the world works. Like the surprises in the game of chess, a bug is an indication that our mental model is incorrect or incomplete. Maybe an external API doesn't behave in the way we expect, or the range of possible values sent by the client doesn't match what we're handling. Investigating and resolving the bug is an opportunity to increase our understanding of how (one small corner of) the world works - to improve our list of rules of the game.

The thing that doesn't fit is the thing that's most interesting. The part that doesn't go according to what you expected.

Richard Feynman

When a scientist comes up with a new hypothesis, their job is to subject it to every test available that may disprove it or highlight any weaknesses. The hypothesis is a starting point, not a destination. If we view our software like a hypothesis, then fixing bugs becomes an exercise in improving our code to better fit the world as it really is. Like performing a science experiment, we can keep passing the same input to our system, following the chain of cause and effect, until we find the point where our mental model and the real world diverge. Re-framing it in this way changes something negative; "there is something wrong with my code" into something positive; "I'm improving my understanding of how the world really works".

Happy hunting! 🐛