Ask a software engineer what they do for a living, and watch what happens. They’ll pause. They’ll attempt an analogy involving plumbing or architecture. They’ll abandon it halfway through. Their parent will nod politely and change the subject. This scene plays out at dinner tables across the country every holiday season, and most people chalk it up to technical complexity or social awkwardness. But the real explanation is economic, and it has nothing to do with coding ability.
The software industry has a structural incentive to make its work unintelligible. Not maliciously, not through conspiracy, but through the natural accumulation of abstraction layers that each generate their own revenue streams. When you understand that dynamic, the communication gap stops looking like a personal failure and starts looking like a business model. This same principle explains why tech companies design software to be hard on purpose, keeping users dependent on specialists who can navigate complexity on their behalf.
The Abstraction Economy
Every layer of abstraction in software is also a layer of economic value extraction. A database engineer doesn’t just store data. They manage a system that sits on top of an operating system, which sits on top of hardware drivers, which sit on top of physical infrastructure, each layer maintained by different specialists who speak different professional languages. When your parent asks what you do, you’d need to explain all of it to make any single layer make sense. So you don’t.
This isn’t accidental. The economic logic of software has always rewarded depth over breadth, specialization over generalism. A senior engineer who understands the memory allocation behavior of a specific runtime environment is worth more to an employer than someone who can explain the whole stack in plain English. The market prices obscurity as expertise. It prices legibility as a commodity.
Enterprise software pricing makes this dynamic explicit. The reason enterprise software costs ten times more than consumer versions has nothing to do with features. It has to do with the cost of navigating complexity, the human layer that translates what the software does into what the buyer actually needs. That translation layer is billable. Clarity is the product. Obscurity is the moat.
Why Engineers Stop Trying to Explain
There’s a second force at work, one that operates inside the engineer’s own head. Most software work is invisible by design. An engineer who spends three weeks fixing a race condition in a distributed system has, from the outside, produced nothing. The product looks identical before and after. Performance might improve marginally. Users will never notice. The parent asking “what did you make this week” has no frame for an answer that doesn’t involve a physical object or a visible outcome.
This invisibility compounds over time. Engineers who work on infrastructure, security, tooling, or performance spend entire careers improving things that users never see. The job is, structurally, about preventing bad things from happening rather than causing good things to appear. Software bugs multiply when teams grow because of a communication problem, not a coding problem, and the engineers managing that invisible complexity have the hardest job of all: preventing outcomes that no one will ever thank them for avoiding.
Compare that to a nurse, a teacher, or a plumber. Their work produces visible, legible changes in the world. Someone was sick, now they’re better. A pipe was broken, now it isn’t. Software engineering, especially at the infrastructure level, produces the absence of failure. That’s nearly impossible to explain over turkey.
The Language Was Built for Colleagues, Not Parents
Professional language in any field serves a gatekeeping function, but software engineering has taken this further than most. The terminology isn’t just precise, it’s layered with history, inside jokes, and cultural references that only make sense if you’ve spent years inside the industry. When an engineer says they’re “refactoring a monolith into microservices” or “implementing idempotency in a message queue,” they’re not being obscure on purpose. They’re using the most efficient language available for communicating with people who share their context.
The problem is that this language was built for a specific audience, and that audience was never the general public. Software engineers write code comments for themselves, not for you, and that changes everything. The same logic applies to how engineers talk about their work. The explanations are optimized for colleagues, not parents. Translating them requires a kind of cognitive context-switching that most engineers have never been trained to do, because the industry has never rewarded it.
Why the Industry Has No Incentive to Fix This
Here’s where the economics get sharp. The illegibility of software work isn’t just a communication failure, it’s a feature that benefits multiple parties simultaneously. Companies that are hard to understand are hard to regulate. Processes that can’t be explained can’t be easily outsourced, at least not without expensive consultants who charge for their translation services. Engineers whose work can’t be described by non-engineers are harder to replace, because replacement requires understanding what the role actually does.
The venture capital model accelerates this. Startups are frequently valued on metrics that require technical fluency to interpret: monthly active users, API call volume, churn rate, DAU/MAU ratios. The language of startup economics is as opaque as the language of software engineering, by design. When you combine technical obscurity with financial obscurity, you get an industry that is almost perfectly insulated from outside scrutiny.
This is partly why the best tech leaders succeed by knowing less than you think. The executives who thrive are often the ones who can translate between the technical world and the business world, a skill that is rarer and more valuable than most technical skills, precisely because the industry has done so little to cultivate it.
What Would Change If Engineers Could Explain Themselves
The consequences of this communication gap are larger than awkward holiday dinners. Public understanding of software shapes public policy, and public policy shapes the conditions under which software companies operate. When legislators can’t understand what an algorithm does, they can’t regulate it effectively. When voters can’t evaluate technical claims, they can’t hold tech companies accountable. The illegibility of software engineering is a democratic problem dressed in a social one.
Engineers who learn to explain their work clearly tend to build better products. The exercise of translating technical concepts into plain language forces a kind of structural thinking that purely technical work doesn’t require. You can’t explain something you don’t fully understand, and the attempt to explain often reveals gaps that the original builder missed.
The next time an engineer stumbles through an explanation at the dinner table, resist the urge to treat it as a personality quirk. It’s a symptom of an industry that has optimized for depth, speed, and internal efficiency at the expense of legibility. The gap between what engineers build and what they can describe isn’t a communication failure. It’s the product of decades of economic incentives pointing in exactly the wrong direction.
