Thinking Through Writing — Clarity Comes From the Page

• Opening — Writing Is Not the Result of Thought, It Is a Tool for It
• 1. Why Writing Clarifies Thought
  • Thoughts in your head are vaguer than they feel
  • Writing is both external memory and a debugger
  • Clear writing vs. vague writing — same content, different thinking
• 2. The Feynman Technique — Write As If Teaching
  • A Feynman-style writing checklist
• 3. Writing by Tool — What Goes Where
  • Comparison table — formats for writing to think
  • Design docs — write before you build
  • Architecture decision records (ADRs) — for your future self
• 4. Writing Daily — A Routine You Can Sustain Without Strain
  • Small, but every day
  • Morning pages vs. evening retrospective
  • Small devices that help you keep going
• 5. Writing in Public — Learning While Sharing
  • Why publish at all
  • The realistic pros and cons of public writing
  • When you are afraid of being wrong
• 6. The Power of Editing — A First Draft Is Only Raw Material for Thought
  • Separate writing from revising
  • Editing is a second round of thinking
  • Before-and-after editing example
  • A self-editing checklist
• 7. Structuring — Giving Thought a Skeleton
  • Skeleton first, then flesh
  • Seeing the flow of writing as a diagram
  • The structure of a single paragraph
• 8. Writing in the Age of AI — A Skill That Matters More
  • If AI writes for you, why write yourself
  • Writing skills that matter more in the AI age
  • Using AI as a thinking partner
• 9. Cases — Moments When Writing Changed the Work
  • Case 1. A stuck bug solved by a single memo
  • Case 2. A document instead of a meeting
  • Case 3. A correction prompted by a public post
• 10. A 7-Day Routine to Start Today
• 11. When You Are Stuck — Beating the Blank Page
  • Being Stuck Is Not Laziness
  • Types of Block and Their Remedies
  • Concrete Moves to Break a Block
• 12. Collaboration and Writing — Thinking for the People You Work With
  • Writing in an Asynchronous Age
  • Pull Request Descriptions — What to Write
  • Review and Feedback Are Writing Too
  • Collaborative Writing Checklist
• 13. Common Myths — Lies About Writing
  • Tools Only Assist
• Closing — Clarity Is Not a Talent but a Habit
• References

Opening — Writing Is Not the Result of Thought, It Is a Tool for It

Many people understand writing like this. First you finish thinking in your head, then you transfer the completed thought onto the page. In that order, writing is little more than transcription. Thought comes first, and writing is its shadow.

But anyone who has tried to write something seriously knows that the order is often reversed. A topic you felt you understood completely collapses the moment you try to put it into sentences. There is a wider gap than you would expect between the feeling that "I understand this problem" and the ability to "explain this problem in a single sentence."

This essay is about that gap. It treats writing not as a skill of expression but as a tool for thinking, and it focuses on concrete ways to fold that tool into a daily routine. I will strip away the self-help exaggeration ("writing will change your life") as much as I can and concentrate on what you actually do, sitting at your desk.

"If you can't write it down, you don't really understand it. Writing reveals how sloppy your thinking is." — Paul Graham, paraphrasing his essay "Putting Ideas into Words"

1. Why Writing Clarifies Thought

Thoughts in your head are vaguer than they feel

In your head, thoughts move fast and feel smooth. But that smoothness is often an illusion. We do not actually connect concepts precisely; we lump them together and move on with the mere feeling of understanding. Cognitive science calls this the "illusion of explanatory depth." Asked to write out, in detail, how an everyday object like a zipper or a toilet works, most people grind to a halt.

Writing breaks this illusion. Sentences are linear. You must put B after A and C after B. The instant you force concepts that were floating around together into a single line, the missing links appear. If you try to write "and so A leads to B" but cannot explain that "and so," there is a hole right there.

Writing is both external memory and a debugger

Working memory is narrow. You can hold only a handful of items at once. Juggle a complex problem in your head alone and the moment you grab one side, you drop another. Writing extends that working memory onto the page. Once something is written down, you no longer have to hold it in your head, and you can spend the freed-up capacity on the next step.

Writing also works like a debugger. Just as you step through code line by line to see where it went wrong, you step through your thinking sentence by sentence to see where the logic breaks. The common experience of "I realized I was wrong as I was writing it" is evidence that writing is an error detector for thought.

Clear writing vs. vague writing — same content, different thinking

Let me write the same idea two ways.

The vague version:

Our service feels slow lately. Traffic seems to be up, and the database seems to have some issues, so maybe doing some caching or something would help.

The clear version:

Last week the p95 response time rose from 800ms to 2.1 seconds. Over the same period requests grew 1.4x, and 92 percent of the slow requests are concentrated on the product-detail API. That API joins three tables — product, inventory, and reviews — on every request. Inventory and reviews tolerate a 30-second cache, so I propose caching those two first to reduce the join.

The difference between these is not prose skill. It is the resolution of the thinking. The person who wrote the vague version does not yet know the problem. To write the clear version you have to check the numbers, narrow the cause, and pin down a solution. In other words, the attempt to write clearly is itself what makes the thinking clear.

2. The Feynman Technique — Write As If Teaching

The physicist Richard Feynman suggested that the way to test whether you truly understand a concept is to explain it to someone learning it for the first time. Translated into writing, this technique — commonly called the Feynman technique — looks like this.

1. Pick one concept to explain.
2. Without using jargon, write it out as if teaching someone who knows nothing.
3. Mark the points where you get stuck — where you find yourself fudging with "it just works that way."
4. Those points are exactly what you do not know. Go back to the source material and refill them.
5. Repeat until the explanation flows.

The heart of it is step 3. Jargon is often a mask for not-knowing. "It is processed asynchronously" sounds plausible, but the moment you try to unpack it as "after sending the request, it does not wait for the answer but moves on, and handles the answer when it arrives," you reveal whether you really understand.

A Feynman-style writing checklist

• Did you use words a middle-schooler would understand?
• If you ask "why?" one more time, can you answer?
• Can you offer one analogy? (If no analogy comes to mind, you may not understand it yet.)
• Did you quietly skip over anything while explaining? Did you note that spot separately?
• Reading it back, can you answer "so what, in the end?"

3. Writing by Tool — What Goes Where

Writing for thinking is not a single format. Different vessels fit different purposes.

Comparison table — formats for writing to think

The point of the table is this: do not see writing as one heavy act. A short daily memo and a long quarterly retrospective are both writing-to-think, but the weight of each is entirely different.

Design docs — write before you build

The habit of writing a design doc before writing code is the most practical case of writing-to-think. The key is to put down the "why" and "what" before the "how."

[Design doc skeleton]

1. Problem
   - What is painful now, and who is affected?
   - What this doc solves and does not solve (Non-goals)

2. Context
   - How does it work today?
   - Relevant constraints (time, resources, existing systems)

3. Proposal
   - How will you solve it? The core design
   - Data flow / interfaces

4. Alternatives
   - Options considered but not chosen, and why

5. Risks
   - What could go wrong? How do you prepare?

6. Open questions

As you fill in this skeleton, the gaps in your design surface before you type a single line of code. It is common to discover a better approach while filling in the "Alternatives" section. The value of a design doc lies not in the document itself but in the thinking it forces while you write it.

Architecture decision records (ADRs) — for your future self

If, right after making a decision, you jot down even briefly "why I chose this," then six months later you can answer the question "why on earth did we do it this way?" A decision record is usually this short.

Title: Chose Redis as the session store
Status: Accepted
Context: Sessions must be shared across multiple servers. Candidates: DB, Redis, cookie-based.
Decision: Use Redis.
Reason: The DB carries heavy read load; cookie-based has size limits and security concerns.
Consequence: One more cache server to operate. Must plan for session loss on failure.

4. Writing Daily — A Routine You Can Sustain Without Strain

Small, but every day

The most common failure in writing-to-think is "starting grand, then quitting after three days." The fix is simple: lower the bar to an absurd degree. Three sentences a day is enough.

• What problem did I spend the most time on today?
• What do I know and not know about that problem right now?
• If I leave one sentence for tomorrow's me, what is it?

Those three lines take five minutes. What matters is not polish but repeating, every day, the act of getting thoughts out of your head. Like a muscle, in writing, frequency beats intensity.

Morning pages vs. evening retrospective

There is no right answer. Pick the side that fits your rhythm, make it a habit first, then add the other side if you need to.

Small devices that help you keep going

• Write in the same place, at the same time. Eliminate the cost of deciding.
• Start from a template with questions on it, not a blank screen.
• Do not fuss over spelling or sentences. First drafts are supposed to be rough.
• Set a minimum of "just one line today." It is a safety net for low-energy days.
• Do not blame yourself for missing a few days. Count the day you restarted, not the day you broke.

5. Writing in Public — Learning While Sharing

Why publish at all

When you do not leave your writing in a drawer but publish it, a new pressure is added to your thinking. The possibility that "someone could read this and push back" makes you look again at the parts you glossed over. This is what people call "learning in public."

It is easy to overstate the benefits of writing in public, so let me be honest. Most posts go almost unread. It is rare for a comment to change your life. The reason publishing is still worthwhile is not the readers' reactions but the fact that your thinking becomes more rigorous when you write assuming it will be public. The reader might be one person — a future you.

The realistic pros and cons of public writing

When you are afraid of being wrong

The biggest wall to publishing is the fear of "what if I am wrong." Two things help. First, when you publish something wrong, a kind person sometimes corrects it. Stay silent and it stays wrong forever. Second, if you honestly note "this is my current understanding," it becomes not a falsehood but an honest record. Simply adding "if you know a better way, please tell me" at the end greatly reduces the pressure.

6. The Power of Editing — A First Draft Is Only Raw Material for Thought

Separate writing from revising

The more of a beginner you are, the more you try to write the first sentence perfectly and end up not advancing a line. Writing and revising are different jobs. Writing is divergent; revising is convergent. Do both at once and you ruin both.

The order I recommend is this. First turn off judgment and pour out your head (the draft). Then put on the critic's hat and cut (the edit). As the line often attributed to Hemingway suggests, every first draft can be terrible. The draft's job is not to be good writing but to create material to revise.

Editing is a second round of thinking

Editing is not mere tidying. As you cut sentences and reorder them, the structure of your thought comes back into view. The question "is this paragraph really necessary?" is really the question "is this argument really necessary?" Good editing not only makes writing shorter; it filters the thinking one more time.

Before-and-after editing example

Before:

Honestly, I have been thinking about this part in a lot of different ways, and basically the way we are currently doing it is not all that bad, but I still feel there is definitely a bit of room for improvement, so I am going to try to lay it out.

After:

The current approach isn't bad, but there's room to improve, so I've laid it out.

Strip out the filler and the message comes into focus. Words like "honestly," "basically," "a bit of," and "all that" are mostly traces of low confidence.

A self-editing checklist

• Does the first sentence state the core, or does it start with an excuse?
• Does each paragraph carry only one idea?
• Did you delete words that can be deleted without changing the meaning? ("honestly," "really," "a bit," etc.)
• Can you change passive voice to active?
• If a sentence runs past two lines, can you break it?
• Would the piece be better if you moved the last paragraph to the front? (Is the conclusion buried?)

7. Structuring — Giving Thought a Skeleton

Skeleton first, then flesh

The longer the piece, the more you lose your way by writing sentences from the start. First list only the items to build a skeleton, reorder it while looking at it, and add flesh last. Most of the difficulty in writing is really a structural problem — "what to say, in what order." If the sentences won't come, nine times out of ten the structure is not yet in place.

Seeing the flow of writing as a diagram

   Thoughts in your head (vague, non-linear)
            |
            v
   [Dump it out] Draft -- judgment off, divergent
            |
            v
   [Structure] Build the skeleton -- list items, then order them
            |
            v
   [Edit] Add flesh and cut -- judgment on, convergent
            |
            v
   [Publish/Archive] Test and record
            |
            v
   Clearer thought (sharp, linear)
            |
            +────────────┐
                         | (cycle to the next topic)
                         v
                  A new question appears

The key to this flow is that it is not one direction but a cycle. Clearer thought almost always gives rise to a new question, and that question becomes the starting point of the next piece.

The structure of a single paragraph

A good paragraph usually has this skeleton. Start with one sentence of claim, support it with evidence or an example, and close with one sentence of summary. Keeping just this simple frame makes writing sharper. Check every paragraph by asking yourself, "so what is the one-line summary of this paragraph?"

8. Writing in the Age of AI — A Skill That Matters More

If AI writes for you, why write yourself

Generative AI produces plausible sentences in an instant. Does that make writing skill an outdated craft? I believe the opposite. The reason is in the opening of this essay. The real value of writing is not the output but the thinking that happens while you write. Hand the writing to AI and you get the output but skip that thinking process.

By analogy, it is like a calculator. Even with a calculator, a sense for numbers still matters, because to notice when an answer is absurd you need to estimate it yourself. The power to notice when AI-written text is plausible but wrong comes from people who have done the writing themselves.

Writing skills that matter more in the AI age

Using AI as a thinking partner

There is no need to bar AI from your writing. But the order matters. First make the draft and skeleton yourself, then use AI as an editor or a sparring partner. Questions like "what is the weak point of this argument?", "what counterexample did I miss?", and "if I cut this paragraph shorter?" are things AI helps with well. Hand it a whole blank page, by contrast, and the output is average and your thinking does not grow. AI is most useful not as a tool to replace thinking but as a mirror that reflects it.

9. Cases — Moments When Writing Changed the Work

Case 1. A stuck bug solved by a single memo

There was a bug I had chased for half a day without finding the cause. To ask a colleague for help, I started writing out the situation. "This function takes this input, processes it like this, and so..." The instant I wrote that "and so," I realized the order of processing differed from my assumption. The problem was solved before I even sent the message. This is what people call "rubber duck debugging." The very act of trying to explain pulls out the answer.

Case 2. A document instead of a meeting

A team that kept repeating the same argument decided to write a one-page proposal before each decision. Meetings began by reading that document. Surprisingly, meeting time went down. Because the points were settled while writing, the time spent talking in circles disappeared. Writing is slower than speaking, but that slowness forces thought.

Case 3. A correction prompted by a public post

I wrote up a concept and posted it on a blog. A few days later a reader pointed out, in a comment, a subtle but important misunderstanding. Had I kept it only in a private notebook, that part would have stayed wrong forever. The value of publishing lies not in applause but in corrections like this.

10. A 7-Day Routine to Start Today

Grand plans usually fail. So here is a small proposal.

• Day 1: Write in three sentences the thing you mulled over the longest today.
• Day 2: Pick the vaguest sentence from yesterday's writing and rewrite it.
• Day 3: Explain one concept you are working with, Feynman-style, without jargon.
• Day 4: Write the skeleton of a design doc (problem/proposal/alternatives) for upcoming work.
• Day 5: Edit one past piece. Delete only the filler words.
• Day 6: Publish one short piece. Start with "this is my current understanding."
• Day 7: Look back on the week and write a paragraph on what became clearer.

Seven days will not change your life. But one thing will become clear: that your thinking before writing and after writing is different. Once you feel that difference, it becomes harder to quit writing than to keep it up.

11. When You Are Stuck — Beating the Blank Page

Being Stuck Is Not Laziness

When the words will not come, we tend to blame ourselves for weak willpower. But most blockages are not problems of will; they are problems of information or structure. Either you do not yet have enough to say, or you have it but the order has not settled. Read being stuck as a signal, and the next action appears in place of self-reproach.

Types of Block and Their Remedies

Concrete Moves to Break a Block

• Write the easiest part first. Writing need not be done in order. If the conclusion is clear, start there; if an example is vivid, start with it.
• Explain it aloud to yourself first, as if speaking, then transcribe what you said. An explanation that flows from the mouth often jams at the hand.
• Fill in the blank: "What I am trying to say, in one line, is ___." If you cannot fill it, you are not yet ready to write.
• Set a ten-minute timer and keep your hands moving for that whole time. It can be a mess. The goal is not good writing but momentum.

"The biggest lie about writing is that you must wait for inspiration. The truth is the reverse: you must begin to write, and then inspiration comes."

12. Collaboration and Writing — Thinking for the People You Work With

Writing in an Asynchronous Age

As remote work and distributed teams grow, we spend more hours working through writing than through speech. Issues, pull request descriptions, chat, documents. These are not mere reports; they are the work of drawing the same picture in another person's mind. One well-written note removes a meeting; one poorly written note summons three.

Pull Request Descriptions — What to Write

A note explaining a code change is a small model of collaborative writing. A good description carries not "what I changed" but "why I changed it, and how I verified it."

[Skeleton of a good change description]

Background: What problem makes this change necessary?
Change: What was changed and how? (the big picture first)
Verification: How was the behavior confirmed?
Impact: What changes along with it? What should reviewers watch for?
Alternatives: Was there another way? Why this one?

Readers cannot infer intent from code alone. A change description that omits the "why" forces the reviewer to play detective. A paragraph or two of context cuts review time in half.

Review and Feedback Are Writing Too

The feedback you leave on someone else's writing or code is also writing for thought. "This looks off" is an emotion; "What happens in this case if the input is empty?" is thought. Good feedback often takes the shape of a question rather than a verdict, because a question opens the other person's thinking rather than closing it.

Collaborative Writing Checklist

• Did you picture one specific reader as you wrote?
• Did you place the conclusion or core request up front?
• Can someone without the background follow along?
• Is it clear what you want the other person to do?
• Did you write with questions and facts rather than blame?

13. Common Myths — Lies About Writing

What blocks writing for thought is often a mistaken belief. Here are the myths I hear most often.

The table makes a single point. Most of the difficulty of writing is not a problem of ability but a problem of how you regard writing. The moment you see it as a process rather than a result, as repetition rather than talent, the threshold to begin drops sharply.

Tools Only Assist

A brief word, finally, about tools. Which note app or which editor you use matters less than you think. Far more common is the person who keeps postponing the writing itself while shopping for the perfect tool. One text file, one sheet of paper, is enough. What matters is settling on a single familiar tool so you can begin writing immediately, without friction. The energy you would spend switching tools is almost always better spent writing one more sentence.

Closing — Clarity Is Not a Talent but a Habit

People who think clearly were not born that way. Mostly, they are people who write and revise until it becomes clear. There is no need to be ashamed of the vagueness in your head. Everyone's head is vague at first. The difference lies in whether you draw it out onto the page and refine it.

Write three sentences today. Do not try to write well; just get what was in your head out into the open. From there, thought finally becomes something you can hold.

References

• Paul Graham, "Putting Ideas into Words" — https://www.paulgraham.com/words.html
• Paul Graham, "Writing, Briefly" — https://www.paulgraham.com/writing44.html
• The Feynman technique (Wikipedia: Richard Feynman) — https://en.wikipedia.org/wiki/Richard_Feynman
• Rubber duck debugging (Wikipedia) — https://en.wikipedia.org/wiki/Rubber_duck_debugging
• The illusion of explanatory depth (Wikipedia) — https://en.wikipedia.org/wiki/Illusion_of_explanatory_depth
• Will Larson, "Writing engineering strategy" — https://lethain.com/
• Architecture Decision Records (ADR) — https://adr.github.io/
• HBR, on business writing skills — https://hbr.org/
• William Zinsser, "On Writing Well" (Wikipedia) — https://en.wikipedia.org/wiki/On_Writing_Well
• Working memory (Wikipedia) — https://en.wikipedia.org/wiki/Working_memory
• Amazon's six-page narrative culture — https://www.amazon.jobs/en/landing_pages/about-amazon
• Paul Graham, "The Age of the Essay" — https://www.paulgraham.com/essay.html
• Learning in public — https://www.swyx.io/learn-in-public/