Debugging 101

Source: Google

What do you think about Debugging as a Service (DaaS)? Okay, that’s not what this is about. Haha!

In computer programming and software development, debugging is the process of finding and resolving bugs (defects or problems that prevent correct operation) within computer programs, software, or systems.
- Wikipedia

Debugging arguably holds the right to be regarded as an essential part of the software development process. Little wonder why many companies list it as a skill for engineering positions. That said, you don’t want to have a lot of regression bugs.

Let’s talk about some debugging techniques:

1. Reproducing the error: This might seem natural but you would sometimes find yourself saying ‘I know the cause’, then you go ahead to fix it without reproducing. Superhuman mode activated. The issue with that is that you might fix one of many possible scenarios which you might have caught if you reproduced the error.
   Reproduce the error on the same environment as the bug reporter (with the same permissions & privileges if applicable) and then on your local environment.
2. Understanding the error message: The error message usually suggests what the culprit is and the type of error raised. For instance, a no method or undefined message suggests that you’re referencing a variable or method that does not exist in the context.
   You might also see a line reference on the error message.
3. Tracking down the culprit: You want to get to the erring LOC. Usually, the stack trace would give you loads of context. The erring line would typically be at the beginning or end of the stack trace. Sometimes, you may need to log your program in verbose mode if that’s not the default.
4. Using a debugger: You’ve tracked the culprit (good cop), but you’re wondering why it’s not behaving as expected. A good step is to print the output of that line to the console to see what it is in runtime. An even better step is to use a debugger. A debugger would typically be interactive and allow you to step through your program one line at a time.
5. Choosing a solution: The most obvious solution is not always the best but the simplest solution could be the best. Take some time to consider different approaches to solve the problem. Think about the complexity, pros and cons of each. Pick the one that best solves the problem. You do not want to over-engineer but you also do not want to pick a solution that has many obvious backdoors.
6. Testing: Usually, it is easier to reproduce the bug with a spec and fix. Whatever pattern you prefer, you should have specs for your code. It would save a lot of stress and expose many loopholes.
7. Validation: Yes, you have some specs for the code you’ve written but that does not take the place of a human using your fix. You should be the first human to validate your fix, even if there is someone else who’s designated for QA. You don’t want to say ‘Bug X is fixed’ only for someone to check and say it’s not.
8. Fixing the root cause: Sometimes, ‘fixing the bug’ to a user might be resolving their pain point. You might be able to do that without actually addressing the root cause of the bug. For example, a user is unable to login because they are told that their account is not confirmed. This is due to a bug in your confirmation flow that prevents the confirmation email from being sent to the user. In order to quickly deliver user value, you confirm the user’s account behind the scenes. From the user’s perspective, the issue is resolved. However, if you do not get to address the confirmation flow issue, you’d soon be getting 100x support tickets if your app is a fast-growing one.
   You should also document the root cause of the bug, it could be valuable if you need to know where a percentage of your team’s bugs are coming from.
9. Communication: This is easily omissible for an engineer, especially if all you care about is to ‘write code’. What is the benefit of code that is written and nobody ever uses? To close the loop on the debugging process it is important to inform the bug reporter about the fix. It also provides you the opportunity to get early user feedback.
   If there are steps they need to follow, you want to document those or go a step further by demonstrating the process via screen recording.

This is the first part of an intended two-part series on the topic. I hope you got value for your time. See you next time 👋