Why I love the debugger

3 minute read

10 years ago, still in college, I started working for a company developing real-time systems for trains in Motorola HC11 assembly. Although very interesting and challenging it was a relief to later move on to some more high-level languages, but in the end, no matter how high-level the programming language you work in, everything comes down to machine instructions and ones and zeros. There is just a bunch of stuff between you and the nitty-gritty that normally you might think you don’t need to care about until the bomb hits (your production system written in your flashy high-level language breaks down) and this is where my friend the debugger comes in:)

I have worked for Microsoft since Jan 1999, starting off supporting Visual InterDev (oh the joy of those DTCs) moving over to ASP.NET, making a brief stint in something called Solutions Integration Engineering and finally landing as an Escalation Engineer for .net. Somewhere around the time frame of when ASP.NET released and the problems were getting increasingly complex on the server-side, (since we were suddenly able to do virtually anything in web-pages), I started realizing that my current way of troubleshooting issues wouldn’t suffice. I delved into the world of debugging and my eyes were opened to a whole new world of troubleshooting. Since then, I have been evangelizing windbg (the mother of all debuggers) to anyone I meet, even some of my friends, not in the computer business have gotten their dose of “look what you can do in here, it’s amazing” while their thoughts were probably going “cuckoo, that girl really needs to get a life”

So to the point, why do I love the debugger so much? I love things that are black and white, my main interests are logic puzzles and billiards, if you get things wrong you know exactly why and there are strict rules for how you should do things. Much like this the debugger tells things in black and white. If your process hangs you can spend weeks on end wondering if your process is hanging because a database query is taking too long or because your boss installed a flashy screensaver that takes 100% CPU. The debugger will tell the ruthless truth, whether you like it or not

In my work there are a few topics that come up again and again so I decided that a blog might just be the best place to log all the tidbits that I gather along the way.

One of the worst case scenarios when you debug is that you discover a problem that requires massive re-design of the application to resolve, and/or that the system is now in production and the servers go down and the server is mission critical. Telling someone at that point that the problem could have been avoided if a different design had been chosen in the early stages of the project doesn’t do much to de-stress people, so some of the main points that I would like to impress on developers are: spend time learning the platform you are working with, spend time testing your system, spend time testing proofs of concept. It WILL pay off in the end. And!!! If you still get an unlucky break and your e-business goes down right in time for the x-mas rush, spend some time in advance on learning the basics of production level debugging so you don’t have to panic in the case of a failure.

If you have some specific areas that you would like me to talk about, don’t hesitate to tell me…

Happy debugging! May the force be with you…