Posted on July 31, 2021
Original post is here.

This article is the second part of How to be A Pragmatic Programmer. The first part is here: How to be A Pragmatic Programmer: Part One (1).
So if you are a programmer or developer, you must have heard that “your code is not working, it has bugs!”. And then you got angry and you supposed to make a plan to kill that man who told you that. But calm down, Pal! Before killing and going to jail, you should be doing a lil bit of debugging and kill that buggy issue.
So let’s be formal. The above paragraph has two buzz words:

I would like to enlist 8 general debugging tips below. But believe me, there are more.
Debugging is painful. No one likes to debug as most of the time, it takes a huge portion of your day. Moreover, it does not create any new value.
So, what you do when you find someone else’s bug? Do you spend time blaming him? I believe you don’t because blaming someone is not a solution. The bug you are having right now is your problem. It doesn’t really matter whether the bug is your fault or someone else’s. You have to embrace the fact. So instead of blaming, keep concentrate on fixing the bug. Actually, in most IT farms it is a part of Culture. For example, the company I am currently working at strictly follows this rule.

Let’s assume a situation where a programmer Rahim developed an application but later the testers reported that his application crashed every time when they submitted the person registration form. When Rahim heard about the issue he said that he could submit the form and it worked fine. So tensions became rising among the team.

To ease the situation the project manager set up a meeting with Rahim and the tester who actually had found out that bug. During the meeting, the tester said that when he had not provided any date and afterward submitted the form, the app exploded.
Rahim said, “Oh, I see!”, in a small voice. Rahim admitted that he had provided a birthdate when he submitted the form, that's why he was able to submit the form without any issues. Rahim should handle the case while the birth date is null or empty.
Lessons from this story are:
Whenever you witness a bug, what’s your reaction? It might be “that’s impossible”, or something like “my code can not produce this bug”. I would say, man, it is very important to step back a pace and give a shot to find out what could be causing the bug. However, you can write code for an immediate fix. That's Genius!. But without knowing the root cause, you can’t avoid similar bugs in near future. So dig deep and try to find out the root cause of the problem.

You have to know how to produce the known bug. Because if you are not able to reproduce it, you don’t know the bug is fixed or not.

For example, in a particular situation, we may find a clue and we chase it down. But if we did not note down where we were and when we started the chase, we could lose a lot of time getting back there. So keep pen and paper near to you while chasing the issue.
You must hear the term Binary Search whether you are a programmer or a non-programmer. You can use this idea even in debugging. For example, your registration form has been in production for 1 week with honor. But suddenly it starts crashing. For this type of circumstances, what you would do! The registration form seems a pretty small topic, all it does is it takes data and sends it to the database. So, at first, you need to look at the dataset. You can try looking at the place in the dataset where the form crashes. Try the dataset and feed it through a locally running copy of the app. Then apply the binary search technique to figure out exactly which input values are leading to the crash. It's not the only case to apply Binary Search. You can use the binary search algorithm to isolate the function or code section where the issue is introduced.

For example, you are using a third-party library for the input fields of the registration form. And suddenly one day your form explodes. You get an error message exactly where the error occurs. But this does not give you a clear reason why the error takes place. It typically can’t tell you what you were doing prior to this call chain. So you can put some tracing statements to drill down into the code. It may help you to get to the issue more easily.
Explain it to someone. Right, you heard right! It may sound simple. But you can apply this simple way when you spent a lot of time just finding out the issue by going through the code but was not successful. Sometimes the listener does not need to say a word, the act of explaining step by step might help you suddenly to gain completely new insight into the problem.

As humans, when we encounter a bug, we get into panic and don’t know what to do. Hence, we lose ourselves in the code while debugging. The above tips more often help me out to debug effectively being on the track.
But sometimes things don't allow us to do this kind of stuff. Because most of the cases we must solve the issue within a fixed time frame. Lots of pressure? From my experience, I would like to give you one piece of advice: DO forget these obstacles or pressures and put a complete deep focus on solving the issue because the pressure will kill time rather than fixing the bug. I hope from this article you have found something new that you can apply in your day-to-day bug fixing.
Reference Book: The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition (2nd Edition) by David Thomas and Andrew Hunt .
If you like this article, make sure to follow my Medium profile and check out other articles of mine!