3 ms·

How do you judge you are better? What criteria are you using? Also, everyone gets better with time - do you have some type of control that shows you may not hav

How do you judge you are better? What criteria are you using? Also, everyone gets better with time - do you have some type of control that shows you may not have been better by now using a debugger?

larrywright 18y ago
It's completely subjective. I don't develop for a living at the moment - I'm a program manager these days. At my day job, I do one off scripts, plus the occasional prototype. I do however work on a number of side projects, mostly in Ruby, where I try out the latest practices: TDD, BDD, etc. I base my statement on my own perception of my abilities, and I certainly don't attribute it fully to my not using a debugger anymore. I've learned a lot, and gained experience. That experience enables me to solve problems more quickly, as it's much more likely that I've seen an error (or something like it) before. I've had more exposure to good code, both internally as well as many of the open source projects that I've looked at. Seeing how other people solve problems also makes you a better programmer. I've also seen a lot more bad code, and thus know which things to avoid. My opinion on debuggers is also subjective. I just know that when I used one in the past, it tended to cause problems (though I didn't realize it at the time). You set a breakpoint, step through some things, find a problem and fix it. But this doesn't generally lead to an understanding of what caused the problem (simple logic errors aside), and in fact can insulate you from larger design issues that need to be addressed. You fix a bug here, modify a line of code there, without taking a step back and looking at what the code is doing, and whether or not it needs to be refactored. This isn't to say that you can't do those things with a debugger. My point is that debuggers seem to enable certain bad habits, while skipping the debugger and relying on analysis, unit tests, and debug statements seems to encourage some good practices. All I can say is give it a try - next time you want to reach for the debugger, write a unit test to recreate your problem, and use some debug statements to try and solve it. If it works for you, great. If not, go back to the debugger. YMMV.

How do you judge you are better? What criteria are you using? Also, everyone gets better with time - do you have some type of control that shows you may not have been better by now using a debugger?

larrywright 18y ago

It's completely subjective. I don't develop for a living at the moment - I'm a program manager these days. At my day job, I do one off scripts, plus the occasional prototype. I do however work on a number of side projects, mostly in Ruby, where I try out the latest practices: TDD, BDD, etc. I base my statement on my own perception of my abilities, and I certainly don't attribute it fully to my not using a debugger anymore. I've learned a lot, and gained experience. That experience enables me to solve problems more quickly, as it's much more likely that I've seen an error (or something like it) before. I've had more exposure to good code, both internally as well as many of the open source projects that I've looked at. Seeing how other people solve problems also makes you a better programmer. I've also seen a lot more bad code, and thus know which things to avoid. My opinion on debuggers is also subjective. I just know that when I used one in the past, it tended to cause problems (though I didn't realize it at the time). You set a breakpoint, step through some things, find a problem and fix it. But this doesn't generally lead to an understanding of what caused the problem (simple logic errors aside), and in fact can insulate you from larger design issues that need to be addressed. You fix a bug here, modify a line of code there, without taking a step back and looking at what the code is doing, and whether or not it needs to be refactored. This isn't to say that you can't do those things with a debugger. My point is that debuggers seem to enable certain bad habits, while skipping the debugger and relying on analysis, unit tests, and debug statements seems to encourage some good practices. All I can say is give it a try - next time you want to reach for the debugger, write a unit test to recreate your problem, and use some debug statements to try and solve it. If it works for you, great. If not, go back to the debugger. YMMV.