Mike Bowler uses debuggers as last resort:
I find that, for myself, relying on a debugger leads to sloppy thinking. When I start single stepping through code, I’m reacting to what individual lines are doing and I’m not thinking about the bigger picture. The debugger throws massive amounts of information at me and I’m forced to sift through it to find the tiny details I care about.
When I don’t use a debugger, I’m forced to actually think about the code rather than just reacting to it. I’m forced to think about how it works and what could possibly be going wrong.
I agree with Mike. Relying on debuggers is a bad development strategy.
Good debuggers take a lot of effort to develop, and years before they hit the market. If you need debuggers, you’re dommed to the tail end of technology. Not necessarily a bad thing, but not an option for me.
Good code is code you can troubleshoot when running in production mode on a hosted server half a world away. If you need a debugger to troubleshoot your code, how can you react to problems in real time?
Using debuggers as excuse to write sloppy, undocumented, badly structured code is not good engineering. Would you like your car to have an hydraulic self-lifting jack, or tires that don’t give up easily?
Developing a strategy for writing better code that is easy to diagnose takes some upfront effort, but pays big time in the end.
(Since Mike is talking about Ruby, I have to point out Ruby does have a debugger, and so does Rails. I just never used them, never will)
Via Raganwald.
Sterling Camden