HOW TO BECOME THE EXTERMINATOR (4 TIPS FOR DEBUGGING)

Abe Johnson

I am struggling to find a hook on why you should read this article. It doesn’t feel too qualifying to say I am skilled at debugging. I didn’t even want to believe it was one of my strengths in programming. However dozens of peers and students have mentioned it independently so I’ve realized that I’ve developed a system.

Here are 4 tips I’ve created to help you learn improve your ability to debug code:

1. ) HAVE YEARS OF MISTAKES UNDER YOUR BELT

I hate when people make top x lists and misrepresent the truth. I’m not going to lie to you; the important factor in debugging quality and speed is experience. Initially when you're starting to learn how to code there’s too much friction in the execution of an idea.

This is especially apparent in the debugging process. The more you code the more lines will begin to interact with each other and it becomes vital that you understand the order in which code is running and how that stack resolves.

The good news is that all the time you spend today running full speed into hurdles will build your skills in the future. Debugging can be a very frustrating experience but it is always a satisfying feeling to overcome adversity knowing that it’s only going to build your skills as programmer.

To reach debugging Nirvana you must assimilate your brain to the functionality of a CPU; reducing complex abstract ideas to sequences of single lined statements. One of the ways to build this skill is to...

2. ) BUILD YOUR CONVERSATIONAL SKILLS WITH YOUR COMPILER!!!

If you find you often run into bugs and have a hard time resolving them, then you need to upgrade your conversational skills. When I see people struggle with debugging it is most likely because their dialog with their compiler sounds like a Shakespearean monologue; too one-sided.

If your coding process consistently feels like a game of guess and check odds are your doing too much talking and you could benefit from looking and logging better data to your console.

A good example of this is this very common error in react:

I see this error in my office hours at least once a week. Usually students can figure out that the item here is undefined, but they are unsure how it got that way and how to fix it. I always tell them not to ask me, but to ask the compiler. Figure out where the mismatch between your expected output and the actual output is.

If you're completely lost you could try to...

3. ) FOLLOW THE SCIENTIFIC METHOD

The scientific method is an invaluable way of affirming data and that's the process I use to debug and teach students how to debug.

Make an observation. Ask a question. Form a hypothesis, or testable explanation. Make a prediction based on the hypothesis. Test the prediction. Iterate: use the results to make new hypotheses or predictions. Instead of going by each one of these step by step I’m going to review trying to explain one of the most challenging bugs I’ve had to explain while working at Nebula.

Bayley Arens, a graduate from the most recent cohort, was working on a very impressive turn based fighting game. Each turn you have 4 different moves per character and each attack has special properties.

That in itself is already quite a challenging concept for a beginner, but where he was really running into problems was figuring out how to make status effects. He had code that would do damage at the end of the round, but he was having trouble making things consistent.

Here is a snippet of code:

let bleeding = false; let bleedingTurns = 0;    let demonGuy = {      name: 'Muzan',      health: 600, }    let chosenChar = {      name: 'Tanjiro',      health: 100, }

Here we have 4 variables. A boolean indicating whether a unit is status effected, a counter for how many turns that effect would go for and two objects that contain the player and the onscreen enemy.

The problem Bayley was having is that the game could not tell which unit was statused and where to put the bleed effect UI.

If you’re a high level programmer you can look at this snippet and immediately tell there is a design scope problem with this code. There is no reference to which unit is bleeding. If I just tell Bayley that it will not help him grow however.

So instead we apply the scientific method:

First we observe the bug. Try to replicate it as much as possible and any time we’re lost we head back to the app to recreate the exact situation to recreate the bug. The next step is to ask Bayley questions until he forms a hypothesis on why the behaviors are happening.

His first guess was that integers in JavaScript have a limit to how many times they can be reassigned. So we had him test that hypothesis and in a short 30s detour we figured out that was not the case.

To many that may seem like wasted time, but If you take away one thing away from this blog I want you to reframe that as experience gain. And experience is the skill they pay for in this industry.

So we made him try a few more hypotheses until he eventually ended up with a more streamlined 2 object solution. Each unit needs access to its own condition of whether or not it’s bleeding and how many turns they should be bleeding for:

let demonGuy = {   name: 'Muzan',      health: 600,   bleeding: false,   bleedingTurns: 0 }   let chosenChar = {   name: 'Tanjiro',    health: 100,   bleeding: true,   bleedingTurns: 2, }

Ultimately that means that with effort any problem is solvable especially if you...

4. ) WORK AROUND ANY BLOCKERS!

Let me tell you the one truth I have come to truly understand. Every force in the universe is actively conspiring to destroy all of your momentum. Scientists have a word for this principle: Entropy; a lack of order or predictability and a gradual decline into disorder.

There are an infinite number of excuses one could come up with to justify why they didn’t do something when it comes to software development. There are millions of lines of code being compiled that you are vaguely aware of what is being done, and yet you're still being asked to build on top of that.

There are API Keys and environment variables that you may not have access to, documentation you’ve never worked with, low or no results on stack overflow.

But despite the overwhelming odds stacked against you you have to show up every day and fight for your right to make progress and gain knowledge. Some days it will be just a lateral step of gaining more knowledge of what not to do. A large part of debugging is to stop resisting the fact that this problem is challenging, but embracing and thriving off the difficulty.

I hope this helped you learn a bit about my mindset into debugging.