Photo by Joey Nicotra on Unsplash

First let’s understand why we’re talking specifically about debugging.

The 3D Process

Design

Develop

Debug

Looking at those 3 parts, the most important part to improve, in my viewpoint, is debugging your code.

Why?

Because Design can happen and can also not happen. It can also be a short or a long process. It’s under our control.

Development has to happen anyway otherwise there’s nothing to debug.

But debugging WILL happen, and it will undoubtedly occur near the end, when the deadline is close (or the night gets short), when stakeholders are pushing, and when your creative energy is usually depleted.

While technical Design is pure creation – you’re just imagining up your code architecture and actually creating it in your head / whiteboard, and Development is the physical creation, which has its struggles but is still always going forward (as you create more and more components of your app), debugging just doesn’t feel like creation, but more like fixing what’s already working (or mostly working).

So what can we do to alleviate this part of the process which is the most undesirable, painful and feels the least under our control? What superpower will mostly help us tackle this part and bring those hard-to-find bugs to their knees as fast as we can?

Logic

As opposed to Design & Development, where imagination and creativity are key, debugging is much more of a straightforward machinery process. Which means it can get boring fast, but if we look at it as a game of beating those red-eyeing bugs, we can think of it in terms of winning those bastards and sending them straight to outer space using our (re)discovered superpower, logic. Specifically, solving any bug will consist of:

1. Make sure you understand what the issue is.
2. Ask for any missing data / reproduction steps.
3. Fire up your application and get your starting point right.
4. Make sure it still reproduces.
5. Break down the flow down to pieces.
6. Take a look at each piece separately and document its results.
7. Concentrate on the first piece that seems broken.
8. Find the solution for it (it could be in yours or someone else’s code).
9. Get it fixed and move to the next one that seems broken.
10. Repeat steps 7-9 until morning (or until bug is solved).

The key takeaway here is point #5. Obviously to do it right you have to go through the other points first. But point #5 is the one which makes the bug / flow manageable and something that you can put under control. That would be the key point – control the bug, because if it was under control in the first place, it wouldn’t have been a bug 🙂

So next time you’re close to your deadline and you’re watching the list of bugs on your issues management system piling up, focus on your mind’s superpower and start blasting those bugs away!

Let me know what you think in the comments below 🙂

Cheers

Nadav