5 Essential Tips to Debug Any Piece of Code
By: Samuel Martins
Tags: Software Development, Debugging, Technology, Programming, Web Development

Yes, here I go again with the bugs. Bugs are still one of the most frustrating things to encounter when you are coding. I know I find them frustrating to some extent. All you coders out there will agree that there is nothing quite like building something that you think will work only to have it break in front of your face.

But, do not get me wrong: bugs are not entirely terrible. You can always learn a thing or two when trying to debug any program. Some of the most rewarding experiences I have had involve fixing a nasty bug. That feeling you get when you watch it melt away at your fingertips is priceless. There is a famous phrase that goes like this:

“If debugging is the process of removing software bugs, then programming must be the process of putting them in. — Edsger W. Dijkstra”

It is pretty snarky, but I agree with the fact that most programs are not without bugs.

It is tough to know every scenario and state that your code will be running when you are writing it. Because of this, bugs are a natural side effect of coding. Unfortunately, that does not make it any less frustrating to deal with said bugs, especially if they are responsible for completely breaking your program.

With that said, there are skills and methods in debugging that help make the process go a little smoother. In this piece, I will share five of my tips on how to debug easily. Most of these tips come from David J. Agans’ textbook “Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems.” Some of them are from my experience dealing with bugs. Let’s get into it.

1. Reproduce the Behavior Consistently

Reliably reproducing bugs is half the battle. You have a much better chance of identifying and fixing a bug if you can reproduce it the same way every time. When you identify a bug, do not even think about the code that might be having the issue. Just think of the code as a black box and figure out what inputs may have caused the bug. Once you can reproduce it, shorten the steps it takes to reproduce it. Think of the simplest thing that you could do to make the bug appear. This helps reduce the number of variables when you are trying to fix the bugs Simplify, simplify, simplify. Once you can reproduce it, write down the steps on how you did that, especially if there are a lot of them. You will be glad that you did, in case you forget.

2. Divide and Conquer

Given that you can reproduce the bug consistently, you now have to figure out which part of the code causes the error. This is where you have to try to go deeper into a specific area of the code. One to five lines of code is about the level of accuracy that you should be trying to achieve. So, where do you start? Well, depending on the codebase and your level of fluency with it, you might know right away.

In case you do not, I have some steps that may help:

First, find any strings that you can search for. For instance, there might be a string literal in the UI, or maybe the error message is unique. Search that entire codebase with that unique term. You will get a sense of what neighborhood or part to focus on.

Second, ask your team members where to look, in case you are working with other people on the same codebase. They will not think less of you, I promise. Trust me, doing this will save a lot of time.

Lastly, set breakpoints and print statements. This is especially helpful if you have already narrowed it down to a general area of the codebase. Set breakpoints and place print statements in different parts of that area to get a snapshot of the values and states that could give you a better idea of where the bug could be.

3. Survey the Landscape

After narrowing down a general area of the codebase, go through the code within that area. Getting a thorough understanding of what the code is doing allows you to make a well-informed change so that you don’t cause more bugs as you try and fix one bug. So, make sure to read the code carefully and figure out answers to questions that may pop in your head. Why was it written like this? When does a specific line of code run? Why is that variable or function necessary in that implementation? If there was an error message, then read that very carefully too. Question your assumptions — because you may be making some assumptions about the code that may not be true.

Another trick is to pin the timeline by looking at various paper trails. What were the changes made since the last time it worked? Take a look at your version control history. At this point, you are acting as a detective for what went wrong. Do a role play if you will. Anything that makes you understand the code is worth the time. Logical thinking is one of the skills that you need to hone for this part of problem-solving.

4. Make Changes One Step at a Time

Speed and efficiency are good qualities to have as a coder. When it comes to dealing with bugs, however, you need to be thorough.

“Bugs are delicate.”

Frustrating but delicate nonetheless. Changing too many things at a time won’t help you pinpoint the issue. You can even decide to change just one thing, then run the program to see if the bug behaves the same way. Change something else and rerun the program. Rinse, lather, repeat.

If it is possible, create a code sandbox. See if you can replicate the same bug by pulling that part of the code into something uncomplicated. It could be a standalone program, an app, a class, or whatever makes sense for your environment. That gets rid of all of the other variables. Doing so will help you concentrate on that part of the code, and it makes it easier to change only one thing at a time by getting rid of all of the other distractions.

5. Get a Fresh Perspective

Have you ever been stuck for hours or even days trying to fix the same thing that you can no longer tell if you are hungry or thirsty? It is crucial to know how to recognize when you are in this state because, after a certain period, it is actually harmful to hammer at the same thing with no results.

Albert Einstein said: “The definition of insanity is doing the same thing over and over again and expecting different results.” With that said, take some time off and get fresh eyes on the bug. If you are working on the same bug for longer than a day, it is time to take a break and look at it from a different viewpoint.



You can even try and get input from your friends or colleagues. Your friends can introduce you to new perspectives or new problem-solving methods that you may not have considered before. I know it is tough, but do not be afraid to ask for help. Teams are better when everyone can work to fix problems together. Whatever lessons you take away from this bug can be shared with somebody else. Sure, it might take more time to fix the bug, but it will be OK. If you are an introverted person, go the rubber ducky way. I do this all the time! Thinking out loud helps a lot and clears your train of thought.