The 5 Most Common Software Debugging Mistakes Made by Junior Engineers

Jason Lew
Jason LewFounder & CEO of SkillMagic

Did you know that debugging is one of the most important skills you can learn as a software engineer?

I'm Jason Lew, former iPhone engineer at Apple, Director of Engineering at Instacart, and repeat technical startup founder. I'm now the Founder and CEO of SkillMagic, where we help train junior software engineers in record time. Today I'm going to tell you the 5 most common software debugging mistakes I've seen from junior engineers. Do you do make any of these mistakes currently?

Debugging Mistake #1: Assuming

The first common mistake is assuming what went wrong instead of running the code to see what is actually happening. Imagine you have a function that you wrote, and it’s returning the wrong value when you call it. You may be tempted to think about all the possible mistakes you could have made in your code, or even staring at the code to see what could have gone wrong. Instead, you should: Run. The. Code. Break it down into small pieces, run those pieces individually, and figure out which piece is breaking. And this leads us to mistake #2 which is…

Debugging Mistake #2: What line is it anyway?

What line is it anyway? Do you know what line of code is actually breaking? It's such a simple concept, yet it's shocking how little it's used by novice debuggers. Would you let a surgeon operate on your broken leg if they didn't first run X-rays and MRIs to figure out exactly where the bone was broken? Of course not! So why would you try fixing your code before identifying where it broke. In other words, force yourself to figure out the problem, before figuring out the solution.

Debugging Mistake #3: Not defining expectations

How do you know if anything is "broken", if you don't have a clear expectation for what is "working"? You can't! That's why it's so important to define expectations.

Ask yourself these 4 important questions:

  1. What is the input supposed to be?
  2. What is the output supposed to be?
  3. What's actually happening with the input?
  4. What's actually happening with the output?

Once you've asked yourself these questions, you can immediately use the above skill of figuring out what line is broken.

Debugging Mistake #4: Inadequate tooling πŸ› 

The fourth debugging mistake commonly made by junior engineers is inadequate tooling. Imagine that you just moved into your new apartment, and you have to assemble a bunch of new furniture. Doing so will require you to screw in around 100 screws in total.

If you were to screw in every screw by hand, that would take an incredibly long time, and the screws probably wouldn't even be tight enough. This is analogous to just looking at your broken code (using no tools) to try to fix it.

If you were to use a screwdriver, it would certainly take you much less time to assemble all the furniture. This is analogous to using print statements in your code to check different variables' values.

Now, if you were to use a full-fledged debugger (eg. pdb for Python), that would be like using an electric screwdriver to assemble all the furniture, and you could expect that approach to be the fastest.

One caveat here is that depending on the nature of the bug, sometimes tools like a full debugger can be overkill. So try to choose the right tool for the right job, but you should never be using no tool at all.

Debugging Mistake #5: Brute-forcing online solutions πŸ’ͺ🏽

The fifth and final debugging mistake commonly made by junior engineers is brute-forcing online solutions πŸ’ͺ🏽. Imagine that you lost your apartment key and you can't get inside. Some brute force methods to get inside would be ripping off the door or shattering your own window to get inside. These solutions are ridiculous of course because they are destructive in nature and are therefore not good long-term solutions. A better solution would simply be to get a new key from the landlord or management.

When you just copy and paste a solution from sites like Stackoverflow, that's like breaking into your house with a destructive solution. Instead, try to come up with solutions that are easy to understand, repeatable, and non-destructive. And make sure you actually understand why the solutions work! You can certainly still use sites like Stackoverflow as a reference, but the point here is not to blindly copy-and-paste without understanding why it works and thinking of future implications.

Recap

Let's summarize the 5 most common mistakes:

  1. Assuming
  2. What line is it anyway?
  3. Not defining expectations
  4. Inadequate tooling πŸ› 
  5. Brute forcing online solutions πŸ’ͺ🏽

If you make any of these mistakes currently, that's OK. Try to catch yourself when you're making them, and force yourself to take the better approaches we talked about. If you do this often, your productivity and skills will compound over time, and eventually, you'll be a master debugger.

SkillMagic teaches critical skills like these to help junior software engineers improve their skills.