If your design is perfect, and your testing is perfect, there are no bugs in your code, by definition. :-)

Let's say you're debugging, and you're adding a bunch of print statements. And you keep making typos, and having to fix them, and take them out of code before it hits production, and so forth. And it's becoming a pain, and one day, you wake up, and realize that all your debugging code may itself contain bugs. Otherwise, you won't be able to find your bug properly.

One way to attempt to avoid bugs in debugging code is to limit the complexity of code you write, so that you only write simple debug and trace statements. Unfortunately, you don't know before you run the program where the problem lies, so you don't know for sure what to print out: and printing everything will often drown you in a sea of output.

Wouldn't it be nice if there were a known, tested, and reliable set of debugging code that you could use? That way, you wouldn't have to worry about typos in all those darned print statements screwing you up; you would be able to get just the output you want, as soon as you decide you want it, without having to re-edit and re-run the program over and over and over again!

You'ld never delete a line of good code while trying to strip out all those print statements you added during the exploratory stages of your debugging. You'ld never let a debug statement slip into production. You'ld get the busy work of writing the same old lines of code over and over out of the way, and just concentrate on finding a fixing bugs.

Doesn't that sound nice?

Well, that's called a "debugger", and to me, that's why it's good. It lets you do the same thing that you do with print statements, except faster and easier, and it shields me against a few common kinds of stupid, time consuming mistakes.

It guarantees that I didn't screw up a program by testing it. If you hand test my code by editing it to understand it, but claim you've made no functional changes, and then later my code breaks, the boss doesn't know which one of us really broke the codebase. If I test using the debugger, the boss knows it's not my problem, without auditing the codebase for changes and arguing over who changed what. It's one less set of diffs to run... one less thing to think about.

Single stepping through the entire program is rarely the answer, but verifying the functions down the call tree is a quite reasonable way to track down a bug.

Does the main program work correctly? No, because you're hunting a bug. Follow the following steps, and you'll probably discover your bug:

1. Look for the design flaw or coding error at this level of the code. If you see it, you're done.
2. If it's not here, look at the output of each of the subroutines called. One of them should be wrong (the bug is either at the level you're looking at, or further down).
3. Step into the subroutine that's in error.
4. Goto step 1

You can do this same thing without a debugger, but it involves writing more code, and you have to re-run the program over and over. Debuggers run code a bit slower, but you don't have to write code to see what's gone wrong, and you can change your breakpoints (ie. where you put your print statements), and what you output as you go.

It's the stupid programmers who need advanced debugging tools, and they're the ones who won't understand how to use them :)

I personally think it's kind of foolish to avoid a tool that can solve my problem faster, but to each their own. Maybe I'm just a "stupid programmer", but again, I think my boss cares less about my IQ, and more about whether I can solve the problems that make his business run. To me, a good program is one that solves the job at hand, correctly, in the budget allotted, with an eye to future business needs.
--
Ytrew