Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The guy here who says not to use debuggers is just full of posturing, macho crap. The purpose of a debugger is to understand and visualize the behavior of your code. Step 1 (understand and document your code) there is a fine and useful thing to do, but I'd rather outsource some of the code-tracing to a debugger rather than taking up mental cycles doing it myself. A debugger is a means to that end.

Step 3 and 4 (use asserts and logging) are also pretty great, but with a debugger, you can do nonce asserts and observations as you trace through the code rather than trying to guess at the beginning of every compile cycle what needs to be asserted or logged. If you want to assert and log everything a debugger might catch, you're just insane. I'm not logging every state change as it happens.

Step 2, 5, and 6 are refactoring, unit testing, and code review. I am all for them, but they don't always solve the same problem as debugging. I'd rather give up debugging than give up refactoring, unit testing, and code review, but no one says you have to.



I'd put it this way: If you find yourself spending significant time inside a debugger, you should probably rethink how you (or your teammates) have been developing code. Time is certainly better spent preventing bugs with unit tests, asserts, thorough documentation & thoughtful design.

That said, on the occasion when a bug does crop up (which will hopefully be rarely), the debugger is usually the fastest way to find the problem. A good programmer will be sure to root cause the problem rather than fixing the symptom. Debuggers are indispensable tools for working up the causality chain.




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: