This post is not about cooking, sorry.

As long as we do not keep stumbling on the same stone, fixing mistakes is a very efficient way of learning. We have the advantage that exploring failure is a lot less painful with programming than it is with car driving or brain surgery for example.

Debugging can be a wonderful experience, an intricate riddle with a hidden gem of knowledge as reward. But most of the times it is just a really frustrating ordeal for two main reasons: the lack of time, and the lack of understanding. And that lack of understanding is a chicken and egg problem. You’ll learn a lot by fixing the bug, but fixing it is out of your reach because you don’t know enough… Fine, now what?

This is where years of intensive gaming can help with a big principle: keep killing the weakest monsters until you are ready to take on the boss. Now look at the list of currently open bugs, they most likely fall on two categories: the ones you can explain, and the ones you can’t.

Bugs you can immediately explain are usually caused by bad design, you know what has to be fixed, and hopefully you know how to fix it, it’s just a matter of biting the bullet. Appearances can be deceiving, but sometimes the link of cause and effect is clear. I would call that the boring bugs. It is still part of the job, but it is not where the fun is. By identifying the issue and finding the proper way of fixing it you have already benefited from the learning.

But the other bugs – the ones you don’t really get at first – might be the weakest monsters you are looking for. They don’t look like show stoppers: it’s only a misaligned character, a sound that triggers when it should not, a noisy splotch on a texture or a hiccup in the framerate at a specific moment. The game could actually ship with it and that would be just fine… But who knows what you might discover in there? It’s like panning for gold, and most of the time you won’t find much.

But I have found bugs that were disasters in the making, and whose visible manifestation was only the tip of the iceberg. Looking for what was really happening under the surface taught me a lot and gave me the opportunity of fixing a much larger issue.

I used to work on a project where a few days before each scrum sprint demo the team would make a rehearsal of what we would show, and we would make a list of everything that looked wrong, including the smallest details. We would then spend the time until the demo to fix as many of these points as we could. I think the time we spent on these details had a crucial impact on the overall stability of our game. Since then, I have been applying that principle to everything I do.

So, pick your bugs. Aim for the small ones that look funny, they are full of surprises.