Set a hard time limit — 30 to 45 minutes of genuinely stuck — and when you hit it, change something about your approach rather than continuing the same one harder. Hours lost to a single bug are almost never hours of progress; they're the same wrong hypothesis being retried with variations.
The escalation ladder, in order:
1. **State the problem in writing.** One paragraph: what you expected, what happened, what you've already ruled out. This is rubber-duck debugging, and a surprising share of bugs are solved during the writing, before anyone reads it — because articulating forces you to check assumptions you were skipping.
2. **Check your assumptions explicitly.** Is this code even running? Log at the top. Is the data what you think? Log the whole object. Did the file save, the server restart, the browser reload without cache? An embarrassing proportion of long bug hunts end here.
3. **Bisect.** Comment out half the logic, or add a log at the midpoint of the data flow. Determine which half is wrong, then halve again. This converts an unbounded search into four or five steps and works regardless of how large the codebase is.
4. **Reduce to a minimal reproduction.** Strip everything unrelated until you have ten lines that still fail. Usually the cause becomes obvious during the stripping, and if not, you now have something you can post and someone can actually help with.
5. **Ask someone**, with the paragraph from step 1. Not 'my code doesn't work' — a specific question with what you've tried. Most people wait far too long to ask, out of pride or fear of looking incapable. Two hours of solo flailing costs the team more than a five-minute question.
6. **Walk away.** Genuinely — a walk, sleep, a different task. The number of bugs solved in the shower is not a joke; stepping away releases the fixation on the wrong hypothesis, which is exactly what's keeping you stuck. Sleeping on it is a legitimate professional technique, not laziness.
The strategic version if it's a full day: stop and ask whether this is the right problem. Sometimes the bug is a symptom of a design that's fighting you, and the correct move is to rewrite the section rather than repair it. An hour of rewriting beats another day of archaeology more often than people expect.
On the demoralisation, which matters as much as the technique: long stuck periods are a normal part of the job at every experience level, not a signal about your ability. What changes with experience isn't frequency — it's that you recognise the state earlier and switch tactics instead of grinding. Building that trigger ('I've been stuck 40 minutes, time to change approach') is the actual skill, and it's worth practising deliberately with a timer until it's automatic.