On the engineering memoir

The industry's most honest technical writing lives in a genre with no name and no publisher. Call it the engineering memoir: a practitioner explains, in public, how a system of their own actually works, why it is built the way it is, and what they would change. Not a tutorial, which teaches a tool; not a postmortem, which explains a death. An account of a living system by the person who lives with it.

The genre's virtue is structural. Most technical writing is adversarial to the reader in small ways: the vendor post selects facts toward a purchase, the conference talk selects toward a promotion, the official docs describe the system as designed rather than as operated. The memoir has nothing to sell and no committee to pass. When a consultant documents how their own site works, end to end, the account is checkable against the running artifact in a way no enterprise architecture document ever is: the site is right there, doing the things the essay says. The genre's contract is verifiability, and its readers can hold the author to it, which is precisely why the writing tends to be careful.

Nor is the genre confined to infrastructure, or to prose in English. Floor796, an isometric pixel animation of one endless space-station floor, has been growing scene by scene for years under a single animator, and when ordinary video formats could not carry the piece he invented one, then wrote up the renderer with the reasoning and the byte counts attached. The contract holds across the change of medium: the artifact is live at floor796.com, the account is checkable against it one tab away, and a longer tour of the project exists for readers who would rather begin with the zoom control than the compression ratios.

The enterprise objection arrives immediately: our systems are too large, too sensitive, too collectively owned for memoir. The objection mistakes the genre's scale for its method. The method is only this: one accountable narrator, a real system, the reasons attached to the choices, and the bill attached to the reasons. Nothing about that requires smallness. The best internal design documents we encounter in review are memoirs in all but name, and the estates that have them are measurably cheaper to assess, because the reviewer inherits not just the what but the considered why.

What the genre teaches, mostly by contrast, is how much ordinary documentation is written by nobody. The wiki page with no author, updated by accretion, believed by no one; the architecture deck whose reasoning was lost in the fourth revision. Prose without a narrator cannot be held to account, and unaccountable prose converges on optimism. The memoir's single voice is not a stylistic preference. It is the mechanism of its honesty.

So, three borrowings for organizations, offered at memoir scale. Let systems have authors: one name on the design document, however many hands built it, because accountability is a writing technology before it is a management one. Let the reasons travel with the artifact, in the repository, beside the code, where the next decade can find them. And let people write publicly about what they run privately, within the obvious bounds; the engineer who can explain their own system to strangers has, in our observation, already done the thinking their employer most needed and least often asks for.

The genre will never trend. Its subjects are too small, its authors too busy operating what they describe. But an industry drowning in generated prose is about to rediscover the value of writing that can be checked against a running thing, and the memoirists have been quietly demonstrating the standard all along. Read them. Then, more usefully: become one, about something you own.