What do you need a debugger for?

In my many years of experience in programming I have noticed that there are some programmers who refuse to use a debugger, or try to use the debugger as little as possible, as in, only when they run out of alternative options. They tend to rely solely on the diagnostic log to troubleshoot problems in their code, so their code tends to spew thousands of lines of log entries per second, and they keep trying to divine the causes of exceptions by just looking at post-mortem stack traces.

Quite often these people do not understand what usefulness others find in debuggers.  I once requested the lead developer of a certain shop (Powernet, Athens, Greece, circa 2000) to enable debugging for me on their development web server so that I can run my debugger on the web site that I was developing in that shop, and she asked me "what do you need a debugger for?" Luckily, she proceeded to fulfil my request after a couple of long seconds of me staring blankly at her.

Listen folks, if you want to be called a "programmer" and if you want to be worth the cost of the keyboard you are pounding on, the debugger needs to be your absolute first tool of choice at the slightest need for troubleshooting, not your last tool of choice, not even your second tool of choice. Companies that develop IDEs go through huge pains to provide us with nice sleek and powerful debuggers so that we can do our job better, don't you dare let their efforts go to waste.

A call stack trace in the diagnostic log of your program will tell you which function was called by which function, and that's all.  This is enough in many simple cases, but when things get just slightly complicated, (and they usually do,) it is not enough.  Lacking any additional information, what you end up doing is theorizing about what might have happened instead of looking and seeing what has happened.



In addition to which function was called by which function, the debugger will also show you the values of the parameters to each call, and the values of the local variables within each call. For any variable which is an object, the debugger will show you the contents of that object, so in essence you have access to the state of the entire machine at the moment that the exception was thrown. When you have all that information at your disposal, then you can say that you are solving a problem. Anything less than that, and what you are actually doing is monkeying with the problem.

Similarly, in my career I have noticed lots of people who, when they want to perform a test run of the program that they are developing, always hit the "Run" button of their IDE instead of the "Debug" button.  Listen folks, if you want to be called a "programmer" then the button you should be pressing is the "Debug" button. You should forget that the "Run" button exists. "Run" is for users.  Programmers use "Debug".  Always "Debug".  Only "Debug".

Starting your program in debug mode does not mean that you are necessarily going to be doing any debugging; it just means that if some issue pops up during the test run, then you will be able to debug your program on the spot, rather than having to rely on the diagnostic log, or having to re-run the program in debug mode hoping that the issue will be reproducible.  Modern development environments even support program modification while debugging, (they call it "edit-and-continue" in the Microsoft world, "hot swap" in the Java world,) so if a small problem pops up you might even be able to fix it on the fly and continue running.

If you don't want to take my word for it, you could take a hint from the key bindings of your IDE.  In Visual Studio the description of the F5 key is "Run the application" while the description of Ctrl+F5 is "Run the code without invoking the debugger (Start without Debugging)".  As you can see, "Run the application" in Microsoft parlance means "Debug the application", and the key combination for debugging is the simple one, while the key combination for running without debugging is the more complicated one. Similarly, in Eclipse, F11 is "Debug", Ctrl+F11 is "Run". In PyDev, the same. Obviously, the creators of these IDEs expect you to be running your program with debugging far more often than without.  For me, it is 99.99% of the time with debugging, 0.01% without.

Some people complain that application start up is slower when debugging than without; I have not noticed such a thing, but what I have noticed is that sometimes one might be making use of some exotic feature of the debugger without realizing it, (for example having forgotten a so-called "function breakpoint" or a  "memory changed breakpoint" active) and that is slowing things down. Just make sure you do not have any fancy debugger features enabled unless you actually need them, and running your program with debugging should be about as fast as running it without debugging.

Related article: michael.gr - .Net code running faster under the profiler?