Code as Writing

The best code doesn't just run — it says something. And if you can't read it, that's a problem.

There's a moment, reading someone else's code, where you either feel yourself relax or tighten. Sometimes you scan a function and the intent just lands — you know what it does, why it exists, what it expects. Other times you're three levels deep trying to reconstruct the thought that produced it.

The difference, I've come to think, isn't about cleverness. It's about voice.

Good writing and good code share the same core problem: you're not there when someone else reads it. You can't clarify, can't gesture, can't add tone. What's left is the thing itself. So the thing itself has to carry the meaning.

Hemingway said prose should have no extra words. The equivalent in code is something like: no unnecessary indirection, no names that lie, no cleverness for its own sake. Not because terseness is a virtue, but because every layer of abstraction is a bet that the next reader will unpack it the same way you did.

The analogy breaks down somewhere — code has to run, prose just has to mean. But that's almost the point. Code that works but can't be read is like prose that technically follows grammar but says nothing. It passed the mechanical test and failed the human one.

What I find interesting is how readable code tends to reveal a certain kind of thinking: it's organized around the problem, not the solution. The structure maps to the why, not just the what. That's also, roughly, what separates writing that feels like a lecture from writing that feels like a discovery.

Both are doing the same thing: inviting someone into a mind that's already moved through the material, hoping the path stays visible.

Photo by wang binghua on Unsplash