The best debugging technique is not to have any bugs. As unrealistic as it seems, when our test steps are small enough, we very rarely have bugs , and when we do, we encounter them quickly and resolve them quickly. Its fairly easy to program for five minutes without writing a bug. An hour ? Im just not up to it.
When we do encounter a defect, if we can back up a short distance and start over, it usually pays off. As you have seen here, its difficult to do thatI always want to find the bug. Yet you have also seen here that when we did start over, things usually went better. Its good to have a pair at these times your pair is more likely than you to be ready to start over and will usually have a good idea on another approach.
Beyond starting over, however, there is debugging. As youve seen, Im more inclined to write some information to the console than to use the debugger. Its not just that Im a Luddite: I know that once I get into the debugger, too often I spend a lot of time there. My mother always told me not to hang out with bad companions, and for me, the debugger smokes, drinks, and shoots pool in sleazy dives, so I try not to spend much time with him.
When we need it, the debugger is a powerful tool. I wish, at least a little, that I knew the Visual Studio debugger a bit better. A little more facility with it might have shortened some of our stays in the debugger and might have reduced some of our need for tracing. Ill put learning about the debugger a bit higher on my list of things to do.
Still, I try always to remember something that a wise manager told me a long time ago: I never hire anyone who tells me in the interview that hes a really good debugger. Theres only one way to get to be a really good debugger.