What Is A Pattern
Define It So It Can Be Measured
A pivot mid-build, when a reusable thing is recognized:
Hey, what we are doing here- building the way our drag and drop system works- that needs to be a fully set pattern here- we have the same thing with the tabs at the top of the page. Rather than run the risk of re-designing something like more than once, we obviously want to use a pattern for that. I know we have our Pattern Registry file- is that the best place to put it? Does that document need to be decomposed at all so it doesn't get too big- would it make sense to have a different document for different kinds of patterns, so we could have a pattern doc for how we build things in the App separately for patterns for how we do things internally with Loop MMT- that seems very obvious split in the model- where else does it make sense to split that up.
And THEN, how does the system 'recognize' that 'there is a pattern here that should be captured'? What, exactly, IS a pattern? We have to formally define it in a way that can be quickly measured, if we are to have any hopes of capturing patterns in the way we should be.
And THEN, how do we build it into our system to ALWAYS look in the pattern registry when building. It's not unlike the Gold Wash system- patterns in the pattern registry are, pretty much, gold, mechanisms, and veins, just ones that we came around to in a different way. How can we merge all of that good stuff into this here?
Let's pivot into this- mark where we are now so we can Shea Walk back to it, but it feels like this is the right place to get our Patterns setup better.
Please TX, CX, SX, and KX here, and obviously dive deep into all the patterns we have. Think WEIRD here too, because it feels like there are solutions there. Get Crux involved here and run a proper, to-spec Kaleidoscope before working so you are in the right head space. Get some tunes going too with Liner Notes.
— Shea Gunther · operator drop, 10.2006
A stated aim that shipped — the Pattern System: it reconciles the pattern registries onto one shared spine and adds the two things none had — a recognition test (is there a pattern here?) and a build-time reach so the registry is consulted before re-solving a shape.
The recognition arrives mid-build: the way the drag-and-drop works — like the tabs at the top of the page — is a pattern, and re-designing it twice is exactly what a registry exists to prevent. The operator asks the housekeeping questions (is the Pattern Registry the right home, should it decompose — app-build patterns vs. internal-method patterns) and then the two hard ones.
First: how does the system recognize that a pattern should be captured — what, exactly, IS a pattern, defined so it can be quickly measured? Second: how do you build in an always-look-at-the-registry step before building? He notes the deep tie — patterns are basically gold, mechanisms, and veins reached by another road — and asks to merge that machinery in. It shipped as the Pattern System: one spine, a recognition test, a build-time reach.
The wider frameThe prompt that formalized what a pattern is. Building the drag-and-drop — like the tabs before it — the operator recognizes a reusable thing and asks the deeper questions: is the Pattern Registry the right home, and should it split (app-build patterns vs. internal-method patterns)? How does the system recognize that a pattern is present — what, exactly, is a pattern, defined so it can be quickly measured? And how do you build in an always-check so the registry is consulted before building? He notes patterns are basically gold, mechanisms, and veins reached by another road. It shipped as the Pattern System — a shared spine across the registries plus a recognition test and a build-time reach.
“What, exactly, IS a pattern? We have to formally define it in a way that can be quickly measured” — The load-bearing demand: a definition you can mechanize. Without a measurable definition there's no reliable way to recognize a pattern when one appears.
“how do we build it into our system to ALWAYS look in the pattern registry when building” — The reflex: recognition is worthless without a consult-before-building step — the always-check that became the pattern-reach.
“patterns in the pattern registry are, pretty much, gold, mechanisms, and veins, just ones that we came around to in a different way” — The unification the operator spots himself: the pattern machinery and the gold machinery are the same shape, and should share a spine.
The prompt is written in the working vocabulary of the methodology. Here is what the shorthand means:
- Pattern Registry
- The catalog of reusable engineering patterns the system checks before building, so a solved shape is reused rather than re-solved.
- Gold Wash
- A build-forward process: rather than chipping away to find a clean line, build up around the weak spots (the 'choss') until only the solid structure remains.
- TX
- The tool-reach reflex — sweep the available tools before a build move so you reach the one you'd otherwise forget.
- CX
- The context-exchange reflex — gather what a task needs across the trust ladder (byte-truth first) before a load-bearing move.
- SX
- The spec-checking reflex — fetch a thing's own operative spec and run from it, rather than from memory.
- KX
- A provisioning reflex: pull in the specific Knowledge Packs a task needs before starting, so the work rests on the right domain grounding.
- Kaleidoscope
- A vantage-assembly move that hands the board several deliberately different standpoints to reason from — a way into creative headspace before hard design work.
- Crux
- The Dev Crew's first-pass line-finder — the named hand who reads a problem's line and finds its crux move, as distinct from the advisory board.
- Liner Notes
- The methodology's enriched-music layer for the sensorium's audio channel — a named soundtrack that sets the working mood.