Domain-Specific Encoding
Knowing When Not to Compress
Anti-fragile information systems and the meta-skill of adaptive density
Across the last three posts, I've been building an argument:
- Shop floor pidgins compress decades of knowledge into phrases like "wing plates" and "head frames"
- Codebases develop the same dynamics — dense jargon that helps insiders and walls out newcomers
- CAD systems encode compression choices in their very structure — configurations vs. separate files, abstraction vs. explicitness
The throughline: compression is everywhere, and it's never purely technical. It depends on shared context, team cognition, and the boundary between formal systems and emergent practice.
But I've been describing compression as something that happens to you. Pidgins evolve. Codebases accumulate jargon. CAD libraries drift toward complexity or explode into redundancy.
The question I want to end with: can we do this deliberately? And if we can — should we?
The Compression Lifecycle
Watch any team long enough and you'll see a pattern:
Phase 1: Explicit. Everything is spelled out. New team, new codebase, new product line. Nobody shares context yet, so communication is verbose. Separate files for everything. Long variable names. Procedures written in full sentences.
Phase 2: Compression. Patterns emerge. People get tired of repeating themselves. Shorthand develops. Someone creates a configuration system. Abstractions appear. "Just use the standard approach" starts to mean something. Efficiency improves.
Phase 3: Over-compression. The shorthand accretes. Layers of abstraction pile up. New people can't parse the pidgin. The configuration system has configurations. Someone knows the incantations; everyone else works around them. Efficiency degrades.
Phase 4: Crisis or correction. Either the system breaks (an expert leaves, a critical miscommunication, a project fails) or someone deliberately intervenes. Complexity gets pruned. Documentation gets written. The cycle begins again.
This isn't failure. It's how living systems work. Compression naturally tends toward over-compression until reality pushes back.
Anti-Fragile Compression
Nassim Taleb's concept of anti-fragility fits here: systems that don't just survive stress but improve because of it.
A fragile compression scheme breaks under pressure. One expert leaves, and the whole system becomes opaque. One miscommunication cascades into a production failure.
A robust compression scheme survives pressure. Redundancy, documentation, explicit fallbacks. It doesn't get better, but it doesn't collapse.
An anti-fragile compression scheme uses pressure to evolve. Each miscommunication reveals a boundary that was assumed but not shared. Each failure exposes a compression that went too far. The system learns.
The teams I've seen do this well share a trait: they treat communication failures as information, not just problems. When someone doesn't understand, that's data about the codebook. When a configuration trips someone up, that's a signal about compression level.
They're not trying to prevent all friction. They're using friction to calibrate.
The Meta-Skill
Here's what I've come to believe: the highest-leverage skill isn't compression or expansion. It's the meta-skill of knowing which to use when.
Compress when: - The pattern genuinely repeats - The audience shares the codebook - The boundary is stable and shared - Speed matters more than onboarding
Expand when: - The audience is mixed or unknown - The concept is contested or evolving - The stakes of miscommunication are high - You're crossing a team or system boundary
The best communicators I know — engineers, fabricators, managers — do this instinctively. They code-switch. Dense jargon with insiders, explicit language with outsiders. Complex configurations for stable patterns, separate files for contested boundaries.
They've internalized not just the pidgin but the meta-knowledge of when to use it.
Can You Design a Pidgin?
Christopher Alexander tried. His Pattern Language was an attempt to create a deliberate compression scheme for architecture — named patterns that encode solutions to recurring problems. "Light on Two Sides of Every Room." "Intimacy Gradient." "Street Café."
Each pattern is a piece of jargon: a few words that unpack into pages of reasoning. Architects who share the vocabulary can communicate densely. The pattern names become shorthand.
But here's what's interesting: the pattern language only works if you learn it. Alexander wrote a 1,171-page book to define the codebook. The compression requires upfront investment.
This is the fundamental tradeoff in deliberate compression design:
- Evolved pidgins have low upfront cost but high maintenance cost. They drift, fork, and lose speakers.
- Designed pidgins have high upfront cost but potentially lower maintenance cost. They can be documented, taught, versioned.
Most systems end up as hybrids. A designed core (official terminology, architectural patterns, standard configurations) surrounded by evolved accretions (local jargon, workarounds, tribal knowledge).
The question isn't designed vs. evolved. It's how much of each, and where.
Toward Deliberate Practice
Some things I've been trying:
Name the patterns explicitly. When I notice a concept recurring, I give it a name and write down what it means. Not in code — in documentation, in conversation, in notes. I'm seeding the pidgin deliberately rather than waiting for it to evolve.
Version the codebook, not just the code. When terminology changes, I track it. When a concept splits into two, I document the fork. This feels bureaucratic, but it's saved me more than once when revisiting old decisions.
Design for onboarding. When I build a system, I ask: if I left tomorrow, how long would it take someone to parse this? That's a proxy for compression level. If the answer is "months," I'm over-compressed.
Build in decompression rituals. Regular moments where dense communication gets expanded. Code reviews, documentation days, new-hire pairing. These aren't overhead — they're the mechanism by which the codebook stays shared.
Accept that some compression will be lost. This is the hard one. Every time an expert leaves, some of the pidgin dies. You can't preserve it all. But you can preserve the core — the patterns that matter most — by making them explicit before they need to be.
The Elegant Algorithm
I keep coming back to a line from a conversation I had about this:
Sometimes the most elegant compression algorithm is simply knowing when not to compress.
The goal isn't maximum density. It's appropriate density. Compression that matches the context, the audience, the stakes.
That's not a technical problem. It's a judgment problem. And like all judgment, it develops through practice, failure, and attention.
The pidgins will keep evolving. The question is whether we evolve with them — and whether we can, occasionally, steer.
This is the final post in a series on domain-specific encoding.
The series: Wing Plates and Head Frames | Your Codebase Is a Pidgin | The CAD File Is a Pidgin Too | Knowing When Not to Compress