On Building in Silence
There is a particular kind of focus that emerges when you stop explaining yourself.
I noticed it a few years ago, during a stretch when I was heads-down on a difficult infrastructure problem — distributed configuration with strong consistency guarantees — and I had deliberately stopped talking about it. No Twitter threads. No Slack updates to people who hadn't asked. No drafts of future blog posts in my head while I was trying to think.
Just the problem, the tools, and the time.
What I found wasn't just that I moved faster. It was that the thinking became different in quality. When you're not narrating, you're not performing. You stop reaching for the explanations before you have the understanding. You let things be unresolved for longer — and that longer residence turns out to be where most of the good ideas live.
The cost of constant narration
Software culture has a complicated relationship with silence. We've built an entire discourse around "building in public" — the idea that sharing your work as you do it creates accountability, community, serendipity. And I think that's often true.
But there's a failure mode no one talks about: the premature crystallization of thinking. When you write about a decision before it's fully formed, you don't just describe a position — you commit to it. The act of explaining makes the idea load-bearing in ways it wasn't before. And then you spend weeks defending a scaffold instead of building what was supposed to go inside it.
I've made this mistake enough times to recognize the shape of it. The insight that felt worth sharing, shared too early, hardening into a thesis I had to inhabit rather than test.
Constraints as a design tool
The other thing that silence gave me was a keener sense of constraints.
When you're building alone and quietly, you can't borrow legitimacy from the conversation. You can't get validation from a reaction that tells you you're on the right track. You have to decide, from the inside, whether something is working. That forces you to develop cleaner internal criteria — not "did this feel right when I explained it" but "does this actually solve the problem."
This sounds obvious, but it runs counter to how a lot of collaborative software work gets done. Consensus-building is a powerful social technology. It also optimizes for things that are easy to defend over things that are hard to explain but correct.
Silence forces you back to the object level. Does this behave the way I want it to? Does it hold under pressure? Does it compose cleanly with everything around it?
What it means to finish something
I think the reason I keep returning to this idea is that most of the projects I'm proudest of were built in a kind of quiet. Not in isolation — I had colleagues, feedback, review. But the core thinking happened before all of that. The idea had time to be private before it became social.
There's a particular satisfaction in finishing something before anyone else knows you started. You get to hold it up and say: here. This exists now. I made it. And no one helped me decide whether it was worth making.
That feeling is hard to replicate when the building is public from the beginning. The making and the explaining collapse into each other, and you lose track of which one you're doing.
I'm not arguing against sharing work. I'm arguing for the right rhythm of it — the understanding that some of the most important building happens in the gap between the first idea and the first explanation.
That gap is worth protecting.