Writing as a Thinking Tool

Last year I spent three weeks stuck on a system design problem. Not a hard one, either. A caching layer for a real-time physics simulation. I had the architecture in my head. I could explain it on a whiteboard. I could talk through the tradeoffs with a colleague over lunch. But every time I sat down to implement it, something felt wrong and I couldn’t identify what.

Then I opened a blank document and started writing. Not code. Prose. “The cache needs to invalidate when X changes, but X depends on Y, which depends on…” and within two paragraphs I found it. The invalidation order had a circular dependency that my verbal reasoning had been papering over for weeks. My brain, when talking, had been jumping past the contradiction. Writing wouldn’t let me jump.

That’s the thing about writing. It’s not a way to record what you already know. It’s a way to find out what you don’t.

The compression thesis

There’s a concept in information theory that applies directly to writing: lossy compression. When you compress an audio file from WAV to MP3, you throw away information that (theoretically) doesn’t matter. The skill is knowing what to keep and what to discard.

Writing is lossy compression for thought.

When you have a vague idea bouncing around your head, it feels complete. It feels like you understand it. But that feeling is deceptive, because unwritten thoughts don’t have to be coherent. They can contain contradictions, gaps, circular references, and undefined terms, and you won’t notice because you never forced them through a bottleneck narrow enough to expose the problems.

Writing is that bottleneck. A sentence is a linear sequence of words. It has a subject, a verb, an object. It makes one claim at a time. To write a paragraph, you have to decide what comes first and what comes second, which implies a causal or logical ordering that your brain never had to commit to when the idea was just floating around in there.

William Zinsser put it best in On Writing Well: “Writing is thinking on paper.” He meant it literally. Not metaphorically. Not “writing helps you think.” Writing is thinking. The act of putting words in sequence is the act of organizing thought. They’re not separate processes where one feeds into the other. They’re the same process.

Zinsser spent decades teaching nonfiction writing at Yale, and his core diagnostic question was deceptively simple: “What am I trying to say?” He found that writers, when stuck, almost never had a writing problem. They had a thinking problem. They hadn’t figured out what they actually meant. The writing wasn’t bad because of technique. The writing was bad because the thinking was bad.

Here’s his test. Take any piece of your own writing that feels off. Ask yourself: “Have I said what I meant to say? Is it clear to someone encountering this for the first time?” If the answer is no, the fix is rarely a better word or a smoother sentence. The fix is figuring out what you actually believe.

Feynman and the honesty of explanation

Richard Feynman’s most famous pedagogical insight gets simplified down to “if you can’t explain it simply, you don’t understand it well enough.” That’s the bumper sticker version. The real version is more interesting.

Feynman’s actual practice was to take a blank piece of paper and attempt to derive or explain a concept from scratch, as if teaching it to someone with no background. When he got stuck, when he couldn’t bridge from one step to the next, he had identified a gap in his own understanding. Not a gap in his ability to explain. A gap in his knowledge.

The critical insight here is about honesty. When you explain something verbally, to a friend, to a class, to yourself in the shower, you can gloss. You can wave your hands. You can say “and then basically what happens is…” and skip the part where you don’t actually know the mechanism. Your listener nods. Your internal monologue nods. Nobody calls you on it.

A blank page doesn’t nod.

This is why writing is harder than talking. Not because of grammar or vocabulary or structure. Because writing is honest in a way that speech almost never is. The page sits there and waits for you to actually say the thing. If you don’t know it, the page is blank, and you can’t pretend otherwise.

Feynman’s technique has four steps, and they map directly to a debugging process that every programmer would recognize:

This isn’t a coincidence. Both processes work because they take something that feels correct and subject it to a formal verification that exposes whether it actually is correct. In programming, the formal verification is a test. In thinking, the formal verification is a written explanation.

Why engineers who write are engineers who ship

There’s a pattern I’ve noticed across every engineering team I’ve worked on. The engineers who write well, who can produce a clear design doc or a coherent post-mortem, are almost always the ones who ship the best code. Not because writing makes them better coders mechanistically. Because both abilities come from the same underlying skill: the ability to think clearly about complex systems and communicate that thinking to others (including their future selves).

Jeff Bezos figured this out in 2004 when he banned PowerPoint at Amazon and replaced it with six-page narrative memos. His reasoning: “The narrative structure of a good memo forces better thought and better understanding of what’s more important than what, and how things are related.”

The Amazon six-pager isn’t a communication format. It’s a thinking format that happens to be shareable.

Here’s what Bezos understood that most organizations miss. PowerPoint lets you be vague. You put three bullet points on a slide, and in the meeting you “talk through” the bullets, filling in the gaps verbally. The audience hears what they want to hear. The presenter says what they feel like saying. Nobody has committed to an actual position, so nobody can be wrong, and nobody has really thought it through.

A six-page memo has no presenter. It stands on its own. If there’s a logical gap on page three, every reader in the room will notice it during the silent reading period. Andy Jassy reportedly wrote 30 drafts of his six-page vision document when pitching AWS. That’s not excessive. That’s thinking happening.

Paul Graham makes a similar observation from the opposite direction. His essay “Putting Ideas Into Words” argues that writing doesn’t just communicate ideas, it generates them. The constraint of having to put an idea into words often reveals implications and connections that you wouldn’t have discovered any other way. You start writing to explain what you already know, and you end up discovering something new.

This is why the best technical writers are often the best technical thinkers. Not because they’re two separate skills that happen to correlate. Because they’re the same skill measured in two different ways.

Code is prose in disguise

Programmers sometimes resist the idea that writing matters for their work. “I write code, not essays.” But code is a form of writing, and the same principles that make prose clear make code clear.

Consider two versions of the same function:

# Version A
def p(d, t):
    r = []
    for i in d:
        if i['ts'] > t:
            r.append(i)
    return r

# Version B
def filter_events_after(events, cutoff_timestamp):
    return [
        event for event in events
        if event['timestamp'] > cutoff_timestamp
    ]

Version B is better not because it’s more Pythonic (though it is), but because it’s been through the same compression process that good prose goes through. Someone thought about what this function actually does, chose names that say it, and eliminated everything that doesn’t contribute to the reader’s understanding.

Zinsser’s rule for prose, “strip every sentence to its cleanest components,” is also the rule for code. Every unnecessary variable, every ambiguous name, every convoluted control flow is clutter. And clutter in code, like clutter in prose, is a symptom of unclear thinking.

The best code review feedback I ever received was from a senior engineer who wrote in the margin: “I can’t tell what this function promises. What’s the contract?” That’s not a code question. That’s a writing question. What are you trying to say?

Writing as the original rubber duck

Programmers have this practice called rubber duck debugging. You explain your code, line by line, to a rubber duck sitting on your desk. The duck doesn’t respond. The duck doesn’t need to respond. The act of explaining is what fixes the bug, because when you have to verbalize each step, you find the step where your verbal explanation diverges from what the code actually does.

Writing is rubber duck debugging, but better. Because when you talk to a rubber duck, the words evaporate. You can’t go back and check whether step three actually follows from step two. When you write, the words stay. You can read them back. You can see the contradiction sitting there on the page, permanent and undeniable.

I keep an engineering journal. Not a diary. A working document where I write through problems before I write code. A typical entry looks like this:

The rate limiter needs to handle burst traffic without
dropping legitimate requests. Current approach: token bucket.
Problem: the bucket refill rate assumes uniform request
distribution, but our traffic is bursty by nature.

Wait. If traffic is bursty, then a token bucket with a
sufficiently large burst capacity should handle it. The real
problem is that I don't know what "sufficiently large" means
for our traffic pattern. I need to look at the P99 burst
size from the last 30 days of logs.

Actually the deeper problem is that I'm designing the rate
limiter without knowing the traffic shape. I should
characterize the traffic first.

Notice what happened. I started with a solution (“token bucket”). Writing forced me to confront why the solution might not work. That confrontation led me to the actual problem (“I don’t know the traffic shape”), which led me to the actual first step (“characterize the traffic”). Three paragraphs. Saved me a day of building the wrong thing.

This happens so regularly that I’ve started treating “write about it first” as the default approach for any problem I can’t immediately solve. The writing doesn’t always produce a breakthrough. But it always produces clarity about what I know and what I don’t know, and that clarity is worth the twenty minutes.

The writing-thinking feedback loop

There’s a deeper mechanism at play that goes beyond “writing exposes gaps.” Writing creates new ideas.

When you write a sentence, you’ve committed to a claim. That claim interacts with the next claim you make. Sometimes those two claims are consistent. Sometimes they’re not. And sometimes, the tension between them generates a third idea that you didn’t have before you started.

This is what Paul Graham calls “the essay as a way of exploring ideas.” You don’t start with a thesis and then write to support it. You start writing, and the thesis emerges from the writing. The act of committing words to a page creates a feedback loop: write a claim, examine it, find a tension, resolve the tension, and that resolution becomes your next claim.

Leslie Lamport, the computer scientist who created LaTeX and won the Turing Award for his work on distributed systems, has been vocal about this. He argues that if you can’t write a clear specification of your algorithm, you don’t have an algorithm. You have an intuition. Intuitions are useful for generating hypotheses. They’re useless for proving correctness.

Lamport’s point extends beyond formal methods. In any domain where precision matters, writing is the tool that converts intuition into knowledge. You start with a feeling that something is true. You try to write it down. The writing either succeeds (confirming the intuition) or fails (revealing the gap). Either outcome is progress.

This feedback loop is why regular writing practice makes you a better thinker over time, not just a better writer. Each cycle of write-examine-revise-write trains your ability to notice contradictions, spot gaps, and generate more precise formulations. Over months and years, this compounds.

The research backs this up

In case the theoretical argument isn’t convincing, the empirical evidence is strong.

A study published in CBE Life Sciences Education found that students who wrote about biology concepts showed significantly improved critical thinking skills, specifically in analysis and inference, compared to students who didn’t write. The non-writing group showed no improvement in these areas.

Research from the Norwegian University of Science and Technology found that handwriting engages more areas of the brain associated with creativity and critical thinking than typing. The slower pace of handwriting forces more reflective and deliberate thinking, fostering creativity and critical analysis. (The speed difference matters: typing is fast enough that you can transcribe thoughts without processing them. Handwriting is slow enough that you have to compress as you go.)

Oatley and Djikic at the University of Toronto published a paper called “Writing as Thinking” that frames writing as an active process of meaning-making. Their key finding: writing is not the transcription of pre-formed thoughts. Writing involves continuous cognitive engagement where ideas are generated, evaluated, and revised cyclically and in real time.

This matches my personal experience exactly. When I write about a problem, I’m not recording a solution I already have. I’m computing the solution in real time, using the page as an external processor.

A practical system for writing-as-thinking

Theory is nice. Here’s what I actually do.

The morning write. Every workday, before I open Slack or check email, I spend 15-20 minutes writing about whatever technical problem is currently on my mind. No outline. No structure. Just a blank page and the question “what am I trying to figure out?” This is not journaling. This is directed thinking on a specific technical problem. Most days, I don’t produce anything publishable. But I almost always produce clarity.

The pre-code write. Before starting any non-trivial implementation, I write a short document (usually 1-3 paragraphs) answering three questions:

This takes ten minutes. It saves hours. Not sometimes. Almost always.

The post-mortem write. When something goes wrong (a bug, a bad design decision, a missed deadline), I write about it. Not a formal post-mortem document with root causes and action items. Just a narrative: “Here’s what happened, here’s what I was thinking at each decision point, here’s where my thinking went wrong.” The narrative format forces me to reconstruct the actual chain of reasoning, not the retrospectively rationalized version.

The weekly synthesis. Every Friday, I spend 30 minutes reviewing the week’s writing and extracting the insights worth keeping. Most of what I wrote during the week was the process of thinking, not the result of thinking. The Friday synthesis captures the results and discards the process.

The cost of not writing

There’s a cost to writing: time. Twenty minutes here, thirty minutes there. In a culture that valorizes shipping fast and iterating, time spent writing can feel wasteful.

But the cost of not writing is higher. It’s just invisible.

Not writing means carrying unexamined assumptions into your implementation. It means building on shaky foundations that feel solid because you’ve never subjected them to the stress test of articulation. It means repeating the same mistakes because you never wrote down what went wrong and why. It means spending an hour in a meeting where six people talk past each other because nobody committed their position to writing before the meeting started.

Amazon’s six-pager culture exists because Bezos noticed this exact cost. Meetings without pre-written memos were meetings where people were thinking out loud, reacting to each other’s half-formed ideas in real time, and leaving with different understandings of what was decided. The six-pager forces the thinking to happen before the meeting, so the meeting can be about evaluating thinking rather than generating it.

The engineers I know who write regularly, not for publication, but for their own thinking, share a few common traits. They make fewer false starts. They explain their designs more clearly. They catch problems earlier. They change their minds more readily (because writing makes it obvious when the evidence contradicts your position). They build fewer things they later have to throw away.

I don’t think writing is a silver bullet. Some problems require sketching, or prototyping, or just staring at a whiteboard with a colleague. But writing is the highest-ROI thinking tool I’ve found, and it costs nothing but time and a blank page.

The uncomfortable truth

Here’s the part that makes people squirm. If writing is thinking, then not writing is not thinking. Or at least, not thinking with any rigor.

That’s a harsh claim. But consider it honestly. How many times have you had an idea that “felt right” and built on it, only to discover a fundamental flaw weeks later? How many meetings have you sat through where everyone agreed on a plan that nobody had actually thought through? How many design documents have you reviewed that were clearly written after the code, as a retroactive justification rather than a genuine exploration?

The fix is simple, even if it’s not easy. Write before you build. Write before you meet. Write before you decide. Not because the writing will always reveal a problem. But because when it does, you’ll catch the problem when it costs twenty minutes to fix instead of two weeks.

Feynman, Zinsser, Bezos, Graham, Lamport. They come from different fields and different eras. They agree on this one thing: the act of writing is the act of thinking, and people who skip the writing are skipping the thinking.

Pick up a pen. Open a blank document. Write “what am I trying to figure out?” at the top.

Then find out.