3 actionable tips on how to become better at solving programming bugs

I’m assuming you are here because you want to improve your skills at solving programming bugs.

The short version of accomplishing that is to just start… solving… programming bugs.

LOTS of bugs!

That’s it!

That’s all you have to do!

Now I’m going to guess that you are a bit disappointed with that answer, right?!?

Okay, okay… I’ll tell you the longer version.

Just note that the key to get good at anything in life is to do a lot of it. And this skill (problem solving) happens to be one of the 5 most useful skills to have as a developer. There is no secret, or pill that you can take, which will suddenly make you good at solving programming bugs.

Simply practicing is the magic formula. With time and experience, you’ll get good at it.

But what are some good habits to develop that would greatly help you along the way?

Make sure that you understand the problem (and gather enough intel)

Oftentimes we may rush, or jump to conclusions, about a specific bug/problem and solve something that isn’t even the problem.

I’m not even joking with this!!

I kid you not that a person I once worked with, had “fixed” a bug to what he had thought was the issue. But if he had actually read the task description and understood the problem, he would have realized that he didn’t actually fix the bug.

He had just developed a whole new feature!

Epic fail!

So you may be a brilliant and experienced developer, but if you can’t read, or understand the problem, there will never be any hope for you!

Yes, yes… I know. Technically he did solve the problem as it worked and wasn’t broken anymore! It was just not in the correct way that the original design behaviour had specifed.

Oops!

I’m hoping that my point came across to you. Understanding the problem is critical to solving it properly.

When you can do that and are in time restrained, or higher pressure, situations like attending some cool hackathon or startup events, you will be able to successfully navigate through your programming problems.

The first step is to always understand the problem!

Once you understand the problem, or if you have no/limited information about it, it’s good to “ask yourself” some deeper questions regarding it.

You might be thinking… well what do you mean by that David?

I mean… questions like this:

• Does the issue only occur on desktop? Or does it also occur on mobile devices? Is it reproducible on multiple browsers, or is it browser specific?
• Does it happen only on initial page load? Occasionally? Or does it consistently happen every time?
• Does the page crash? Are there any errors in the console or network tabs?
• Is the scope limited to a specific aspect of the page? Or is it in general on that page? Or is it everywhere that aspect is displayed over the entire website?
• Did it previously work and get broken after some recent code changes? Or was it overlooked (as in an edge case that wasn’t considered)?

Woah… that’s a whole lot of questions to ask!

Yup, but the more you know the easier it is to solve the problem. The key is to ask questions that help you identify the behaviour of the bug. To figure out the when and how it is happening.

Then you can move on to figuring out where it is happening!

Narrowing down the scope

This one is simple! You want to figure out what sort of issue it is and keep narrowing it down as you cross off your potential guesses at what the issue might be.

Some bugs will be obvious to you and you won’t have to go through such a procedure. You just know what the issue is almost right away. This is especially true when it comes from either past bug experiences or just from knowing/understanding the code around the feature well.

Usually the person who wrote the code for that feature will be able to figure out the issue in a fraction of the time compared to someone who is unfamiliar with the code and implementation details.

This was exactly true in my current job.

I had accidentally produced a bug in another area of the website project I work on, when I merged one of my tasks. The next day when someone had discovered the issue, a few developers had spent the afternoon looking into the bug.

While they correctly identified the line of code that was causing the issue, they were scratching their heads why it was happening.

So they had reached out to me and within half an hour I had already figured out the issue and the PR fix was open.

If they had tried to figure it out on their own, they would have taken much longer because they were not familiar with what I was trying to fix in my original task. They also did not have the same level of understanding of what the problem was as I did. Plus they didn’t know about all the quirks in the codebase around that section either.

So usually the best person to solve it is the person who knows the most about it!

Now, how can you narrow down the bug to get something specific. The easiest is to start by asking yourself broad, general questions like the following:

• Is it a front end (FE) or back end (BE) issue?
• Is this a styling/CSS related issue?
• Is it JavaScript? Or is it related to a FE framework library like React?
• Does it have to do with fetching or retrieving data (API calls)?
• Is the data that is sent to the client (on the FE) correct? Or is it wrong/missing information?

Asking questions like this will help you narrow down the scope to a more specific area. You want to do this and eventually narrow down the scope to a specific component, or a section of code lines.

Oftentimes when you run the project locally, and reproduce the bug, you will see an error message printed in the console. This can massively help you identify which file, and line of code, is causing the issue.

Sometimes you don’t get that feedback, because the code doesn’t “break” the site. It behaves differently to what was the desired behaviour.

This is when you need to be an inspector gadget.

If you have no error messages, you need to figure out if anything bad is happening in the network tab, with any network requests. This would signify an issue with the data that comes through to the client (the FE).

Otherwise (if you are working with React), you need to figure out what component is on the page and where the logic comes from. Looking at the React components tab in Chrome devTools (you would need to first install the React Developer Tools extension) will really help you to figure out the component tree structure.

Alternatively, you can also look at the HTML markup by hovering over the problematic area and seeing what the name of the element on the page is. Not always, but on certain projects the name of the component (that the element is from) will be shown there. This makes it easier to start searching within that file inside of your IDE.

Once you have some kind of idea of where the code lies that might be responsible for that feature around the bug, you need to figure out one more thing.

Which is asking yourself, why is it happening?

The debugger becomes your best friend

Assuming that you are debugging with Chrome devTools (because who isn’t?!?!) then you better be comfortable using this.

It is a highly powerful and important developer tool in your toolkit.

Alternatively (or combined together) you can also use simple console.log statements to give you feedback on what is happening when the code is getting executed.

When you need things to go slower and you aren’t really sure what is going on in the code, it’s best to set up breakpoints. This allows you to go through the code step-by-step with actual values.

This can be achieved by either adding debugger; lines into your code file directly, or manually putting a breakpoint in from finding the file in the “sources” tab within devTools.

This lets you see if the breakpoint gets triggered, and if it does, the window will go into debugger mode. From here, you can start a deeper analysis and hopefully have a better understanding of why the code is behaving in the way that you don’t want it to.

Sometimes this can be straightforward in helping you find the problem, but other times you don’t get anywhere.

In such cases, it may very well be that your original assumptions were incorrect. As in some outside source (ex: external CMS system), or maybe some disconnect from the backend to the frontend, would be the real culprit.

Other times it can be due to your lack of understanding of how the architecture, or higher level aspects of the codebase work.

Or maybe you were looking in the wrong spot, and you haven’t found the correct location yet.

And if you can’t figure it out by this point on your own, assuming you’ve already spent a reasonable amount of time trying to figure it out, then it is best to ask for help!

As there is no point “suffering” endlessly trying random things. It only makes you frustrated and stressed out.

If you are working full-time at a company, getting help is easy to do. All you have to do is ask a colleague!

When you are on your own, this is harder. However, there are a lot of good developer communities around and someone is always willing to help you solve your problem. Especially if you can explain/describe it well!

Final Remarks

In summary, when you are trying to debug an issue you want to make sure you do the following things:

• Make sure you understand the bug/problem well.
• Narrow down the scope of the problem until you get to a specific portion in your code base.
• Use the debugger tool (and/or console.log statements) to help assist you in solving the problem.

And if you just can’t figure it out… ask for help!

It is my hope that these tips will give you a better approach when solving programming bugs. That way the next time you encounter a bug in your code, you’ll be able to better squash it!

---

Once you get good at this and if you also have an interest in entrepreneurship as well, you could consider joining me on a challenge to build a SaaS business within 1 year. Doing something like this you will for sure get practical (and real world) experience at solving problems, programming bug and just develop your overall skills.