5 Pieces of Debugging Advice

One area that I feel a lot of junior developers can improve a lot in is debugging. When something goes wrong it’s hard to know exactly how to fix it. Hopefully this advice can lead you to an answer faster.

1. Relax and Do Some Research

When you first find a bug or a bug has been given to you, it might be the case that you’re under pressure either internally or externally to fix it. Panicing will not help the situation so try to remain calm. Remember that, whatever is happening, you can change it. It’s only a matter of how much it will cost. Right now you might think the cost is high, but you really don’t know until after you’ve done your research. Try to narrow down where you think the error might be. If you have an error message try searching google for the exact message, usually there will be several stack overflow posts. This part is usually the most unpredictable but once you find out if it’s in your code, a library you’re using, or the underlying framework, you can get more of an estimate of how long it’s going to take and what you need to do to fix it.

2. Run, Don’t Walk

When I was studying computer science in college, I’m not sure what class it was but I distinctly remember a professor telling me about for loops versus recursion. He told me to run, not walk. What he meant was to use recursion to divide the task in half instead of using a for loop. You can also apply this approach to debugging. For example, you know there is some troublesome element in an html file. Instead of commenting out each element one by one, try commenting out half of the elements. Find which half the problem is, then subdivide again. This will go much faster, especially on large problems.

3. Test Your Assumptions

Now that you’ve found out where the bug is try to read though the code with the bug. If it’s not obvious why it isn’t working, that’s ok. Try to think about your assumptions for each line. If it’s not working the way you expected, somewhere along the line one of your assumptions is wrong. One common way to test is to use breakpoints and to verify the values for everything are what you expect.

4. Discuss Your Plan of Attack

After you’ve discovered what’s wrong it might be a simple fix. If it’s not take some time to think about what the best solution is. If you’re not sure, talk with the rest of your team. There might be issues with your solution or it even might be out of scope for the timeframe you’re working with.

5. Refactor Along the Way

Hopefully the team or company you’re in has some generally understood best practices or even some coding style guidelines. If, along your journey, you see something that doesn’t conform to the general style of what you’re working with, take 5 minutes to refactor. It will help you understand the code a bit better. It will also help everyone after you, because it is now in the same style as the rest of the code base.