Why software work turns level-headed people into b-tier Bond villains

Most software is mundane underneath the branding — forms, endpoints, permissions, a database, maybe a queue. Yet the act of building it reliably pushes sane adults into a kind of institutional neurosis. The author’s argument is that software fuses five ordinarily manageable forces — speed, money, complexity, abstraction, and near-infinite freedom to change your mind — and the combination strips away people’s sense of proportion. The core problem is missing friction: unlike moving a kitchen mid-construction, where torn-out plumbing makes the cost undeniable, changing software hides its cost inside people’s heads and inside systems that are already hard to reason about. Because a change sometimes really is cheap, teams learn to treat every ‘quick idea’ as free, and ‘could we’ slides into ‘should we’ and then ‘why isn’t it done yet?’

That frictionlessness makes everything feel urgent and every technical call feel strategic or even ideological, since dozens of plausible solutions exist and a rival is always supposedly shipping faster. Software has no natural definition of ‘done’ — a carpenter puts down the hammer when the cabinet exists, but a button, a query, an abstraction, or a market can always be ‘improved.’ Organizations end up surrounded by levers, and people surrounded by levers start pulling them, whether from genuine need or from fear, board pressure, or flat metrics. The industry even launders this behavior with flattering vocabulary: thrashing becomes ‘responding to the market,’ rebuilding a working feature becomes ‘iterating,’ and abandoning your identity becomes ‘pivoting.’

Money amplifies all of it — few fields let a small room of people plausibly conjure hundreds of millions in value, which loads emotionally trivial decisions with the weight of everything the company hopes to become. Complexity fills the same psychological gap: a distributed event-driven platform with a service mesh feels more important than a boring CRUD app, and complicated systems generate work, ownership, status, and debate. The result is self-reinforcing — the system exists partly to sustain the org that exists partly to sustain the system — and, crucially, it’s nearly invisible from the inside. The takeaway for engineering leaders is a discipline of restraint: the existence of a take-able action is not the same as a need to take it.