Writing and Code: Same Leverage, Different Story

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, but think about it — software rarely works this way. Launching an app isn't the end. It's just the beginning. Then comes user feedback, bug fixes, feature iterations, version upgrades, security patches. The developer is tied to the product. As long as the product lives, the developer has to keep up. In a real sense, this is a hidden long-term liability.

Writing doesn't have this problem. Publish it, and it's done. Readers might comment. You can respond or not. The essay itself doesn't need your continued investment to continue existing. That "ship it and it's done" cleanliness is an outright luxury in software development.

There's another difference. When a user uses an app, they experience the product, not the person. But when someone reads an essay, they experience the writer — how they think, what they've seen, where they've been. The author's voice, judgment, even personality live in the words. Writing is a bridge between reader and writer. It builds something code never can: a relationship between people, not just between a person and a tool.

Finally, there's the meaning of recording.

I once wrote on my About page: what isn't recorded ceases to exist. In the context of code versus writing, that line takes on a specific meaning.

Code records functionality — a solution to a problem. It's useful, but it captures "how it was done," not "who I am." Writing records the person — my judgment at a particular point in time, the path I walked, what I saw, how I thought, my doubts and realizations. Over time, this accumulates into an archive that belongs only to you. Your own history.

AI Is Changing the Comparison

One more thing has been shifting in the last couple of years: the impact of AI.

AI's ability to write code is improving fast. Describe a feature clearly, and AI builds it — faster, better, every month. Code as leverage is becoming less scarce. That doesn't mean code is unimportant. It means "being able to write code," as a personal competitive edge, is diluting. When AI can produce code faster and better than most of us, where does my leverage as a coder come from?

Writing is different. AI writing capabilities are also advancing rapidly, but there's a fundamental distinction: AI-generated writing can be mass-produced, but it has no real experience, no authentic voice, no perspective that belongs to one specific person. AI can produce fluent, well-structured articles. But it can't write "It started around 1999, writing weekly columns on internet marketing for a newspaper. I remember always procrastinating until the last minute" — or capture the texture behind that kind of detail.

In an era flooded with AI-generated content, writing with real experience and an authentic voice is becoming scarcer. Which means it's becoming more valuable.

That's roughly everything I can think of right now about how code and writing differ as leverage. I've been emphasizing writing's strengths here, mostly because I come from the code side — I've written code for a living for years, and while I've occasionally jotted things down along the way, I'd never really stopped to think about how these two forms of leverage actually compare. This is a small summary of that recent reflection.

One thing I want to emphasize: code and writing are absolutely the two forms of permissionless leverage of our era. Whenever possible, we should make full use of both.

And to my fellow developers: whenever you get the chance, write things down. Because one day you'll realize that your essays outlasted your code.