Productive and unboring debugging

Most of us don’t like debugging: it bothers from current tasks and disappointing, because hints that we’ve done our work in bad faith.

But in real life software without bugs is not possible. If so, let’s do something with it!

How to make debugging productive?

And at some point I realized that debugging actually is not so bad. More than that it can help you a lot in future.

But to get it you should follow some rules.

• Never do monkey debugging firstly. Usually it means using logs or debugger to get runtime values at certain point of execution.
• Never do debugging in autopilot mode.

Humans are lazy. They try to find the shortest way to solve the problem. And logging is it. We don’t think, just mechanically searching for a place in code, step by step. It can take 3 minutes or 3 hours.

Then found. Fixed.

We didn’t think and analyze the real issue and as a result don’t remember the code structure. And when it happens again we have to start from the beginning.

And this is a real trap. Errors are insidious ones and can turn out to be a very deep hole. At the end hot fixes lead to more and more bugs.

Spending just several minutes trying to investigate the issue in our head we:

• refresh our knowledges about architecture
• get extended and advanced vision of the problem
• can do proper conclusions
• prevent other such problems (in future or already existed)

There is even an exercise for memory training: before going to sleep remember everything that happened today in reverse order. Debugging is the same, just remember all things related to the issue. Sometimes it’s hard or even not possible, but attempt definitely have to be.

It doesn’t help. I need to go deeper

I have a small list of steps, that helps me in debugging:

1. There is no magic here. Really. Yes, I know that you are sure, that you wrote everything correctly. But there is no magic. It’s computer. And not quantum one.
2. You look into the wrong file/database/repository
3. Where were the last changes. Realization of difference between working version and broken one is very important.
4. Don’t stay at one obvious point, move further
5. Extend the vision. Things are got by many ways.
6. Read more precisely suspicious places
7. Go through the code, executing it line by line
8. Go for coffee
9. Have a talk with someone about pokemons
10. Try again 3-6
11. If nothing helps, ok, use the debugger or logs.

How to have fun with it?

The best thing in debugging is a possibility to have a guess about a real problem.

It’s like a riddle. Everyone likes riddles, it needs just to feel the bug as a puzzle. We have initial conditions which lead to the incorrect behavior. That’s your riddle description. Try to write down at least several possible reasons of the problem.

Solving problem in this way turns routine into the game and success brings much more pleasure than solving by monkey debugging, after which you probably would think: “Hell, I could have a guess about it, actually”

Take care and have no bugs!