A hundred posts is the easy half

A hundred-post technical series exists and is countable. The part people ask about is how it got written; the part that determined whether it was worth writing is a different question entirely.

Volume is a scheduling problem. Quality at volume is a measurement problem, and they need different machinery.

The case this post is about#

One hundred posts in thirty days, and the four artifacts that decided what the hundredth looked like:

preflight    dead links, length band, missing evidence, frontmatter, tag count
curriculum   what each post covers, approved before any of it was drafted
voice        a document describing the register, read before writing, not after
ledger       what has been published where, so nothing is silently duplicated

None of those is about scheduling, and scheduling is the half everybody writes about. Volume at this rate is not hard any more — what is hard is that post ninety-six is measured against the same thing post one was, by which time nobody remembers what that was.

This post follows those four, because three of them existed before the first draft and the difference between them and a style guide is that three of them fail a build.

The symptom#

The failure mode is not that the posts stop coming. It is that they keep coming and converge — the same four section headings, the same opening move, the same two sentences of throat-clearing before anything is claimed. Each individual post is fine. Read in sequence they are one post with the nouns changed.

The second thing is drift in what counts as finished. Post three gets a worked example because there is time; post sixty gets a sentence saying what the example would show. Nothing announces the change — each post is slightly cheaper than the one before it, and the slope is invisible from inside any single one.

The third is the broken link, which is the smallest problem and the most damaging to trust. A reference that 404s tells a reader the post was not checked, and one of those undoes several good posts. At volume this stops being a thing you can catch by remembering, because the number of links is multiplying at the same rate as everything else.

The arithmetic is unforgiving and nobody does it in advance. A hundred posts with a dozen references each is more than a thousand links, every one of which points at something somebody else controls and may move. Checking them by hand once is an afternoon; checking them on every edit is not a thing a person does, and the half that is never re-checked is where the dead ones accumulate.

The fourth is the one that is hardest to admit: a post that is structurally complete and says nothing. It has the sections, it has the length, it names a real problem, and it never commits to a claim anybody could disagree with. That passes every mechanical check I could think of, and it is the exact output you get when the process is optimising for throughput.

Why the obvious fix failed#

Write a style guide. Necessary and not sufficient — I have one, it is a hundred lines, and a document does not read itself. A style guide catches the problems of somebody who consults it, which is a different population from somebody producing the sixtieth item in a series.

Review each one before publishing. The honest answer at low volume and the thing that fails first. Careful review of a long technical post is most of an hour, and it is the step that gets compressed when there is a backlog — which is precisely when the drift is happening.

Templates. They solve the structure problem by causing the convergence problem. A template makes every post have the right shape and makes every post have the same shape, and sameness at the structural level is what makes a series read as generated.

Just write fewer. Defensible and it does not answer the question. The interesting problem is not whether volume is wise; it is that if you are going to produce volume, the quality question has to be mechanical, because everything that depends on attention degrades exactly where the volume is.

It is also the advice that is easiest to give and hardest to act on, because the reason for the volume is usually not inside the writing. A series exists to cover a subject, or to be found, or because somebody committed to it — and "write fewer" asks you to change that decision rather than to solve the problem it created.

The actual mechanism#

Split the problem: mechanical properties get a gate, and judgement gets a standard to be read against.

preflight    dead links, length band, missing evidence, frontmatter, tag count
curriculum   what each post covers, approved before any of it was drafted
voice        a document describing the register, read before writing, not after
ledger       what has been published where, so nothing is silently duplicated

The first line is the uncontroversial part and it is worth being specific about what belongs there. A link that does not resolve, a post below the length band, a post with no image, a malformed frontmatter block — each of these is a property of the artifact that a script can decide, and every one of them is a thing I would otherwise be checking by hand at the moment I least want to.

The second line is the one that does the most work and gets discussed the least. A curriculum manifest — the full list of what each post covers, agreed before any drafting — removes the per-post question "what should this one be about", which is where both the convergence and the thin posts come from. Deciding the hundred topics as a set, once, is a different activity from deciding the sixty-first topic while tired.

It also makes the gaps visible while they are still cheap to fix. Laid out as a set, a curriculum shows you that four posts cover the same ground from slightly different angles and that an obvious subject is missing entirely — both of which are invisible when topics are chosen one at a time, because each individual choice is defensible.

The sub-case that determines whether any of it holds is what the gate cannot check. A post can pass every mechanical test and be empty, and no amount of additional mechanical tests fixes that, because the property is "does this commit to something". The closest I have come is a check for the register itself — the hedging constructions, the throat-clearing openers, the phrases that appear when something is being described rather than claimed — which catches a surprising amount and is a proxy rather than the thing.

The gap between the proxy and the thing is worth stating rather than glossing. A register check can tell that a sentence hedges; it cannot tell that a paragraph is true, or that an example was actually run, or that the author believes the claim. Those are the properties that make technical writing worth reading and none of them is visible in the text's shape.

The fix#

gate       the mechanical properties, with the build failing rather than warning
decide     the whole set of topics in advance, as one act
measure    against a written register, read before drafting
accept     that the judgement part is not automatable and budget attention for it

The mechanical half is a gate, and the whole point is that it fails rather than warns — a warning on a passing build is read by nobody:

const CHECKS = [
  { id: "tags",      max: 5,  of: (p: Post) => p.meta.medium_tags.length },
  { id: "seo-title", max: 60, of: (p: Post) => p.meta.seo_title.length },
  { id: "seo-desc",  min: 140, max: 156, of: (p: Post) => p.meta.seo_description.length },
] as const;

export function gate(posts: Post[]) {
  const findings = posts.flatMap((p) =>
    CHECKS.flatMap((c) => {
      const n = c.of(p);
      const bad = ("min" in c && n < c.min) || n > c.max;
      return bad ? [`${p.slug}  ${c.id}=${n} (allowed ${"min" in c ? c.min : 0}–${c.max})`] : [];
    })
  );
  // Duplicate angle is the one that is NOT per-post: it only exists across the set.
  const byAngle = new Map<string, string[]>();
  for (const p of posts) {
    const k = normalise(p.meta.description);
    byAngle.set(k, [...(byAngle.get(k) ?? []), p.slug]);
  }
  for (const [, slugs] of byAngle) {
    if (slugs.length > 1) findings.push(`duplicate angle: ${slugs.join(", ")}`);
  }
  if (findings.length) throw new Error(findings.join("\n"));
}

On a batch written quickly:

$ deno task gate
seo-zero-to-organic   seo-desc=187 (allowed 140–156)
og-image-per-post     tags=7 (allowed 0–5)
duplicate angle: feeds-are-a-lower-bound, reading-the-405
FAILED — 3 findings

The duplicate-angle line is the one that could not be a per-post check. It only exists when the set is examined as a set, which is why deciding the whole list in advance is a separate step from writing any of it.

The fourth line is the one I would press on, because the first three are easy to adopt and make it tempting to believe the problem is solved. It is not: the gates raise the floor and they do not raise the ceiling, and a series where every post clears the floor and nothing exceeds it is a worse outcome than an uneven one with some real pieces in it.

The practical compromise I settled on is to spend the saved attention unevenly. The mechanical checks mean no post is ever broken, which means the review time that used to go on checking links goes somewhere else — and putting all of it on a few posts rather than a little on each produces a series with peaks, which is what people actually remember.

How we proved it#

The gates are countable and the series is public, which makes most of this checkable rather than asserted. The preflight refuses a post with a dead link, a post below the target band, a post with no evidence image, and a handful of register tells — those are names of checks in a script, not descriptions of an intention.

The convergence problem is visible in the artifacts. Reading the series in order, the posts written before the register document was written are distinguishable from the ones after it, and the tell is the opening: the early ones announce what they are about and the later ones start with the thing that went wrong. That is a real effect of a written standard and it is not subtle.

What I cannot tell you is how long it took. I have the publication schedule and I do not have an honest record of drafting time, so any number I gave for posts-per-day would be reconstructed rather than measured. The backlog entry for this post claimed a figure and I have dropped it, because the interesting claim is about the gates and the timeline was never the evidenced part.

What I have not solved: the empty post. The register check catches hedging and the length band catches brevity, and a post that is structurally complete and claims nothing passes both. I do not have a mechanical test for "commits to something a reasonable person could dispute", and I suspect the honest version of that test is a reader.

And a cost that is real: gates make a bad day worse. A post that is finished at eleven at night and fails on a dead link is not going out that night, and the temptation to add a bypass flag is strongest at exactly the moment the gate is doing its job. I have not added one, and I have wanted to.

The thing I got wrong was building the mechanical checks first and the register document second. In that order the gates were available during the stretch where the drift happened, and they cheerfully passed every post, because none of them was broken — they were just increasingly similar. The register would have been cheaper to write and would have caught the thing the scripts could not see.

What this generalizes to#

A quality bar that depends on attention degrades exactly where attention is scarcest, which is under volume — and that is the condition everybody adopts the bar to survive.

The pattern is not specific to writing. Code review thoroughness at the end of a release. Test quality during a crunch. Incident write-ups after the fourth incident in a week. In each case the practice is sound, everybody endorses it, and its application is inversely proportional to how much it is needed, because it is funded out of the same budget as the work.

So the useful move when scaling any practice is to separate what can be decided mechanically from what cannot, gate the first half ruthlessly, and then spend the recovered attention on the second half rather than on the volume. The gates are not the quality; they are what stops the floor falling while you are looking somewhere else.