Get Better at Debugging by Making Predictions

Jake Worth — Tue, 23 Sep 2025 15:42:40 +0000

Shift to a proactive mindset by making predictions before any experiments in a debugging session.

This may sound simple, but it's powerful. Here's how and why it works, why it moves you from reactive to proactive, and how to use it outside of debugging.

How and Why to Make a Prediction

Imagine you're debugging a web application, and you're trying to understand why some data on your page looks wrong. Think of an action you might take to learn more.

Maybe you decide to log your data to see what's wrong with it.

Before looking at your console to read the data, stop! I want you to predict what's going to happen next.

Is it going to be null? Is it going to be an object with the wrong keys? Is it going to be an object with the right keys, but the wrong values? Say your prediction out loud.

Now, look at the output. What do you see? You made a hard prediction, so it's either right or wrong. Which one was it?

Considering this result, think about another action you might take. Log something else? Use a debugger? Log something higher up?

Repeat.

Predictions Move You from Reactive to Proactive

Predicting what might happen forces you to pivot from the comfort of reacting to the empowering discomfort of being proactive.

When you're debugging, reacting is our default. "I do this, then I see this... But why? That shouldn't be happening!" Stimulus, response. You might stumble onto a solution, but it will take a while, and you won't learn much.

We want to be proactive. There's a saying about debugging: "If all you're assumptions were correct, you wouldn't be stuck." In other words, your mental model of the problem needs refinement.

To have a chance at fixing a bug, you must at least have a mental model. That's what making a prediction does. You're making a model. On the surface, it can look very similar to guessing. The difference is you're forcing yourself to take a stake in the results of your experiment.

Predicting moves you from "Why isn't it working?" to "I expected an object of data, but it's null," which is powerful. It's specific enough to be actionable, or at least lead to a good next question. Such as "Why is this null?"

Learning to Predict Outside of Debugging

I make predictions all the time when coding.

On my best days, it puts me in a state where I'm making prediction after prediction and seeing them realized. When a prediction isn't realized, it's jarring. It's a trigger that turns off my autopilot when something surprising happens.

Conclusion

Shift to a proactive mindset by making predictions before any experiments in a debugging session. See how it moves you away from reactive, and how it can be useful in many contexts.

If you found this idea helpful, it's adapted from my short, actionable debugging guide: Don't Stay Stuck: A Debugging Guide for Rising Engineers.

--
Photo credit: Hans Reniers on Unsplash

Debugging Tip: Don't Stay Stuck

Jake Worth — Wed, 13 Aug 2025 15:02:57 +0000

Staying stuck rarely leads to a solution or a happy day; don't stay there.

This post is adapted from my digital debugging guide, Don’t Stay Stuck: A Debugging Guide for Rising Engineers.

We've all seen this: a frustrated coworker hunched over a computer after hours, flailing against some impossible bug. Or been that coworker ourselves.

Persistence has limited power. Put your problem in a timebox, or go home.

The Limited Power of Persistence

Persistence is important in computing, but it can only take you so far.

I once took a CS course that featured an online puzzle where you had to perform a series of tasks in a seemingly random order to solve it. The solution required brute force. You tried each step until something happened, and then you tried another. I found it maddening, and I gave up.

It was intended to be a lesson in persistence: sticking with a problem without clear feedback. I learned that, along with an anti-pattern that took years to shake: staying stuck for too long.

Sticking with a problem is a virtue in programming. If we all walked away anytime we were stuck, none of us would become expert debuggers. But if you're deeply stuck, the process soon loses value. You're no longer demonstrating persistence; you're feeling defeated and alone. When you get there, I recommend stepping away from the computer.

Put it in a Timebox

Still persisting? My advice is to timebox your solo debugging: give yourself twenty minutes to an hour to spin your wheels, then ask for help.

When the timebox ends, and you ask for help, you can still learn, because the person you asked might not be available or capable of solving the problem. They might only offer an idea. That meager crumb can lead you back to the trail.

Go Home

If you can't get help and it's an appropriate time, go home. Let your brain work on the problem while you sleep.

You've solved hard problems before, and you can solve this one. Sometimes, the easiest way to do that is to step away.

I can't count the number of times I've labored over a bug all afternoon, gone home exhausted, then come back and fixed it within minutes the next morning.

Conclusion

Staying stuck is frustrating and rarely leads to a solution or a happy day; don't stay there.

Cover Photo by Aubrey Odom via Unsplash

DEV Community: Jake Worth

Get Better at Debugging by Making Predictions

How and Why to Make a Prediction

Predictions Move You from Reactive to Proactive

Learning to Predict Outside of Debugging

Conclusion

Debugging Tip: Don't Stay Stuck

The Limited Power of Persistence

Put it in a Timebox

Go Home

Conclusion