Part I: Principles of Debugging
As fate would have it I run into fellow developers all over the world. For example, I traveled all the way to Buenos Aires to study Spanish and get away from the tech-centric bay area and its ubiquitous engineers; ironically on the first day of my Spanish class I sat next to Rob, the software developer, from Chicago. When our teacher asked us what we did both of us remarked that we were developers, only Rob responded that he hated it, while I being the ode-to-code writing femgineer remarked with alacrity, “I love it!”. I later asked Rob why he was despised coding, and his only response was, “I hate debugging.” I wouldn’t say I hate debugging, its just part of the job description, and since I love being a software engineer I treat debugging as a necessary activity.
However, I can empathize with Rob. I remember writing my code as a freshman, and absolutely abhorring debugging even 100 lines of code! I knew how to use GDB and DDD, but I still didn’t like that my program wouldn’t just work after I compiled it. My hatred for debugging reached its peak when I had my first job, and the software program was over a million lines of code. I couldn’t stand sitting in my cube, and being told to debug a bug that I hadn’t even written! Most of the time the authors had poorly commented the code, and had left the company years ago. But I would trudge through it, and try to figure out what was going on.
It wasn’t until I was at a startup that I began to learn how to debug properly. At a startup everything is top priority; bugs, features, scalability, performance, etc. There is no time to whine or solve a problem sloppily, because 99% of the time the bug will come back to haunt you, and there just isn’t anyone else around to fix the bug. So I had to roll-up my sleeves and learn the number one principle of being a good debugger: patience.
Stepping through code in a debugger can seem monotonous, but its one of the surest ways to figure out whats causing the bug. There are times when patience can run out, which in my experience is also the point when the debugger become futile. With a look of defeat and anguish on my face I would approach my boss. Instead of telling me to try harder, he taught me the second principle to being a good debugger: understand the problem or use case, and think about how other areas of the code or things might affect it. Basically, this means that the bug not exist in your code, and its probably being triggered by code in a different module, system, or process. To find the cause of the bug requires understanding the intricate details, and architecture of the system you are working on. This does not have to be a one man effort, because no one expects you to know everything about the code base, even if you wrote it all yourself! This leads to the third principle: communicate with others. But before doing this I would recommend going back to principle #2 and trying to hypothesize where you think the bug might have originated and formulate a hypothesis. Could it be in some other code, the framework you’re using, a language construct, or even the IDE? Narrowing the scope of the problem first, and talking about the methods you’ve used to debug will foster better communication. Keep in mind your colleague has to understand you in order to help you debug.
The final principle is intuition, intuition, intuition, which can only come from experience. So while debugging a really tough bug today might seem like druggery, you might see the same issue again tomorrow, six months from now, or even years down the road. While the same solution might be applicable often times it might not. However, recalling the old bug will do two things for you: one it will help you remember the context and the code space you dealt with before, so you won’t have to re-learn it. Two, spotting the pattern puts your mind into the frame of thinking that you used before to tackle the problem, which will save you time, and give you confidence when it comes to tackling the current bug.
Part II: Motivation
Part III: Time to solve the mystery
