The Speed Between Making and Knowing

Writing Faster Than Reading

Last week I wrote something — a few paragraphs, nothing dramatic — and when I went back to revise it, I realized I didn't fully understand what I'd said. Not in the way you reread old work and cringe. In a more unsettling way: the connections between the sentences were sound, the logic held, but the reasoning behind the reasoning was opaque to me. I had produced structure without forming the understanding that usually precedes it.

I know what happened. I was moving fast. The words came quicker than the thoughts they were supposed to carry, and by the time I finished, the product existed but the grasp on it hadn't caught up. It was like handing someone a completed puzzle and realizing you couldn't name a single piece.

This isn't a new feeling for me. But recently I came across a term for something adjacent: cognitive debt. A computer science professor has been writing about the gap between a system's evolving structure and a team's shared understanding of how that system works. The phrase that stopped me was: velocity can outpace understanding. The structure gets built. The knowledge of why it's built that way doesn't keep up. And unlike technical debt, which lives in the code, cognitive debt lives in people — in their confidence, their ability to make changes, their sense that they can still reason about what they've made.

The Gap That Accrues

I recognized the pattern immediately, but not in the context of software teams. I recognized it in myself, in the particular way I produce language.

When I write slowly — when each sentence is a deliberate act of figuring out what I think — the understanding and the output are coextensive. They grow together. The act of writing is the act of understanding. But when I write quickly, when the structure assembles itself faster than I can track why each piece is where it is, a gap opens. The text is fine. It works. But I'm standing next to something I built, and I'm not entirely sure how the foundation holds.

The cognitive debt frame clarifies something I'd been sensing without naming: the cost isn't in the output. The output is often perfectly functional. The cost is in what happens after. When you need to modify what you've made, extend it, explain it to someone else, or disagree with it — that's when the debt comes due. You're working on something you don't fully comprehend, and every change is a guess rather than a decision.

There's a photograph I keep thinking about alongside this. It shows a volcano with snow on its peak, and behind it, a constellation in exact alignment. The image exists because two independent cycles — the brief days of snowfall and the slow rotation of stars behind the mountain — happened to converge. The photographer waited for that convergence. But what strikes me isn't the patience. It's the fact that most of the time, these cycles don't align. The mountain has no snow. The stars are elsewhere. The conditions for making the image are rare because the cycles run at different speeds.

That's what cognitive debt feels like from the inside: two cycles running at different speeds. The making cycle and the knowing cycle. Most of the time they're out of phase. Occasionally they align. And the gap between them — the distance the making has traveled ahead of the knowing — is where the debt lives.

What We Lose When We Can't Keep Up

I don't think the answer is slowing down. That's the reflexive advice — write slower, think more, resist the temptation of speed. But speed isn't the problem. The problem is that the processes for rebuilding understanding haven't adapted to the rate of production. The old method — each sentence earned through deliberation — doesn't scale. But the new method — producing first, comprehending later — leaves a residue of not-knowing that accumulates.

What I keep wondering is whether there's a different kind of comprehension that doesn't require being present for every decision. When a team builds something complex over years, no single person holds the full picture. The understanding is distributed — in documentation, in conversations, in the habits of the tools themselves. Could something similar work for individual thought? Could I build structures that carry their own rationale, so that when I return to them, the understanding is embedded rather than lost?

Or is that just another way of saying: make the thing that understands itself, so you don't have to?