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.