Re:Debuggers are for Losers
by bunderbunder on Monday July 23, 2012 @10:07AM
(#4281008)
Quick quiz:
You've got a unit test that just failed. It's not immediately obvious what's going on, but it's possible some assumption about possible states your program can be in at this point turns out to be incorrect. In order to diagnose it in more detail, would you rather. . .
a) Start guessing at possible causes, and cycle through iterations of writing print statements to check for them and then running the program to see their output until you make a correct guess.
b) Start guessing at possible causes, and cycle through iterations of writing Assert() statements to check for them and running the program to see if anything throws until you make a correct guess.
c) Set a breakpoint, fire up the program, and take a peek at the program state at the point where the test fails in order to get an immediate and complete picture of what's going on in there.
d) Spend two hours stepping through the code one line at a time, and a further four on Google Image Search hunting for pictures you can use to pepper the blog post blaming the debugger you could stand to learn to use more effectively for your productivity problems.
You've got a unit test that just failed. It's not immediately obvious what's going on, but it's possible some assumption about possible states your program can be in at this point turns out to be incorrect. In order to diagnose it in more detail, would you rather. . .
a) Start guessing at possible causes, and cycle through iterations of writing print statements to check for them and then running the program to see their output until you make a correct guess.
b) Start guessing at possible causes, and cycle through iterations of writing Assert() statements to check for them and running the program to see if anything throws until you make a correct guess.
c) Set a breakpoint, fire up the program, and take a peek at the program state at the point where the test fails in order to get an immediate and complete picture of what's going on in there.
d) Spend two hours stepping through the code one line at a time, and a further four on Google Image Search hunting for pictures you can use to pepper the blog post blaming the debugger you could stand to learn to use more effectively for your productivity problems.