Sometimes it’s difficult to understand exactly how to solve a problem without getting more information.

Verbose logging mode is available on the majority of libraries and provides the information showing how everything fits together which is normally enough information to work out how to solve the problem.

My natural approach, when stuck using a 3rd party library for example, is to read the documentation but I have noticed that better debuggers than myself head to the source code much earlier and try to work out what is going on from there.

This approach certainly makes sense and when I have problems with project code my instinct is to look at the offending code straight away and try to work out what’s going on. I haven’t quite got this discipline when it comes to library code just yet.

The art of this approach comes in being able to read through the code and realising quickly which parts of the code are important and which can be skimmed over.

An article I read about the expert mind seems to confirm this, stating that an expert in any discipline doesn’t analyse more options than others, only better ones.

Closely linked to the above is the assumptions we make when debugging.

The best debuggers don’t assume that the code does exactly what they expect it to, they take a more critical approach and try to work out whether or not it is actually working by changing small things and seeing what the impact is.

If it does turn out that there is a bug then we can look at the source code and work out whether there is a way around the problem or if there is only one way to solve the problem, submit a patch to fix it.

I think this is probably the most important yet the simplest of the approaches.

It sounds so obvious yet it’s so easy to make change after change after change and eventually solve the problem but have no idea which change or combination of changes it was that fixed it.

We need to ensure that we know why we are making each change and revert it if it doesn’t have the desired effect.

Reading the error messages that we get and not the error message that we think we saw is yet another obvious approach but one which I have certainly violated.

Sometimes we need to slow down a bit when debugging problems and read exactly what the message is telling us and work from there.

Most of the approaches I’ve noticed seem very obvious but I find that it requires quite a lot of discipline to apply them. When I do approach debugging with this more logical approach problems become much easier to solve.

One of the best books I have read with regards to debugging code is Debugging - The 9 Indispensable Rules for Finding Even The Most Elusuive Software and Hardware Problems - I actually had the 9 rules stuck to my machine for a couple of months earlier this year, and probably should do that again.

I also noticed that the Pragmatic Programmers have a new book coming out called 'Debug It' - it will be interesting to see the similarities and differences between this book and the other one.