The software development field is filled with bad ideas. For instance, have a look at this - "debugging 101", which advocates against using a debugger. I wonder if he thinks the compiler is a crutch too, and that "real men" just use ASM. It's too bad, because the rest of the article is pretty good, and filled with good advice. Here's the bad fixation:

In general, I recommend you avoid symbolic debuggers of the type that have become standard in many IDEs. Debuggers tend to produce a very fragile debugging process. How often does it happen that you spend an extended period of time carefully stepping through a piece of code, statement by statement, only to find at the critical moment that you accidentally "step over" rather than "step into" some method call, and miss the point where a significant change in program state occurs? In contrast, when you progressively add trace statements to the code, you are building up a picture of the code in execution that cannot be suddenly lost or corrupted. This repeatability is highly valuable - you're monotonically progressing towards your goal.

Yeah, print traces are so much more useful, and so much easier to deal with. We couldn't possibly do a progressive narrowing of scope with breakpoints. Heck, I finally tracked down a bug in the network library we use in BottomFeeder yesterday - by progressively narrowing the scope of the search with breakpoints. I have no idea why this guy thinks debuggers are bad - I'd guess it's just that in his experience, the tools suck. Maybe he should find his way all the way into 1980's era technology, instead of hanging around in 1975. Here's what he advocates most of the time, with a few caveats about debuggers maybe being useful under some circumstamces:

This is the principle debugging method I use. A trace statement is a human readable console or log message that is inserted into a piece of code suspected of containing a bug, then generally removed once the bug has been found. Trace statements not only trace the path of execution through code, but the changing state of program variables as execution progresses. If you have used Design By Contract (see below) diligently, you will already know what portion of the code to instrument with trace statements. Often it takes only half a dozen or so well chosen trace statements to pinpoint the cause of your bug. Once you have found the bug, you may find it helpful to leave a few of the trace statements in the code, perhaps converting console messages into file-based logging messages, to assist in future debugging efforts in that part of the code.

Interestingly enough, the article is otherwise filled with good suggestions. If you get past his fixation on debuggers being a problem, it's worth reading.