Somewhere past the twentieth kilometre

The best thoughts arrive somewhere past the twentieth kilometre. Not before. The first hour is bookkeeping: legs, breath, the argument with the body about whether this was a good idea. Then the argument ends, and something else begins.

Debugging has the same shape. A problem in code rarely gives way to force. Staring harder at the screen doesn't help; neither does adding another log line to a function that already has six. What helps is distance. Closing the laptop, leaving the desk, letting the problem run quietly in the background while the foreground is occupied with something simple and repetitive. Steps, in my case. Thousands of them, on a dyke road between two villages, at a pace that asks nothing of me except that I keep going.

What happens on those runs is not thinking, exactly. It's closer to listening. The problem I couldn't solve at the desk turns itself over slowly, and at some point around the third hour the wrong assumption surfaces on its own. Not the fix, usually. The assumption. That's the useful part. Most bugs aren't mistakes in what the code does; they're mistakes in what I believed the code was doing. A route long enough to bore me is the only place I reliably stop believing.

The cockpit taught me a version of this earlier, and more strictly. A small aircraft at 95 knots leaves little room for staring harder. When something doesn't add up, a radio call that doesn't match the field, a fuel figure that's off, the trained response is not to fix it but to fly the aeroplane first. Aviate, then navigate, then communicate. The order exists because the mind, under pressure, wants to solve the wrong problem quickly. Keeping the wings level buys time, and time is where the right problem shows itself.

Running gives me that time without the altitude. It works the way the checklist works: by removing options. On a long run there is nothing to open, nothing to search, no one to ask. The only tool left is the one I keep forgetting I have, which is patience. And patience, it turns out, is a debugging technique. Not a virtue. A technique.

There is a distinction I keep coming back to, between something that works and something that is right. A patch that makes the error go away works. Understanding why the error was there is right. The desk produces the first kind readily. The road, given enough kilometres, produces the second. I have come home from runs with the fix fully written in my head, and I have come home with nothing except the realisation that the fix I'd been writing for two days was aimed at the wrong layer. The second is worth more, and it never comes quickly.

So the long runs are not time away from the work. They are the part of the work where nothing is typed. Somewhere on the return leg, when the village comes back into view, the answer is usually already there, waiting for me to slow down enough to notice it.