Two hundred pieces in

This is the two hundredth piece published here. That seems like a reasonable moment to write about the writing rather than about the subject.

what it did to my engineering#

It forced me to actually understand things. You can hold a fuzzy model of a technology in your head indefinitely and it feels like knowledge. The moment you try to explain it in a paragraph, the fuzziness becomes visible.

I have abandoned drafts because I discovered, four hundred words in, that I did not understand the thing well enough to write about it. Every one of those was more educational than the pieces I finished.

It made me check things. Writing "X is faster than Y" in public means someone will ask for numbers. Knowing that in advance changes how you form the belief in the first place.

It made me notice my own patterns. Reading two hundred pieces of my own writing back, the recurring themes are obvious to me now and were invisible while writing: verification over generation, boring over clever, measurement over intuition, and a persistent suspicion of anything that requires you to trust rather than check.

I did not set out with a thesis. It assembled itself.

It taught me to be wrong in public, which is a skill and is uncomfortable and is the only way to find out you were wrong quickly.

what I have been most wrong about#

I graded myself in December and the pattern held for the following eight months.

I am reliably right about technical trajectories and reliably wrong about adoption.

Local models got good; people did not switch, because hosted models got cheap faster than I expected. RAG got less necessary; the infrastructure repositioned instead of dying, which I have now failed to predict three separate times. Registry security controls were obviously needed; they arrived after the incident rather than before.

The lesson I keep relearning: the technology is the easy part to forecast, and the technology was never the hard part. Human and organizational behavior is where the uncertainty lives and where the consequences land.

I under-predict inertia and over-predict rationality. Almost every wrong call has that shape.

the thing about writing news#

Two hundred pieces, roughly half of them about things that happened in a specific week.

Reading them back, the ones that held up are almost never the ones that reported the event. They are the ones that used the event to explain a mechanism.

Nobody needs my summary of what a company announced. They can read the announcement. What is worth writing is: why does this shape of thing keep happening, and what does it imply for what you should do on Monday.

The news is a prompt. The mechanism is the article.

I did not know that when I started and it took about forty pieces to figure out.

on the archive#

Everything published here is still at its original URL. Nothing has been quietly edited, renamed, or removed. Corrections are marked in place.

That is a deliberate choice and it costs something — there are pieces I would write differently now, and a few I think are wrong.

Leaving them up is the point. A publication that silently revises its history is not a record, it is a marketing surface. The value of an archive is that it shows what someone thought at the time, including when that was wrong, and you can only get that by not touching it.

If you want to know whether to trust a technical writer, check whether their old pieces still exist and whether the wrong ones were corrected in the open.

on the format#

Gray background. Monospace headings. One column. No popups, no cookie banner, no newsletter modal, no autoplaying anything, no third-party JavaScript on any page.

This is not minimalism as an aesthetic. It is that every one of those things was added to a website to serve the publisher at the reader's expense, and the cumulative effect has made reading on the web genuinely unpleasant.

A page should render before you notice it loading. Text is the interface. Nothing moves unless the reader moved it.

Those are not hard constraints to meet. Almost nobody meets them, and the reason is never technical.

the next two hundred#

Same beat. Tech, developers, and the code underneath. News where the news teaches something, essays where the news does not.

More on the verification problem, because it is the defining engineering question of this period and it is nowhere near resolved. More on the craft, because the craft is what survives the tooling cycles. Fewer pieces about model launches, because they have stopped being informative.

Thanks for reading. Corrections are always welcome and get priority over everything else.

— Dom