The engineers who consistently produce the most leverage share one trait that doesn’t show up on resumes: they compress. They compress code, yes, but also ideas, APIs, explanations, and system designs. They take something sprawling and find the smaller, truer version of it.
This isn’t minimalism for its own sake. Compression is a precision skill. Done wrong, it produces cryptic one-liners and under-specified interfaces. Done right, it produces systems that are genuinely easier to reason about, maintain, and extend. Here’s where it actually matters.
1. Code That Does Less Is Usually Better Code
The most dangerous metric in software is lines of code written per day. It measures output, not value. The engineer who deletes 500 lines and ships the same behavior has done something harder and more valuable than the one who added 500 lines to solve the same problem.
This isn’t theoretical. Every line of code is a liability: something that can break, something that needs to be understood by the next person, something that interacts with everything else in ways you won’t fully anticipate. The Unix philosophy got this right decades ago. Small tools that do one thing well compose better than large tools that do everything adequately.
The practical implication: when you finish a feature, ask whether any of it can be deleted now that it’s working. The answer is often yes.
2. API Design Is Compression Design
A good API is a compression of what a system does into what callers actually need. A bad API leaks internals, exposes implementation details, and forces callers to understand how the thing works in order to use it.
The difference between a 3-method API and a 15-method API isn’t just convenience. It’s cognitive load, surface area for bugs, and maintenance burden multiplied across every consumer of that API. Stripe’s API is often cited in engineering circles specifically because it compresses the complexity of payment processing into something developers can understand in an afternoon. That compression is the product.
When you’re designing an interface and find yourself adding a method for every edge case a caller might need, stop. That’s usually a sign the abstraction is wrong, not incomplete.
3. The Ability to Summarize a System Accurately Is Rare
Ask an engineer to explain a system they’ve worked on for six months and you’ll often get one of two things: a 40-minute stream of implementation details, or a vague summary so high-level it’s useless. The ability to compress a system’s behavior into a paragraph that’s both accurate and genuinely informative is uncommon and enormously valuable.
This matters for onboarding, incident response, architecture review, and hiring. When something breaks at 2am, the person who can say “this service buffers writes to Redis and flushes them in batches every 30 seconds, so if the consumer is down you’ll see up to 30 seconds of lag before data appears” is more useful than the person who needs to re-read the code first.
Compression here isn’t about simplification. It’s about identifying which details are load-bearing and which are incidental. That’s a judgment call that requires deep understanding, not just familiarity.
4. Verbose Specifications Produce Ambiguous Systems
There’s a counterintuitive truth in requirements work: longer specs are often less precise than shorter ones. When you describe every edge case in prose, you introduce ambiguity through language. When you’re forced to compress, you have to find the underlying rule that generates the edge cases rather than listing them.
A requirements doc that says “users can edit their profile, including name, email, and bio, but not after account deletion, and only if the account is verified, except for the email field which…” will produce a system full of conditional logic that nobody fully understands. The compressed version asks: what are the invariants? What’s always true? Write that down and the edge cases resolve themselves.
This is why good engineers often push back on feature specs by asking for the purpose, not the prescription. The prescription is usually a compressed version of the purpose with information lost in translation.
5. Compression Applies to Data, and Most Engineers Ignore It
Literal compression, the algorithmic kind, is something many engineers treat as a solved problem and never think about again. This is a mistake. Storage is cheap but latency isn’t, and moving large payloads across a network has real costs that compound at scale.
The choice between gzip, zstd, and Brotli for a given workload has measurable performance implications. Zstandard, developed at Facebook and released as open source, achieves compression ratios comparable to zlib at significantly higher speeds. For workloads where you’re compressing lots of similar data (logs, JSON API responses, columnar data), choosing the right algorithm and tuning it for your data’s characteristics is not premature optimization. It’s basic due diligence.
The same principle extends to data modeling. A schema that stores rich structured data is often harder to query and maintain than one that compresses the structure to match how the data is actually accessed. Why shrinking an AI model often makes it more useful covers adjacent territory: the insight that stripping a system down to what’s essential often makes it perform better, not just smaller.
6. Senior Engineers Compress Communication, Not Just Code
The most efficient engineers write short design docs. Not because they’re lazy, but because they’ve already done the compression work in their head and know which details are essential. A three-page design doc that captures the real tradeoffs is more valuable than a ten-page one that buries them.
This extends to code review comments, Slack messages, and status updates. The ability to say “this will cause a race condition under concurrent writes” in eight words instead of three paragraphs is a skill built through deliberate practice. It requires understanding the audience, knowing what they already know, and trusting that precision beats coverage.
The highest-paid engineers write the least code gets at something related: the engineers with the most leverage are usually the ones who’ve internalized what can be left out. Compression isn’t about being terse. It’s about signal-to-noise ratio. Most codebases, most meetings, and most technical documents have the ratio backwards.
