How to improve your debugging
Debugging is one of the most important skills you require as a developer. Reason being, you will have many bugs and you will never write perfect code.
There are a number of techniques you can use to improve your debugging. For myself, this made a huge improvement in my life when I took the time to learn a bit more about debugging. In this article, I won’t focus on debuggers and IDEs because I don’t want to provide advice that might not work in your environment or your technologies. For example, a big IDE such as any JetBrains IDE will give you excellent debugging tools, but VS Code requires a bit more setup. Instead, I will discuss techniques of debugging that can help take you to the next level.
Patience
This was the number one tool that helped me become a better debugger. I’m not kidding when I say patience is the best tool for debugging, it truly is. The reason for this is that the moment you let stress and frustration rule you, your debugging becomes ten times harder. Keeping patient allows you to focus, take the process step by step, and allow you to observe the issues with an open mind. Shifting your mindset from “I will never get this, this is awful” to “I’m curious as to why this is happening, this is very strange, let's find out what is happening”. Taking this perspective reduces the stress, and reduces the frustration you have around this issue. You will solve it, it’s just a matter of time before you do.
Getting angry won’t make you solve it quicker, it will probably make it take longer. Remaining calm opens your mind up to the possibility of solving it, to focus on the problem at hand. It’s very hard to remain patient when the bug has taken you hours or days. However, if you can manage to keep your emotions in check, it pays dividends.
Step by step
You must become methodical, like a robot, step by step until you solve the problem. Early days I had a tendency to jump around, and I still do. I’d jump from line to line, file to file, this meant that I would miss a lot of things. I would think “it can’t be this, so ill skip it”. Then it turns out it was that thing I said it wouldn’t be, which I could have solved hours ago. I’d also forget what I had tried and what I hadn’t. Take your debug step by step. Start from the top, the very start of your program, and note down all the new additions you made. Then one by one, comment out the code until the bug stops happening. When you note that it isn’t happening any more re-comment in the code and that's the area it is in. That is usually how I figure out what is going on.
Another technique, which applies to bugs where you have no idea where it could be coming from, is to put breakpoints at each stage or console logs. Observe the system at each point, noting what the data is, what is happening and if you use console logs, each log statement should have a clear name to make it easy to read. As you observe the data moving through the system, you can see where the data changes from one form to another. Here you might make a discovery, the data suddenly changes to the wrong thing at a certain point. Thus, you can comment out some code, then observe its working or at the very least your descriptive log or breakpoint, shows you the area of code affected. You can use this technique when you’re figuring out a new codebase as well. Watching how the data flows through the system is a great way to learn how all the pieces fit together.
If your environment and language supports breakpoints you should be using those over console logs, but not everyone has them set up in projects, especially in the frontend space. If you’re using React and VS Code, you can see how to set this up here.
Debugging is a very slow process, you must become a robot in how methodical you are. One of the best debuggers I have seen was a robot, indistinguishable from a robot, so much so that he may as well have been the computer. At each tiny step he would change something to see what was happening, it could be a breakpoint or a console log or hard code a value to see how that affects the system. At each step he would note down what happened, never moving fast, always one tiny step at a time. If a thought popped into his head he would note it down to try later but until he had observed the system from start to finish, identifying where the issue was happening, it was step by little step. This meant that any bug, no matter the difficulty, was always within his grasp. Furthermore, he kept a cool head at all times, in fact, he enjoyed the bugs. The harder the bug, the more fun he had. Ultimately, this resulted in him being able to solve any bug whilst remaining calm. It was something special to watch.
You, too, can become better at debugging, and mostly it’s taking the process step by step, remaining calm and thinking clearly. Write down with pen and paper your thoughts, this puts your thinking on page, clarifies it. It also keeps a record of what you have tried and what you might have left to try. I find that it’s often the times I go to explain the problem to someone else that you figure it out, or you figure out a new approach to try. Writing this down is a good way to hash out your thinking.
If you take these steps when debugging, you will instantly see an improvement. Debugging is mostly about staying patient and being methodical. It’s as simple as that. The best debugging experiences I have had have been taking it step by step. The worst is when I jump from file to file, with no process. Create your own debugging process, your own ritual if you will. This will make the experience a lot easier and more enjoyable.