$engineering
memos

MEMO-2026-001

The act of publishing

-- listen
0:00 / 3:22
memosThe act of publishing
0:00 / 3:22

Shipping and publishing are two different acts, and as engineers, most of us only practise one of them throughout our careers. Shipping answers to the machine: does it run, is it correct, does it hold at three in the morning. The feedback is mechanical and fast, and we live in it. Publishing answers to people: is it true, is it clear to a stranger, is it ours to stand behind.

Our principles are what first turned me toward publishing the colophon of these memos, the harness that drafts and narrates them: this site already runs on showing the work, and a colophon is that same transparency pointed at how the memos are made. The surprise was the act itself. That harness is code, built as infrastructure before there was any memo, so publishing it alongside this first one laid both acts over a single object at once, the familiar shipping and the unfamiliar publishing in one motion. The code did not change. The standard it answered to did, and the unfamiliar one asked far more of us.

A publishing mindset is worth building for that demand, and it matters more now than it ever has. As producing code gets cheap, the scarce thing is no longer the code; it is the judgement you will put your name to in the open. Everyone already agrees judgement is the moat . We already practise a version of it: a teammate reads our code at review and we defend the choices. But publishing widens the circle from a colleague who shares our context to a stranger who does not, and the bar climbs with it. Done honestly, even ordinary shipping starts to feel like publishing.

The closest we have come to that is open source: code in the open, the whole point being that anyone can read it, collaboration and judgement and the coding held together in one public act. So the obituaries for open source , and February’s $285 billion SaaS sell-off on a bet that AI makes software disposable, are one anxiety, not two: the fusion coming apart, the coding commoditised out from under the judgement that used to travel with it. The sober reading was never that the work is dead, only that its old shape is.

That standard falls on the maker, and the maker is no longer only a human. I built much of this harness alongside an agent that never knew any of it would be published, and I kept that to myself. GitHub Next has floated a version of this as goal-setting for the agent: ask whether it is proud of its work , and have it iterate until it is. I do not know whether telling the agent the work would be read would have changed what it made. But I can put the question to the human half of the maker: would I be proud that this was published? That much, at least, I can ask before shipping a line.

The colophon is public, and exposing it does make the work better by forcing judgement earlier and higher than a code review or a pull request can. Amazon has teams write the customer press release before they build the product , and kills the idea if that release does not land, before a single engineer is assigned. That is the mindset worth practising now: answer for the whole, as if it were public even when it will not be, before you can hide in the parts.

You are invited to read the colophon, use it, and hold us to it.

work with us

If this is your kind of engineering, we're hiring.