Most people think documentation is the final step.

The project is done. The bugs are fixed. Everything works.

Now it’s time to write the documentation.

I’ve started believing the opposite.

Documentation isn’t a summary of what happened.

It’s a record of what actually happened.

The mistake

Whenever I built something, I’d tell myself:

“I’ll document it later.”

Later never came.

Or worse, I only remembered the polished version.

I forgot the dead ends.

I forgot the strange error messages.

I forgot why one solution failed and another worked.

The final article looked clean—but it wasn’t truthful.

The real value

Recently I found myself solving problems like these:

• A sed command that kept failing because of quoting.
• A file split operation that produced nothing but placeholder files.
• A Hugo layout that almost worked, except for one tiny detail.
• A multilingual project that became impossible to maintain because I duplicated everything.

Those mistakes were the documentation.

The solution alone wasn’t the interesting part.

The journey was.

Documentation is debugging

When I write while I’m building, I naturally capture things like:

• what I expected
• what actually happened
• the commands I ran
• the exact error message
• what I searched for
• why I rejected one solution
• why the final solution worked

Months later, that’s far more useful than a perfect tutorial.

Small notes become articles

A note as simple as:

split: too many files

doesn’t look valuable.

Until six months later…

You search your own notes because you’ve forgotten the solution.

Suddenly that tiny note becomes the beginning of an article.

My new workflow

I no longer wait until a project is complete.

Instead, I keep a running Markdown file beside the project.

It doesn’t have to be pretty.

Just enough to answer questions like:

• What was I trying to do?
• What broke?
• What did I try?
• What finally worked?
• What would I do differently next time?

By the time the project is finished, most of the article already exists.

The unexpected benefit

Writing documentation while building has another advantage.

It slows me down just enough to think.

Many times I’ve caught a bad design decision simply because I tried to explain it in writing.

If I can’t explain why something exists…

Maybe it shouldn’t exist at all.

Final thought

The best technical documentation isn’t written by someone who remembers everything.

It’s written by someone who captured the confusion before they forgot it.

That’s the version future-you will actually thank you for.