Those are the steps you should take when solving a bug

Tobias Aguiar
3 min readApr 21, 2023

--

Photo by Markus Spiske on Unsplash

This happens to you and maybe you don’t notice it.

A constant in life

In any development career, you’re going to encounter bugs. In the most unpredictable ways. Take me as an example : I found a little bug on release’s day. I got desperated.

But today’s journey thought me a valuable lesson, that it has been trying to teach me a while a go : stress and desperation won’t help you solving your bug. Even less if you have a deadline, like I did.

But we agree that is hard to think when those situations come in. You just paralyzed. And that’s why you need to not rely on yourself when you are on such vulnerable state. Let me explain.

Stress is necessary, but at the same time not useful

Imagine you are next to a river where you can see yourself through the reflex of the water.

Now you put your hands on the water, and you start shaking it. It produces some waves. Can you still see yourself ? I’m afraid you can’t.

Because the water isn’t calm, it is pretty agitated. And you can’t see clearly.

That’s exactly what happens to us when we are desperate or angry. Those emotions take control of us most of the time and blind our “vision” and logical thinking.

Getting back to the point, why you shouldn’t rely on yourself?

because you are not reasoning well.

If I’m not reasoning well at the this specific time, what should I do?

When you calm down, you’re going to take a piece of paper. You’re going to write down the following questions :

  1. Which was the last commit from your version control system that was not having this bug? Go back there.
  2. Look at the piece of code that was created between this commit. Is the code small? If yes, then comment everything and uncomment until you find the bug.
  3. Is the code big between the 2 commits? Then, take the logs from the 2 versions and compare each line Found something odd? Go to the code where this log is issued, compare the 2 versions of this specific piece of code, and find in which part can be something missing.

You can even draw a flow chart illustrating everything.

And then, next time you have a bug with a deadline to solve it and you get nervous or desperate, you don’t even think.

Just take your flowchart, and follow what it says.

I applied and worked pretty well, and it even helps you calm down as you’re following through it.

Notice that every bug is different, even if you are in different software fields. Every bug requires different actions and steps to be taken.

However, if you tends to be desperate and emotionally affected (which is my case), I highly recommend having a backup plan.

This means having simple steps written in a paper (or somewhere else) where you can just follow without thinking while you can’t reasoning well.

Final thoughts

Every one has those tough times, the difference relies on how you deal with it by using your own developed systems and hacks that can protect you from those situations.

Hope it can help you somehow.

Happy learning!

Thanks for reading!

Other resources

I post something on linkedin about embedded systems every day. If you don’t want to miss it, make sure to follow me here.

Want to search for a job or you lost your current one? Take a look at this article here.

--

--

Tobias Aguiar

Software developer | Trying to make complex concepts look easy | Want help or discuss about embedded software development? Email me! tobi.aguiar01@gmail.com