A Checklist When You're Stuck

I was two hours into a bug and completely certain it was mine. Properties I'd added on the Java side of an application weren't showing up on the JavaScript side. I'd just touched that code. It had to be my change — that's not a hunch, that's just how these things go, you break the thing you were last inside of. I spent the better part of an hour re-reading my own diff, convinced the answer was somewhere in it, because it obviously had to be.

It wasn't in my diff. It was a legacy codegen sync script, three steps removed from anything I'd touched, quietly failing to invalidate an old artifact. I didn't find that out by getting smarter. I found it out by walking away from my own certainty, twice, guided by a checklist I'd set long before I ever opened that file.

Here's that checklist, the same one every time. I go through this checklist anytime I'm about to dig into a problem that I know might be tricky.

1. Before you start — while you're calm, not while you're stuck — decide how long you're willing to work under pressure before you're required to stop. I typically set this at two hours.
2. Decide what activity you'll do when the timer goes off. Something calibrated to wherever you happen to be that day: a walk or a coffee run at the office, cooking dinner or picking up a controller at home.
3. Set the timer and get to work.
4. When the timer goes off, stop. Immediately. No snooze button, no "just five more minutes," especially when you feel close.
5. Get up and perform the activity from step two. Then loop back to step three. If the day's ending and the work isn't done, "call it done for today" and return to the checklist tomorrow.

That's the whole thing. It reads like it belongs on a sticky note, and I want to own that up front instead of pretending it's more sophisticated than it looks.

Why you need a plan instead of just trying harder

I built this checklist to get unstuck. What it's actually for is disrupting confirmation bias, and I didn't fully understand that until I'd used it enough times to notice the pattern.

Confirmation bias isn't a rare or exotic failure mode. It's the default behavior of any system — human or otherwise — that updates its beliefs using only the evidence it happens to be looking at. I spend a fair amount of my professional life around models that do exactly this, and the thing that should scare you about bias isn't that it exists. Knowing a cognitive bias exists — or that you're susceptible to one — is never sufficient to correct it. A concrete countermeasure is what you need.

I think engineers, of all people, are the ones most likely to trip on this, because we're the ones most likely to know better. Go back and read that API bug again: I could have explained confirmation bias to you, correctly, the entire hour I spent re-reading my own diff for a mistake that wasn't there. The knowledge didn't help, because knowledge doesn't operate at the point where the bias does its damage. Bias runs while you're interpreting the last ten minutes of evidence, not after. By the time you'd notice you've been doing it, you've already used the distortion to explain away the last three things that didn't fit.

So if awareness doesn't work, the thing that's left is structural. Not a better observation — a rule that fires whether or not you're paying attention to your own bias in the moment, because in the moment, you won't be. That's what steps one and two are actually doing. They're not scheduling; they're a decision made by a version of you who can still be trusted, binding a version of you who can't yet.

No snooze button

Step four is the one that matters most and the one people skip first, so it's worth sitting with.

The instinct to keep going, right when the timer goes off, almost always shows up dressed as intuition — I'm right there, just a few more minutes. I'd flag that feeling harder than any other part of the checklist. Feeling close is not a green light. It's frequently the same mechanism that's been quietly cherry-picking evidence for the last two hours, now asking for one more chance under a different name.

I don't have a clever enforcement trick for this beyond the commitment itself, and I want to be honest that I don't think one exists. This is why I placed the decision back at the first step. It's a decision made while you are still calm and hopefully unbiased. When the timer goes off, you are simply honoring that decision.

Why the break actually works

Here's the part I can't fully explain, though I've watched it work often enough to trust it. You do the calibrated thing from step two — walk, dinner, Guitar Hero, whatever's on your list — and at some point you sit back down and have to genuinely ask yourself: what was I in the middle of?

That disorientation isn't a side effect. It's the mechanism. The bias lived in the continuity of your attention — in the unbroken thread of "I've been staring at this for two hours and here's what I've concluded so far." Break the thread, and you don't get to reload the conclusion for free. You have to rebuild your understanding of the problem from something closer to scratch, and reconstruction doesn't automatically re-import the same assumptions you walked away with. Sometimes it does. But often enough it doesn't, and that gap is where the actual answer tends to live.

Not every activity earns you that gap, though. Passive stuff — TV, a podcast, scrolling — mostly fails, because your mind keeps quietly chewing on the problem in the background even while your eyes are elsewhere. The thread never actually breaks. What works is something that demands enough of your attention that you genuinely can't think about work while you're doing it, and which specific thing that is turns out to be personal. A walk does this for plenty of people. It's never worked for me — I just stew the whole time, same problem, different scenery. Cooking does it. A video game that actually requires focus does it. Your list from step two should be built around that test, not around what sounds relaxing on paper.

The other run through the loop

The API bug is the run where it worked the way you'd hope — I already told you that one, because I wanted you to have a win in hand before I complicated things. Here's the run I'd rather tell you about last, because it's the one that actually proves the point instead of just illustrating it.

I spent three days trying to implement an academic acoustic echo cancellation algorithm, with zero background in digital signal processing, going in on faith that I could learn enough of the domain to pull it off. Same discipline, same timer, same breaks. No breakthrough. On day three I stopped, and bought hardware microphones with built-in echo cancellation instead. This wasn't just an easy out — it meant that I had to ask for an entire display kiosk to be redesigned to incorporate a better microphone. Being able to calmly walk the stakeholders through everything that was tried and not letting my frustration with the problem overwhelm me is what made this a successful outcome.

I want to be precise about what "worked" means here, because it's easy to read that as a failure story bolted onto a success story for balance. It isn't. The checklist's job was never to guarantee the bias would break in my favor. Its job was to guarantee I didn't spiral while I found out whether it would. Both runs succeeded by that measure. One of them just also happened to produce a bug fix.

The checklist is the correction

You cannot fix a bias by knowing about it. Awareness and correction operate at different points in time, and bias does its damage at exactly the point awareness doesn't reach. What you can do is build something that doesn't require you to catch yourself in the act. The only place you can build that something is earlier, back when you're clear enough to distrust the person you're about to become under pressure.

So if you take one thing from this, take the order of operations, not the five steps. Decide the rules while you're clear-headed. Set the timer. Respect it like it's not yours to negotiate with. Let the disorientation do its work when you come back. That's true of a stuck bug. It's true of most places where you're trusting your own in-the-moment read of the evidence a little more than you should.

The timer's just the part you can see.