Simon Willison published a piece on technical blogging this week. The topic recurs, and the standard defence — build an audience, advance your career — undersells it.

The stronger argument is about what writing does to your own understanding.

Writing is where vagueness dies

You can hold a belief like "our retrieval got better after we changed the chunking" indefinitely without examining it. It feels like knowledge.

Try to write it down and you immediately face questions you had been skipping:

• Better on what measure?
• Compared to which baseline?
• How much of the gain was the chunking versus the reranker you changed in the same week?
• Did you check whether it held on the hard subset?

Most of the time, sitting down to explain a result is when you find out you do not fully understand it. That failure is the product. The published post is a by-product.

The abundance argument, inverted

The obvious objection is that generated text is now abundant, so why add more.

That gets the economics backwards. When text is cheap, specificity becomes the scarce good. A post that says "we tried X and here are the numbers, including the ones that did not support our hypothesis" cannot be generated, because the information is not in any model. It came from you doing the thing.

The posts that have lost value are the ones that were always low-value — introductory overviews, rephrased documentation, listicles. The posts that gained value are the ones grounded in specific experience: this broke, here is why, here is what the profiler said.

The compounding effect nobody mentions

The underrated benefit is searching your own archive. Any engineer with a few years of writing has had the experience of hitting a problem, searching, and finding their own post from three years ago describing the solution.

Your past self is a better source than most, because they were working on your codebase with your constraints. Notes in a private file work too, but posts are better-written, because writing for an audience forces the context that private notes omit.

What makes a technical post worth writing

• A specific problem you actually hit, not a general topic.
• The numbers, including the unflattering ones.
• What you tried that failed, which is usually the most useful part and almost always cut.
• Enough environment detail that a reader can tell whether it applies to them.
• A clear statement of what you are still unsure about.

That last one is what separates writing that helps from writing that performs. Most technical posts are written to demonstrate competence. The useful ones are written to work something out.