Long Walks as Debugging
The best tool I have for a hard problem is leaving the room it is in.
I have solved more problems on foot than at a desk, and for a long time I assumed this was a personal quirk rather than something structural.
It is structural.
Why the desk stops working
Debugging is a search, and a search has a failure mode: you keep going back to the same region because it is the region you can see. Sitting in front of the code is enormously useful right up until the answer is somewhere the code is not, at which point staring harder just reinforces the wrong hypothesis. Every re-read makes the assumption you did not know you were making more invisible.
Walking removes the artefact. You cannot check anything, so you are forced to reason from what you remember, and what you remember is a compressed version that has thrown away exactly the incidental detail you were fixating on.
The specific mechanism
The useful part is not relaxation. It is that you are obliged to hold the problem in a form small enough to fit in your head. Anything that does not fit gets dropped, and what survives that compression is usually the actual shape of the thing.
More than once the answer has arrived as an awareness that I could not reconstruct some step I had been treating as obvious. That is not inspiration. It is an inventory check that the desk was preventing.
A caveat
This only works after the groundwork. A walk taken before you have properly read the code produces confident nonsense. The compression is only valuable if there is something worth compressing.
Do the reading. Then leave.