Vincent Ping - Writing and Code: Same Leverage, Different Story
"abo this site" -->
Vincent Ping
About
Contact
Writing and Code: Same Leverage, Different Story
2026-06-19
by Vincent Ping<br>en<br>cn
Naval Ravikant said it in The Almanack of Naval Ravikant: "Fortunes require leverage." The modern divide isn't between the rich and the poor. It's between people who use leverage and people who don't.
He broke leverage into four types: labor, capital, code, and media. Of these, he singled out code and media as the only two forms of permissionless leverage — the only two that don't require anyone's permission to use. Labor needs people willing to work for you. Capital needs you to already have money, or someone willing to give you theirs. But code and media? One person, one laptop. Once it's built, it works for you while you sleep.
Naval's "media" covers writing, podcasts, video — all of it. But today I want to focus on just one slice: writing, and how it compares to code as a form of leverage .
I largely agree with Naval's framework, especially on code. I've made my living writing code for a long time now. I understand code leverage well: build something once, copy it at near-zero marginal cost. With web-based software, you don't even need to distribute — people open a browser and it's there. Software has direct utility, too. Plenty of people rarely read, but everyone uses software every day: WhatsApp, TikTok, Apple Pay, Amazon. From that angle, code has broader reach — users don't need to want to read, they just need to use.
But lately I've been rethinking the comparison. The more I look at it, the more I think that as two forms of permissionless leverage, writing and code are far more different than they first appear.
What Writing Can Do
First, the nature of influence is different.
Code is a tool. A user opens an app, completes a task, closes it. Who coded it doesn't matter. The user doesn't know, doesn't care, doesn't need to. Code's influence is functional — it changes what you can do, but it rarely changes how you think.
Writing is different. A good piece of writing demands reading, sometimes re-reading. It requires understanding, internalization. Writing enters the reader's mind. It changes how they think.
A good essay might shift how you see something. It might open a window during a moment of confusion. It might make you smile in recognition: "Someone else thinks the way I do." That kind of influence is cognitive. It's a real connection between writer and reader.
A software user finishes and moves on. A reader sometimes carries an essay for life.
Second, the independence of distribution is different.
Code must live inside a complete runtime environment — operating system, dependencies, servers, databases. It can't exist on its own. It needs infrastructure to run. That means code distribution has a high barrier: users need to install, configure, learn, sometimes need specific hardware and systems. This is partly why many developers prefer building standalone apps over web services — fewer dependencies.
Writing is different. An essay is a complete, self-contained unit. One article, one link — it can go anywhere, and anyone who opens it can read it. No screen? Print it out. Carry it in your pocket. It doesn't need a runtime, an installation, an account, or a manual. That lightness is something code rarely achieves. Naval's "works for you while you sleep" is purer with writing — it truly exists independently, with no preconditions.
Third, the shelf life is different.
Technology iterates fast. Code written ten years ago often can't run today — not because anything is wrong with the code itself, but because the environment changed. The things it depends on moved too fast. I've seen plenty of projects like this: the code is fine, but a single deprecated dependency kills the whole system. Software has a peculiar kind of rot. It doesn't change, but the world around it does, and that's enough to break it.
Writing ages differently. An essay can become outdated — the data, the references, the specific context it discusses may all expire over time. But it doesn't "break." An essay you wrote twenty years ago still opens, still reads, still looks the same. No one needs to maintain it for it to continue existing. And the best writing doesn't go stale at all — explorations of worldview, ways of thinking, observations about the human condition. These sometimes hit harder decades or centuries later, strengthened by the weight of time.
Paul Graham is a good example. Few people remember the software he wrote in the early days. But the essays he wrote in the same period — on startups, on thinking, on programming languages — are still circulating, still cited, still shaping each new generation of founders and engineers.
The half-life of an essay's influence is something most software products can't match.
Writing as a Durable Asset
Once an essay is finished, it's a complete product.
That sounds simple,...