Hoard the Pattern

What happens to the insight you find under pressure at 11pm, when the bug is live and you finally understand why the query was wrong?

Most of the time, it disappears.

You fix the bug. You move on. The next engineer — or the next version of you — hits the same wall six months later. They find the same insight. Under the same pressure. At the same hour. Nothing compounded. The hoard never formed.

Simon Willison calls this a solvable problem. His answer is ruthless capture. A TIL site with 575+ entries. Notes, tools, repos — all of them archives of working solutions. His rule: the barrier for writing something down is "I just figured this out." That's the whole criterion. Not significance. Not elegance. Just: this worked, and I don't want to lose it.

Two Hoards

Willison hoards in prose. Notes, blog posts, short write-ups. The hoard is searchable, citable, shareable.

But there's a second kind of hoard that goes further. Instead of recording what you learned, you encode it into something executable. Not "here's how to handle pagination" — but a code template that generates the correct pagination implementation every time someone runs it.

The difference matters. Prose requires the next engineer to read it, understand it, and apply it correctly under their own constraints. Executable templates require nothing. They run. They produce conformant output. The pattern propagates without translation loss.

This is what a code generator does. Every hard-won insight — how to structure the WHERE clause, how to handle errors, how to name methods so the type system helps you — lives in the template. The engineer who runs the generator tomorrow inherits all of it. They don't need to know it was ever a problem.

The Inversion

The clearest proof of this thesis is what happens when the hoard is bypassed.

A repository that should have been generated by the template instead gets written by hand. One entity becomes two, then five, then seven. Each added under time pressure by someone who doesn't know what they're supposed to inherit. Pagination goes missing. Error arguments get reversed. Prepared statements never appear. Method naming drifts. Eight hundred lines become sixteen hundred.

The patterns are gone. Not because anyone decided to remove them — because they were never in the file in the first place. They existed only in the template that wasn't used.

This is not a failure of engineering discipline. It's a failure of inheritance. The hoard was available. The mechanism to apply it existed. The practitioner just didn't use the generator, so the insight never transferred.

The Legacy Rule

There's a principle that runs through good engineering cultures, usually stated something like: when you finish a job, improve the template for the next person.

Not document. Not communicate. Improve the template.

The difference is that documentation requires a reader who goes looking for it. Templates require nothing from the inheritor. You run the command. You get the pattern. You never had to learn it.

Willison's TIL practice is the documentation version of this. It's valuable — especially for knowledge that can't be templated, for judgment calls and context. But for structural patterns in code, the template version is stronger. It's a hoard that executes.

The compounding effect is significant. Every new implementation that uses the template is correct by default. Every edge case the template handles is handled everywhere. When a better approach is discovered, the template is updated — and every future implementation inherits the improvement automatically.

The hoard grows in precision, not just in size.

What Gets Lost

The god-file is the artifact of a team that stopped hoarding.

Thousands of lines. Multiple entities. No pagination. Reversed arguments. Inline filter logic instead of generated methods. Each of these is a pattern that was discovered, worked with, and then left out — because the template wasn't consulted and the insight didn't transfer.

The cost isn't just technical debt. It's lost compounding. Every engineer who works in a god-file is working from scratch, rediscovering constraints that should have been inherited. Every bug that lands in it is a bug the template would have prevented. Every hour spent understanding it is an hour not spent on the problem that actually needed solving.

Willison's frame makes this legible: the god-file is a place where the hoard was bypassed, repeatedly, over time.

Context

• Standard Templates — where the executable hoard lives
• Quality Assurance — Deming's 14 points on compounding standards
• The VVFL — the loop that makes the hoard virtuous, not just corrective
• Naming Standards — the compressed form of accumulated pattern knowledge

Questions

What's the half-life of insight that lives only in your head?

• When was the last time you hit a problem you had already solved, in a different codebase or a different role?
• What would it take for your team's best patterns to become the default, not the exception?
• Is there a difference between a codebase that documents patterns and one that enforces them?
• What is the most valuable thing you know that is not yet in a template?