That's not an abstraction, that's just a layer of indirection
Most "abstractions" in software are just indirection that adds complexity—true abstractions like TCP let you forget the complexity exists, while bad ones force you to constantly peek under the hood.
Read Original Summary used for search
TLDR
• TCP is the gold standard: you never debug at the packet level because it actually hides the complexity of unreliable networking
• Test your abstractions: How often do you need to peek under the hood? Daily = bad, yearly = good
• Abstraction costs are asymmetric—authors get immediate benefits (cleaner code), maintainers pay the price (debugging, performance work)
• "All abstractions leak" but good ones minimize leakage; bad ones turn every bug into an excavation through layers
• Abstractions are enemies of both performance (distance from the metal) and simplicity (each layer adds its own rules and failure modes)
In Detail
The author draws a sharp distinction between true abstractions and mere indirection. A great abstraction like TCP hides complexity so well that you operate as if it doesn't exist—most developers never debug TCP at the packet level. It handles error correction, retransmission, and sequencing invisibly. Bad "abstractions" are just thin wrappers that add cognitive overhead without hiding anything, forcing you to trace through layers to understand what's actually happening.
The key test: how often do you need to break the illusion and look underneath? Once a year suggests a good abstraction; once a day suggests indirection masquerading as abstraction. The author introduces the concept of asymmetric costs—the person writing an abstraction enjoys immediate benefits (cleaner, more elegant code), while future maintainers and performance engineers pay the real price in debugging complexity and optimization difficulty. While "all abstractions leak," good ones minimize these situations; bad ones turn every small issue into an archaeological dig through layers.
The practical takeaway is a framework for evaluation: before adding an abstraction, ask whether it truly hides complexity or just adds another layer to navigate. Abstractions have real costs in both performance (distance from the underlying system) and cognitive load (more rules, interfaces, and potential failure points). Use them when they genuinely simplify the system, not just when they make your immediate code look prettier.