It all started when I wrote “Hello world”… and it didn’t work. The year was probably 1996, and the programming language was most likely PHP. That’s the first time I remember truly debugging, actively digging into what wasn’t working, and why.

At its core, debugging hasn’t changed since the term was coined, even though the technology has changed a lot, from punch cards to OOP to using LLMs. But we are still hunting down bugs in our code that prevent it from running as expected.

For me, debugging is inseparable from the act of coding. There is no coding without debugging. I debug, therefore I am.

Writing software has always been a joy, the thrill when something finally works just as you intended, the sense of endless possibility. Yet, I still get even greater satisfaction from locating a bug that was difficult to track down. The perseverance it takes, the methodical narrowing of suspects, the moment you finally nab the culprit, nothing beats that feeling.

Sometimes bugs are easy to spot, sometimes they’re elusive, and that’s when the hunt becomes most compelling. Even when you think you know your software inside out, tracking down a tricky bug almost always uncovers something new, something that doesn’t look right and needs fixing (when you have time), or reveals that one of your assumptions about the system was flawed. So you adjust your mental model* and keep going.

A bug at the end of such a journey could be anything. I can categorise issues we are trying to find into the following categories:

– Bug is in the code, and you can replicate it easily on your localhost

– Bug is in the code, but you can’t replicate it easily on localhost, but you can on production

– Bug that happens only sometimes, usually related to randomly failing tests.

– You have no idea what is happening or where, but the software is not behaving as expected.

These “categories” are very general, and you can narrow them down a lot. But for the purpose of this rant, they will do.

When I look at those categories, they are ordered from easiest to solve to hardest, so when you have a bug on your localhost and don’t know how to find it. Consider spending more time getting to know your software, how it works, and how to use debugging tools and techniques to find the bug faster.

And the rest of the categories? Well, that’s what my future posts should be about 😉.

If you want to learn more about coding, the software you write, and the system you are in, debugging is the way.

Follow me and I will share how I approach things. Examples of real debugging stories. My favourite debugging tools and techniques.

And if you can’t wait, email me or DM me on LinkedIn.

Thank you for reading.

PS:

* It wasn’t until I read this 👇 that I realised the way I think about “the software map” in my head is more of a mental model.

“A mental model is the thing you build when you read code. It’s your internal map of how the system works, where the tricky parts are, what depends on what. Without it, you’re just staring at lines of text.” source