What a Blog Is, and Why Practitioners Should Keep One

A blog is a dated series of posts, newest first, written by a person who has something to say and wants it to stay findable. That is the whole definition. Everything else (themes, newsletters, comment sections) is decoration.

The form is older than most people assume. Jorn Barger coined the word "weblog" in December 1997, and Peter Merholz shortened it to "blog" in 1999 by splitting the word into "we blog" in his sidebar, according to the Wikipedia history of the form. Nearly three decades later the shape has barely changed, because it solves a problem that has not gone away: a working person needs somewhere to put an idea that is too long for a post and too small for a paper.

What a blog is not

A social post is built for the feed. It is short, it competes with everything else on the screen, and it is mostly gone within a day. Good for a pointer. Bad for an argument. You cannot fit a stack trace, a wiring diagram and the three things you tried before the fix into a format designed to be scrolled past.

A paper is built for review. It has a method section, related work, and a bar for novelty that most real engineering lessons will never clear. "We changed the PLC scan time from 10 ms to 20 ms and the jitter on line 4 went away" is extremely useful to the next controls engineer. It is not publishable.

Documentation is built for a product. It describes how a thing is supposed to work, in the voice of the organization. It rarely says why a decision was made, what was rejected, or what broke in production at 3 a.m.

A blog sits in the gap. It is long enough to show your reasoning, informal enough to include the dead ends, and permanent enough that someone can search for it in 2031.

Why individual practitioners should keep one

Writing is how you find out what you think

Paul Graham makes this point in Putting Ideas into Words (2022): "Writing about something, even something you know well, usually shows you that you didn't know it as well as you thought." Anyone who has tried to explain a race condition, a threat model or a gripper calibration to a colleague has felt this. The gap between "I understand it" and "I can write it down in order" is where the real learning happens.

Your hard problems are someone else's search query

Julia Evans describes her approach in Blog about what you've struggled with (2021): struggle with something, figure out what actually helped, then write that down, because other people are almost certainly stuck on the same thing. Note that she stresses the lesson, not the struggle.

This matters more as AI systems answer the easy questions. A model can summarize a vendor manual. It cannot tell you that a particular firmware revision on a particular servo drive misreports its encoder after a brownout, unless someone who saw it wrote it down. First-hand field notes are becoming the scarce input, not the abundant one.

It makes your judgment visible

Résumés list tools. Blogs show decisions. A security analyst who writes up how they triaged a noisy alert shows more than any certification line. A designer who explains why they rejected a layout the AI suggested shows the taste that the tool lacks. A roboticist who documents a failed grasp strategy shows they can reason about physical systems, which is exactly what employers struggle to assess in an interview.

It compounds

Simon Willison recommends, in What to blog about (2022), adding "write about it" to your definition of "done" for anything you build. He also argues for short "TIL" (today I learned) posts, which lower the bar to almost nothing. One post is a note. Fifty posts over three years become a searchable record of how you think, one that you will consult more than anyone else.

What a good practitioner blog looks like

There is no single template, but the useful ones share a few traits:

• One idea per post. A post about "our migration" is vague. A post about "why we kept the old message broker for alarms" is useful.
• Evidence on the page. Code, logs, photos of the bench setup, a before/after chart. Readers trust what they can check.
• Honest scope. Say what you tested and what you did not. "This worked on two arms in one lab" is more credible than a universal claim.
• Dates and versions. Software and hardware change. A post that names the version it applies to stays useful longer, because readers can tell when it has stopped applying.
• Links to sources. If you lean on a standard, a paper or someone else's post, link it. It lets the reader go deeper and keeps you honest.

Starting without overthinking it

You do not need a niche, a schedule or an audience. You need one thing you learned recently that was harder than it should have been. Write down the problem, what you tried, what worked, and what you would do differently. Keep it under a thousand words. Publish it.

The second post is easier. By the tenth you will notice that you approach problems differently, because part of you is already drafting the write-up. That habit, more than any single post, is the point.

Sources

1. Blog (Wikipedia) — history of the terms "weblog" (Barger, 1997) and "blog" (Merholz, 1999).
2. Putting Ideas into Words, Paul Graham — February 2022 essay arguing that writing exposes gaps in what you think you know.
3. Blog about what you've struggled with, Julia Evans — May 2021 post on turning hard-won lessons into posts.
4. What to blog about, Simon Willison — November 2022 post recommending TILs and adding "write about it" to your definition of done.