Publishing, and the inbound it creates

The asymmetry

Writing to strangers is linear: one message, one chance. Publishing is not. A page you wrote in March is read in September by somebody you have never heard of who is hiring, and you did no work in September.

That is the entire mechanism, and it is worth being precise about it rather than mystical. Two things bring the reader: a search engine or a model answering a question you happened to have written the answer to, and a person forwarding your link to somebody else. Both reward the same thing: writing that is specific enough to be the best available answer to a narrow question.

What to write, in order of return

1. The thing that just took you two days. You spent nine hours on a Docker networking error, an obscure dbt incremental bug, a Hindi tokenisation problem. Write it up the following morning while you still remember the wrong turns. This is the highest-value writing on the internet and almost nobody does it, because once you have solved it, it feels obvious. It is not obvious. It was not obvious to you on Monday.

2. A comparison with numbers. “I ran the same 200-row extraction task through four approaches; here is the accuracy, the cost per thousand documents and the latency.” Anybody can have an opinion. Almost nobody has run the test.

3. A decision record. The case-study format from the evidence module, published. What you were trying to do, what you rejected, what the number was.

4. Notes on something you are learning. Weakest, but not worthless, provided you write as a learner rather than as an authority. “Three things that confused me about embeddings, and what finally made them click” is honest and useful. “The Ultimate Guide to Embeddings”, written by somebody who learned them last week, is neither.

The shape that gets read

• Title it as the question somebody would type. “Why my dbt incremental model silently dropped rows after a schema change” is a title. “Data Engineering Lessons” is not.
• Answer in the first paragraph. Readers who need the answer will take it and go. That is a success, not a theft; they will remember where they got it.
• Show the error text, the command and the version numbers. These are what search finds and what makes the page credible.
• Say what you are unsure about. A sentence admitting a limit does more for a reader’s trust than three paragraphs of confidence.
• Length is whatever the thing needs. Six hundred honest words beat three thousand padded ones, and the padding is visible.

Where, and at what cost

Your own site first, because links you own accrue to you and a platform can disappear or paywall you. Free hosting on GitHub Pages, Cloudflare Pages or Netlify; free static generators: Hugo, Eleventy, Quarto, or plain HTML. Then cross-post where the readers are, with a link back: Dev.to, Medium, Hashnode, LinkedIn, Reddit’s topic communities, Hacker News occasionally. On LinkedIn, paste the text into the post itself rather than posting a bare link, because the feed suppresses outbound links and a post nobody sees helps nobody.

The limitation, stated plainly

Most posts are read by about forty people. Many are read by four. The compounding is real but slow and unreliable: a fair expectation is six to twelve months of monthly writing before anything traceable happens, and a substantial number of people write for a year and get nothing but the writing itself.

That should change what you optimise for. Write things that are useful to you in six months (your own notes, findable) and treat the inbound as the second-order effect it is. People who write for the audience quit at post four. People who write to remember things keep going, and the audience arrives later.

One rule with teeth

Never publish your employer’s data, code, incident details or customer names, and be careful with anything under an agreement. Write about the method, the tool, the general problem. This is not a formality: it is the one way that public writing can cost you a career rather than build one.