Electronic flyswatter: The Art of Debugging

Among the less popular things about programming in general is debugging. It is a hassle to most people I know, yet an essential skill to master.

The first step to find a bug is to think while coding. Hacking away without reason and just grinding code without exercising your brainmuscles is futile. Believe me when I say that a well thought through codeflow is saving you quite some headaches in debugging.

Before you start coding make yourself a clear picture of what you want, how it should look and how it should flow. Expect that to be hard :)
Do whatever helps you, don't rely on what others tell you too much, as there is no perfect way. Use what works for you.. diagrams, UML or Post-It notes. It saves you time and gives you an overview of the program-to-be.

Step two is translating that into code. Here I mostly choose to have my own collection of ironcode. WTF? 'Ironcode' is code I use all the time, well tested and throught through (...ehhehe... in most cases well though through). It minimizes the possibility of errors... most of the time :)
KISS. Keep It Simple Stupid. Don't optimize too much. It is easier to get a working program to run fast than a fast program to run.

Avoid one-liners in the first iteration. I love oneliners like:
string ASCII = Encoding.ASCII.GetString(Encoding.ASCII.GetBytes(srLogFile.ReadLine()));
While it surely is not the most complicated thingy to do, it is surely stupid to do that untested. Try, for debugging, to split that into three or more lines. It is easier to debug (yes, and to read, I hear you, but maintenance programming is another topic).
When your code is ready to be shooed out of the sandbox, you can always tighten up things.

Step three is 'Know your tools'. Know your tools. Know how the debugger works, when to hit which key and watch your locals. Locals is your friend, the callstack tells you quite a lot about what happened before you crash.. or did not crash.. also a possibility in a multithreaded environment.
Speaking of which.. create a decent logger that is alive in your debug build. In most of the cases you cannot just 'stop, drop and roll' your program, e.g. Games. There a good logger is making your live a lot easier.

Step four is 'know the 'usual suspects''. I, when programming, have a list in my mind of those things that can go wrong. I build and test every function I create for obvious errors then stuff in a few lines of loggingcode to be prepared.

And the last, most important, step: 'Don't give up'!
See it this way: At least you have the sourcecode, you know the one who committed the cirme and you know all the things that sourround your program. The worst thing that can happen to you is reverseengineering buggy code with not the slightest idea what that program needs... believe me.. been there, done that, got the T-Shirt.

All in all this is not the yellow brick road to follow in debugging. Never thought of it that way, but it should take away the highest hurdles. Of course it is easy to say such things while having quite a bit of experience in that field. As always. But then... I also started sometime... heheeh... most people forget that...