The thought process of debugging
--
Coming from a bootcamp to a company with a large application, it was very challenging to understand which behaviours were a feature and not a bug, and to actually know what was causing it, was an entirely different headache, specially because you might not be able to understand the entire scope of what is really happening.
But once a bug was discovered, to fix it is like solving a murder mystery, you have a victim and now you have to start looking for clues before thinking who the culprit is, and to be able to manage that, I created a system to be my guide and my Watson.
Write your findings down
You might have a perfect memory, but having a visual clue of what is happening will help you make connections that otherwise could have been missed or simply prevent you from checking the same thing again.
Write down any information you think it is relevant, you won’t know if something is a clue or not until the end of the investigation.
You should also build a timeline of what happened, and what triggered what, this way you can see a chain of actions and perhaps even spot where something should/shouldn’t have happened.
Replicating
If you have a QA or a tester in your team, and you are not confident in how to replicate a bug, they should be the first people you ask for help, because they know how things look when they are working and will show you how to trigger a certain action and usually even know the expected behaviour.
But not all bugs are replicable, but is the best place to start, because once you can reproduce it, you can see the scope in which it is happening, and start looking for situations where it doesn’t, and see what is the difference, and try to change it and see if the behaviour also changes.
Sometimes it can be a bit tricky to replicate something, specially if you need a third-part response or access, but even then, if you can see whatever information is being sent, you can check if this is what the other application is expecting, or if there is something missing.
Error tracking and logs
Tools like rollbar will store errors or bad requests that happened in the application, they are usually the place where you should go to check if something that should have happened, didn’t.
And that is when having a timeline will be the most valuable, as you will have a time slot of when the error happened, and it will enable you to spot it much quicker, as sometimes the error might look unrelated to the bug.
Following the breadcrumbs trail
Once you have been able to reproduce it locally, to spot exactly where the bug is being generated can be tricker than it looks, as several workers and units might be used and it can become very confusing very fast.
That’s why I like to use a method that I call breadcrumbs trail, where I will “follow” the bug often using binding.pry, as I code mainly in Ruby, I will see where that information is coming from, see how it looks, and trying to find where it changed from the correct one to the wrong one, for example.
Depending on how big the application is, or how lost you are, this can be a rather slow method, but one way around it, is to use the same methodology for binary search, you will try to find a middle point of where the information is being sent and where it is being received check the state of it, and then either go to the next middle point, or come back.
Extras
Rubber ducking
Use an inanimate object or a living victim to talk about what is happening, and what you are thinking, as often enough by just talking out loud, you will be able to organise your thoughts and come up with new theories or things to try.
Asking for help
YOU WILL GET STUCK, if not in this bug, in the next one, and sometimes can be harder to ask for help than to solve the actual problem, don’t feel threatened about looking stupid and asking for someone to give a look at it, a new fresh pair of eyes can see things that you tired and used brain could have missed.
Final thoughts
Anyone can write code, but to understand someone’s else, is whole different skill, and as any other, it needs time and practice, so remember that if you know one thing more than yesterday it was progress.
Good luck.
