When I built the content negotiation for this site (the part that hands each visitor the format and encoding their browser actually wants), the most useful reference I had was a post I’d written years earlier, on this same blog, about doing the same thing in nginx. That is what the blog is for.

Most of what I know about building software, I learned on the job — at companies and on contracts I’ve long since left. Almost none of that work came with me. The part that did is the work I did in public.

The knowledge sink

Most of what I learn on a job stays on the job. Three separate things make sure of it.

• Legally, the code belongs to the employer. So do the patterns I discovered while writing it.
• Morally, the notes, the wiki pages, the design docs were paid for and belong in that context. Walking out with them isn’t right.
• Physically, it is simply gone. The laptop goes back, and the corporate wiki, the chat history, and the ticket archive all sit behind a login I no longer have.

What survives the move is harder to name: intuition, skill, judgement, the experience of having done the thing. Real, but not in any form I can hand to the next version of myself. As an independent contractor I feel this on a short cycle: each engagement ends with my access cut off, and the only thing I carry into the next one is what I made public.

What public work preserves

Public work is the way out, and it works in three forms. Each one keeps a different layer of the same knowledge.

• Open source code keeps the artifact: the API, the edge cases, the commit history. Future-me reads the diff and recovers what I did.
• Blog posts keep the reasoning: the why and the how, the approaches I rejected, the traps I hit.
• Talks keep the teaching version: a talk has room for a few slides, so it keeps the core ideas and drops the details.

Code without the writing is opaque even to the person who wrote it, a few years on. Writing without the code is just claims. Together they let me return to old work years later and still trust it.

Not all of my work is public. Most of my talks went unpublished, and so did a long article on REST API design, and some of my private projects live only as records, wikis, and code. They are mine, so they stay with me, but only the published part can reach other people.

There is a second effect, which I will only point at here. Building something for the public, for callers I will never meet, in situations I cannot predict, forces a kind of generalization the in-house version did not need, and the general version usually ends up better than the specific one it grew from. But that is a craft argument with its own home.

Why bother?

Preservation is what public work gives me afterward. The work itself gives me things paid work rarely makes room for:

• Learning. Writing a thing down, in prose or in code, is how I internalize it.
• Exploration. I can dig into the parts of a subject that work usually leaves no time for.
• Interests. Some subjects interest me, and none of my paid work involves them.
• Craft. Sometimes I want to perfect something without cutting corners: spend the time to make it right instead of stopping at “it works somehow, move on.”
• Research. I can ask “what else is available?” and take the time to answer it: search widely, survey the field, dig into academic papers. Working for wages rarely assumes any of that. “Why do you need it? You are an expert. That’s why we pay you.”

It pays off, for me first

None of this is theoretical. I dip back into my own public work constantly (old repositories, gists, slides, posts) to lift an idea or recover a detail I worked out once and would rather not work out twice. A partial list of times my own published work was the thing that unblocked me:

• dynamodb-toolkit and cognito-toolkit hold years of AWS fine points I would otherwise re-learn on every project. I encoded them once; now I look them up.
• stream-json and its relatives have gone into my own client work more times than I can count.
• deep6 and yopl grew straight out of a Prolog-style interpreter I wrote years before.
• And the post that opened this one: my old nginx content-negotiation write-up paid off more than once — first to stand up a company-wide CDN, and again to wire up the format-and-encoding negotiation this site runs on.

The contractor’s life is what makes this pay off. Each engagement’s code stays with the client, the same way a job’s code stays with the employer. My public toolkit is the one thing that comes with me from one engagement to the next, so I reuse it on every one.

The audience question

Niche public work is not a media business, and grading it like one is a mistake. The questions I actually care about are smaller:

• Did I record the thing I would otherwise forget — in code, in prose, or in a talk?
• Can a like-minded reader, or a future user, find it when they need it?
• Does future-me come back to it?

The 2014 Unification series answers the last one: I reread it more often than anyone else does — and I lean on my own packages the same way, far more than any stranger ever will. That is by design: a few readers who keep returning add up over the years, and a spike of visitors lasts a day.

I don’t want some things to be forgotten and vanish in time.

Compound interest

A small body of public work, indexed by the way future-me actually searches, gains value over time. New work leans on the old: a post cites the post before it, a package absorbs the lessons of the last one. I search the archive like a reference, and every entry in it was written with the full context, because I wrote it.

Twelve years of silence on this blog erased none of it. The 2014 series still finds readers. The packages from back then survived because they were public — and the reasoning behind them nearly didn’t, until I finally wrote it down this May, in the story behind stream-json.

Summary

Three things:

• I publish for me, first.
• Readers and users are welcome, and the few who stay are exactly the right ones.
• The blog, the packages, and the talks come from the same impulse.

Its companion piece, Code is cheap, makes the same case from the other direction: it argues that the ideas behind code are worth more than the code itself.