This week had me thinking really hard about troubleshooting and debugging. These are the two main tasks I perform as a dev.
I spent quite some time troubleshooting a red herring only to discover that I was likely troubleshooting the wrong issue.
I feel that what might take more experienced engineers a few minutes to troubleshoot, often takes me quite some time. Without going into my feels about how that “let’s the team down”, I will confirm that I learnt a lot about not wasting too much time in the rabbit hole of improper troubleshooting.
Often a client will request an explanation for why something happened to ensure it won’t happen again. I totally get this. Most times I am able to explain this just by looking at logs and verifying what the issue was. Logs are the answer key to the test.
But what if, you really don’t know or can’t prove why something happened?
I ran into this issue twice in the last week. First was a server glitch that, well, could not be proven, but all other theories were exhausted.
The second, is still in the “provable” state, and I made a note to myself that in the future, I will only update the client when I can PROVE what the issue was, otherwise, I’ll simply let them know that I am still working on it.
The obvious issue here is that you cannot move on to debugging if you aren’t even trouble shooting the issue properly. BOY oh BOY is that a challenge with complicated code base. Which leads me to this awesome article that the boss shared. A Six Pronged Rails Performance Philosophy
After reading that, I decided to up my pen/paper game with regards to debugging. Per more experienced engineer’s suggestions, I really take the opportunity to write down what my theories are on a good old tablet of paper. This way I can comprehend, at a quicker rate, what exactly is happening, where the error is and what I want to do. I am not sure if there is a better way to do this, but that is how I start theorizing on how to solve the riddle.
After writing everything down that I need, I use the console to begin my debugging. If I need to see what a method is returning, a binding.pry will do just fine.
If I want to test my changes without borking stuff, testing locally works great for me. And lastly, if I just don’t know where to begin, I have learnt to become less intimidated by the process and just freakin’ ask. Sometimes, I get the answer, sometimes I get to pair up with another engineer, and sometimes I am left to fend on my own, going around in circles.
So my tasks for next time….truly understand what I am troubleshooting. Don’t rush, write it down and really understand it. There is nothing more frustrating than spending hours troubleshooting the wrong issue.
Use the most basic of debugging tools I have at the helm, start from point 1, not point 16 to debug the issue. Instead of assuming I know exactly where in the complex code base the problem lies, try something simple first, like finding out what the method, ivar, class, module et al are doing. Even though Ruby is almost 99.9% like english to read, it’s not always that simple, but it’s also not that difficult either.