Practical .NET
Insider: Secrets of Debugging
Faced with reviewing large swaths of other people's code, Peter Vogel is left to ask: what does it really take to be good at debugging?
Even with following a Test Driven Development regime, my code doesn't work the first time (pretend you're surprised). So debugging is a critical skill for me. Also, as a hired gun, I'm frequently having to deal with someone else's code, which often isn't working the way everyone expected it to.
One thing I have noticed: I'm better at debugging than a lot of the people I work with. My first step is to look at the evidence to make sure that I know what the problem is. A lot of people seem to feel that the first step is to SOLVE THE PROBLEM. They look at some of the symptoms, assume that they know what the underlying problem is and then start implementing a solution -- which usually means that we end up with two problems where we originally only had one. But I've already written about what I consider the essence of the debugging technique (getting a good description of the problem) and the mental tools for achieving that goal. Feel free to read it and disagree.
Lately, however, I've been reviewing a large whack of code with an eye to improving its quality and performance. That means that I've been reviewing my debugging and analysis toolkit. And that's led me to writing up some of the resources that you have available in the .NET/Visual Studio environment and may not be aware of. Those topics are so short that they don't really belong in this forum, so you'll see them turning up as weekly tips in my .NET Tips and Tricks blog over the next few weeks.
But I wonder: Can people learn to "debug better?" Or are some people just good at debugging and every else is just good at generating bugs? You tell me.
About the Author
Peter Vogel is a principal in PH&V Information Services, specializing in ASP.NET development with expertise in SOA, XML, database, and user interface design. His most recent book ("rtfm*") is on writing effective user manuals, and his blog on technical writing can be found at rtfmphvis.blogspot.com.