Write the Manual You Wished You Had (Even If Nobody Reads It)

Every self-taught developer eventually hits the same wall: the tool you're trying to learn has terrible documentation. Maybe the README was last touched in 2019. Maybe the official docs assume you already understand the concept you came here to learn. Maybe there are fourteen blog posts, all contradicting each other.

Most people complain and move on. You should do the opposite. You should write the documentation yourself — and I'd argue it's the single highest-leverage learning habit you can build after "actually writing code."

The Documentation Gap Is Your Syllabus

Here's the thing about badly documented tools: the gap between what the docs say and what you needed to know? That gap is your curriculum. It tells you exactly where the hard parts are, exactly where the next person will get stuck, and exactly what's worth writing about.

When you document a tool as you learn it, you're not doing charity work (though the community will thank you). You're doing the most demanding form of studying there is. Reading a tutorial is passive. Following along is semi-active. But explaining how something works, in your own words, for an audience — that's the point where your brain stops pretending and starts actually processing.

You've probably heard of the rubber duck technique: explain your problem out loud and the answer often surfaces. Writing documentation is the rubber duck with a permanent memory.

Why Public Beats Private

You could keep these notes in a private Notion page. Some people do, and it works fine. But putting your docs somewhere public — a GitHub repo, a personal site, a dev.to series — changes the game in three ways:

1. It raises your personal bar. When only you will read it, "it works" is enough. When it's public, you find yourself double-checking the config step, testing the example command, adding the caveat you almost skipped. That extra rigor is where the real learning lives.

2. It becomes searchable and permanent. Six months from now, when you (or a coworker) hit the same weird Docker networking issue, your notes are one Google query away. Your future self is the most important reader you'll ever have.

3. It compounds into proof. A repo full of clear, honest documentation says more about your communication skills than any line on a resume. Hiring managers can see how you think — and unlike a portfolio project, docs show the why, not just the what.

A Workflow That Actually Sticks

Don't overthink this. The whole point is to lower the friction, not raise it. Here's the loop I'd suggest:

Step 1: Pick something with thin docs. An internal tool at work. A niche library you needed last week. A config file that took you three Stack Overflow threads to get right. Small beats ambitious — "How I set up ESLint with TypeScript in 2025" is a perfectly good first entry.

Step 2: Write while the pain is fresh. The moment you get something working, open a blank file and write down what you just did. What did the docs say? What did they leave out? What was the actual command that worked? Fifteen minutes, tops. If you wait until the weekend, the struggle fades and so does the insight.

Step 3: Structure for the next you. Every entry should answer three questions: What was I trying to do? What went wrong the obvious way? What worked? That's it. No need for polished prose — you're writing a field guide, not an O'Reilly book.

Step 4: Iterate without guilt. Your early entries will be rough. Some will turn out to be wrong. Update them. A doc that admits "I originally thought X, but actually Y" is more honest and more useful than something pretending to be authoritative.

Step 5: Occasionally share one. Post the best entries on Reddit, Hacker News, or your LinkedIn. Sometimes you'll get corrections — free expert review of your understanding. Sometimes you'll get a thank-you from someone stuck at 2 a.m. on the same problem. Both are wins.

"But I'm Not an Expert"

This is the objection that kills most documentation projects before they start, and it's based on a misunderstanding. You're not writing the official reference. You're writing a beginner's field notes — and beginners write better field notes for beginners than experts ever will, because the expert forgot what was confusing twenty years ago.

There's even a name for the trap experts fall into: the curse of knowledge. The person who can no longer explain what a virtual environment is because to them it's just "obvious." You, learning it this week, are the perfect person to explain it to next week's you.

And if you get something wrong? Someone will tell you. That's not embarrassing — that's a free code review of your brain.

Start Tonight

Think back to the last tool that made you mutter "why isn't this documented anywhere?" That frustration was a flash of insight. Capture it.

Open a repo called something like notes-to-myself or docs-i-wish-existed. Write one entry tonight about whatever you learned today. Keep it ugly, keep it honest, keep it going.

In a year, you'll have a personal knowledge base that no course could sell you, a public record of how you learn, and — more often than you'd expect — a resource that other people genuinely needed and couldn't find.

That's the quiet superpower of the autodidact: you don't have to wait for someone to write the textbook. You're already holding the pen.