Debugging is a life skill everyone should develop. I have come to love debugging, mostly because it is 90% of my job right now. I love the hunt, and the different stratergies you can use.

Every time a student comes up to me with a problem, I get to choose which tool I will be using this time to solve the problem. While debuggin labs on , most students normally just look at the solution after a certain point if they can’t figure out the answer. I did that a lot too in the beginning, I still do that sometimes. I don’t think it matters when you look at the solution, but the process of how you got there. Did you try everything possible before getting there? Did you read the error message? Were you able to figure out the line at which your code is breaking? Did you find anything on stackoverflow which might help you?

If you are able to do even some of these steps while you are trying to debug your code, you will be able to figure out the point/line where the bug lives. Once you know where to look, you have won half the battle. The second phase of debugging is determining what sort of error it is. Are you calling on a variable that is not in your scope? Is there a syntax error? Is there something wrong with your logic? Are there environment issues?

Error messages might not always tell you that there is a syntax error, even if that is the problem. While helping a student, I recently got an error telling me that I might have encountered a bug in ruby interpreter. I remember freaking out the first time I got such errors and thinking did I just break Ruby? I feel I have come a long way since then and I now know that the problem mostly lies elsewhere, and I didn’t infact break ruby.

I have since then devised a step by step plan to find the culprit. As soon as my code breaks, I trace back the last few steps and try to figure out what might have triggered it, a wise man(Steven Nunez) once told me never be more than a few command+z away from working code. This might seem like an obvious thing to do to seasoned programmers, but took me a while to make it a habit. When I finally had this down and was starting to love debugging, I started teaching, and debugging was never the same to me.

Back to the student who got this weird error about the ruby interpreter, how am I suppose to debug with limited time, without going through all the code and also make this a teachable moment? It took me a while to figure this out and with the help of a lot of patient students, I feel have a few tricks up my sleve but so much more to learn. I start by asking them what they added since the last time the code was working, which is mostly 20+ lines of code. I start by commenting one function at a time. Once I have found the function which is has the bug, I start commenting out line by line, till I find the line which breaks the code. I have found this technique very helpful as it allows me to debug without looking at all of the codebase. As for the student, he had a syntax error, and he was thrown off by the error as it was not the normal Ruby syntax error.

I feel this skill of breaking down the problem is important for all developers, as you might not have students to help, but you will be working on code that others have written which you might have to debug. So learn to enjoy the hunt!

Like what you read? Give Ruchi Ramani a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.