The starting point
When a problem stops moving, adding more hours is not always the best next step. Staring at the same code can make the current explanation feel inevitable, even when the explanation is wrong.
First principles
A short break works best when it has a boundary. Write down the exact question you are trying to answer, step away from the screen, and return with one hypothesis to test. The point is not to magically solve the problem while walking; it is to interrupt an unproductive loop.
| Concept | What it means | Why it matters |
|---|---|---|
| Before stepping away | Write the failing behavior and expected behavior | Preserves the concrete problem |
| During the break | Avoid replacing it with another screen | Creates distance from the current approach |
| On return | Test one new hypothesis | Turns reflection into action |
A practical example
A small example helps make the idea concrete. This snippet is illustrative; it assumes the surrounding data and setup are already in place.
actual = run_case(input_data)
expected = reference_case(input_data)
if actual != expected:
print("Smallest failing case:", input_data)What to take away
A break is not a substitute for disciplined debugging. Use it to return with a sharper question, then verify the answer with a minimal reproducible case.
The goal isn’t to memorize a recipe. It’s to understand the choices well enough to make them deliberately.