Why I think more clearly when I type

I think more clearly when I type.

The keyboard doesn’t give me better ideas, but typing changes how I work on them.

Speaking is faster. A voice note catches a thought before it disappears, and dictation can produce a lot of words in a few minutes.

But when I want to understand something, I go to the keyboard.

Typing slows me down, and I think that’s the useful part. There is a small delay between having a thought and having a sentence, and in that delay I get to see if the thought makes sense.

I don’t have a study to back this up. It’s what I noticed after years of writing blog posts, tutorials, ebooks, lessons, notes, and code. Writing has always been how I learn. Many times I start with a question and find out what I think while I answer it. The keyboard is part of that.

Capturing a thought is not developing it

We use the word “writing” for two different jobs.

The first is capture. An idea shows up while you’re walking or cooking, and you want to save it before your mind moves on to something else.

Voice is great for this. I have taken vocal notes while walking, so I can catch an idea without opening a laptop. They are one small part of the productivity system I use to keep ideas around without interrupting what I’m doing.

Most of those ideas never turn into anything, and that’s fine. Capture should be cheap, and its only job is to stop a possibly useful thought from vanishing.

The second job is development. You sit with the idea. You ask what it means, what belongs in it and what does not, and which part is useful to someone else.

Here typing works much better for me.

When I dictate, I can keep talking around a weak idea. The words keep coming, and the momentum hides the fact that I haven’t made a point yet.

When I type, the sentence sits there on the screen. Does it say anything? Does the next one follow from it? Am I repeating myself? Did I pick a vague word because I don’t understand the detail?

Typing turns a thought into something I can look at.

Writing is one of the ways I learn

I wrote before that writing forces me to think, and it happens all the time on this blog.

I start with a small question and write the first line. That line raises another question, so I follow it. At some point I write a sentence I did not have in my head when I started.

The thought gets made while I write it. There was no finished version to transcribe.

Technical writing makes this very visible. Say I start an explanation like this:

A transaction groups database operations.

Correct, but incomplete. Why group them? What happens when one of them fails? I also need to know what problem the reader had before they got here.

The first sentence creates the next questions, and answering them is what creates the article.

And if I can’t explain something with simple words, I usually don’t understand it well enough yet.

The screen gives the thought a shape

Spoken words are gone as soon as you say them. Typed words stay where you put them.

A paragraph has a shape I can see. I can tell when it’s too long. I can spot a statement sitting alone that needs an example, or notice that three sections are making the same point.

Headers make the whole argument visible at once:

What is the problem?
Why does it happen?
How do we solve it?
What should we be careful about?

Before I fill in any of those sections, I already have a map.

This is one of the reasons I like Markdown so much. There is almost nothing between the thought and the page. It’s plain text, and I can still see the structure.

For me, moving a paragraph, splitting a sentence or turning a line into a heading is part of the thinking, not cleanup at the end.

Slower can finish sooner

We measure writing speed in words per minute. That’s the input speed. It says nothing about how much of it is useful.

If I dictate 2,000 words and later delete 1,200 of them, the first number was misleading. If I type 900 words that already go somewhere, the slower method probably finished first.

Typing adds a bit of friction. My hands can’t keep up with every thought, so I have to pick one sentence. That choice is already an edit.

I draft and edit in small cycles. Write a paragraph, read it, change a line, go on.

The edit is rarely about grammar. Most of the time it changes the idea. A broad claim becomes a smaller one I can support. A sentence that sounded clever but didn’t help goes away. Sometimes I notice the explanation is too abstract and add an example.

Take this sentence:

This approach improves the developer experience.

What does that mean? Does setup take less time? Are the errors easier to understand? Can a new person run the project with one command?

I might end up with:

A new developer can clone the project and start it with one command.

Now the claim can be checked. And the vague sentence told me the thought behind it was vague too.

Deleting is thinking

I delete a lot. The deleted words are not wasted.

Sometimes I need to write the wrong paragraph before I see the right one. The wrong paragraph shows me I started too far from the reader’s problem, or that I explained the history before the reader knew why the topic mattered. Then I cut it and start closer to the useful part.

Typing makes this cheap. I can cut a section, park it below the draft, and see if the article is better without it.

Why this matters in a tutorial

Tutorials need a careful order. The reader needs context before the code, the code should show one thing, and the explanation after it should point at what changed.

I think in a small loop:

1. What are we about to do?
2. What is the smallest useful example?
3. What does the reader need to notice?

Typing lets me tune each of those separately. I can remove code that doesn’t serve the concept, or move a warning to after the first working example. A big code block might become two steps.

Code is also spatial. Indentation matters. So do file names, and one missing character breaks the example.

With the keyboard, the explanation stays close to the thing I’m explaining. I run the example, copy the result, and fix the paragraph right away.

Voice still has a place

Voice is useful when there is no keyboard around. A note can be very short:

Post idea: why build caches fail when tools write outside the framework cache.
Include the Open Graph image example and cold versus warm build time.

That’s enough to recognize the thought later. Back at the computer, I decide if it deserves a draft.

Voice also helps after I write. Reading a paragraph out loud shows me the awkward rhythm. A sentence that looks fine on screen but is impossible to say is usually too long.

Other people work differently. Someone who has dictated for years can probably compose clean prose by speaking. And accessibility needs matter too.

I’m only describing the loop that works for me:

think → type → see → revise → continue

Seeing the thought on screen is what helps me react to it.

The keyboard is where the idea becomes specific

I can think about a topic for days and still have only a cloud around it. The cloud feels complete because there are no sentences yet to challenge it.

Then I start typing. The first sentence forces a choice, and the second one has to connect to it. An example shows a detail I was missing, or a header exposes a jump in the argument.

Slowly, the cloud turns into something another person can read.

Want me to talk about your product? You can sponsor this site.