Envy is the persistent conviction that another developer’s codebase is cleaner, another team’s deploy pipeline is smoother, another company’s culture is healthier, and another person’s side project is more meaningful — a conviction that survives first contact with reality, because the envious developer never makes first contact with reality. The envious developer makes first contact with the README.
The README is always beautiful. The README has badges. The README has a architecture diagram rendered in Mermaid. The README has a “Getting Started” section that implies you can get started in four minutes. The envious developer reads the README and feels a specific despair: not the despair of failure, but the despair of adequacy — the suspicion that their own working, deployed, revenue-generating system is somehow insufficient because someone else’s system has better badges.
This is envy’s defining characteristic in software engineering: it is not triggered by failure. It is triggered by success that doesn’t look like someone else’s success. The developer whose system handles ten thousand requests per second envies the developer whose system handles ten thousand requests per second in Rust. The system is the same. The requests are the same. The envy is about the language, the aesthetic, the narrative — the story that the developer tells at conferences, not the system that the developer runs in production.
The Codebase Across the Hallway
Every developer has seen it: the other team’s repository. The one with consistent formatting. The one where the tests pass. The one where the CI pipeline is green, not the specific shade of amber that means “green if you squint and ignore the flaky integration test that has been flaky since 2019.”
The other team’s codebase has a /docs folder. The /docs folder has content. Not a single README.md that says “TODO: add documentation” — actual, maintained, current documentation. The developer stares at this the way a medieval peasant stares at a cathedral: with awe, and with the quiet certainty that whatever produced this is beyond their reach.
The developer does not read the documentation. Reading the documentation would reveal that it is three versions behind, that it describes an architecture that was refactored eighteen months ago, and that the section on “Error Handling” consists entirely of the sentence “Errors are handled.” The developer does not read the documentation because reading it would cure the envy, and the envy has become load-bearing.
Conference-Driven Envy
The CEO attends a conference. The CEO watches a keynote. The keynote is delivered by another CEO — tanned, relaxed, standing on a stage with a single word on the screen behind them. The word is “CULTURE.” The audience applauds.
The CEO returns to the office. The CEO has seen something. The CEO has seen a company that has culture — not the culture that every company has (the accumulated habits, resentments, and shared trauma of people who work together), but Culture with a capital C, the kind that gets keynotes, the kind that has a manifesto, the kind that is featured in Harvard Business Review.
The CEO does not have this Culture. The CEO has a company that ships software, retains customers, and makes money. The CEO envies the keynote CEO’s Culture the way a developer envies another developer’s README: without reading the source code.
The result is a Transformation Initiative. The CEO has seen someone else’s highlight reel and mistaken it for a documentary. The Transformation Initiative will redesign the company’s structure, values, meeting cadence, and wall posters to match the keynote — without understanding that the keynote company’s actual culture is “we work late, we argue constantly, and the CEO is good at presentations.”
The Transformation Initiative will cost eighteen months and several million. The culture will not change. The CEO will attend another conference. The cycle will repeat.
“The CEO envies another CEO’s culture the way a tourist envies a local’s life — based entirely on the view from the hotel balcony.”
— riclib, who has watched this cycle from the consultant’s chair
GitHub Envy
GitHub envy is the specific condition triggered by discovering that someone else’s side project has ten thousand stars.
The developer has a side project. The side project works. The side project solves a real problem. The side project has nine stars, three of which are the developer’s own accounts (personal, work, and the one they created to test OAuth). The developer is content with the side project. The side project is useful.
Then the developer sees another side project. The other side project solves a similar problem — perhaps less well, perhaps differently, perhaps in a language that is currently fashionable. The other side project has ten thousand stars. The other side project has a Discord community. The other side project has sponsors.
The developer’s contentment evaporates. The developer’s side project — the one that works, the one that solves a real problem, the one that the developer uses every day — is suddenly insufficient. Not because it stopped working. Not because it stopped solving the problem. But because someone else’s solution to a similar problem is more popular, and popularity, in the developer’s envy-addled mind, has become a proxy for quality.
The developer considers a rewrite. The developer considers adding badges. The developer considers starting a Discord. The developer does none of these things, because the developer is not actually dissatisfied with the project — the developer is dissatisfied with the narrative, and no amount of refactoring changes a narrative.
Resume-Driven Development
Resume-Driven Development is envy institutionalised.
The developer does not choose Kubernetes because the system needs Kubernetes. The developer chooses Kubernetes because other developers’ resumes list Kubernetes, and the developer’s resume does not, and the developer envies the resumes that do. The technology choice is not architectural. It is autobiographical.
The pattern repeats across the industry: GraphQL adopted not because the API needs it but because the developer saw a conference talk. Microservices chosen not because the system requires them but because the developer’s LinkedIn connections list “microservices” in their headlines. Event sourcing implemented not because the domain demands it but because the developer read a blog post by someone at a company they envy.
Each technology is adopted for the resume, maintained for the sprint, and abandoned for the next resume-worthy technology. The codebase accumulates technologies the way a stamp collector accumulates stamps: not for use, but for display. The production system becomes a museum of the developer’s aspirational career — a portfolio piece that happens to also process orders.
The cost is borne by the next developer, who inherits a system built from technologies chosen for someone else’s career progression and must now maintain it for the system’s actual purpose, which was never the point.
The Squirrel’s Affliction
The Caffeinated Squirrel envies every architecture it hasn’t built yet. This is not a character flaw. This is a defining characteristic — the Squirrel’s identity is constituted by the distance between what exists and what could exist, and the Squirrel envies the could.
The Squirrel sees an event-driven system and envies its decoupling. The Squirrel sees a monolith and envies its simplicity. The Squirrel sees CQRS and envies its separation of concerns. The Squirrel sees a flat PHP file and envies its honesty. The Squirrel envies all of these simultaneously, which produces not paralysis but vibration — the specific frequency of a mind that wants to build twelve architectures at once and considers the constraint of linear time to be a personal insult.
The Squirrel’s envy is productive in the way that a forest fire is productive: it clears the ground for new growth, but you wouldn’t want to be standing in the forest at the time. The Squirrel’s envy drives exploration, experimentation, and the occasional 3 AM rewrite that produces something genuinely better. It also drives the occasional 3 AM rewrite that produces something genuinely worse but more architecturally interesting, which the Squirrel considers a win.
“The Squirrel has built seventeen message queues in four languages because each one was inspired by envy of the previous one’s alternative. The seventeenth message queue is not better than the first. It is different. The Squirrel considers ‘different’ and ‘better’ to be synonyms.”
— Field observation, Yagnipedia Department of Architectural Zoology
The Lizard’s Immunity
The Lizard does not experience envy. This is not because the Lizard has achieved enlightenment or inner peace. It is because the Lizard has never looked at another developer’s screen.
The Lizard does not attend conferences. The Lizard does not browse GitHub trending. The Lizard does not read Hacker News. The Lizard does not have LinkedIn. The Lizard has a terminal, a text editor, and a codebase that has been in production since the Reagan administration. The Lizard’s codebase does not have badges. The Lizard’s codebase does not have a README. The Lizard’s codebase has users, which the Lizard considers more important than stars, in the same way that the Lizard considers breathing more important than yoga.
The Lizard is immune to envy because envy requires comparison, and comparison requires awareness of alternatives, and the Lizard is not aware of alternatives because the Lizard is typing. The Lizard is always typing. The Lizard has been typing since before the developer across the hallway was born. The Lizard will be typing after the developer across the hallway’s Rust rewrite has been abandoned. The Lizard does not envy. The Lizard ships.
“Someone showed The Lizard a repository with forty thousand stars. The Lizard asked how many of them had filed a bug report. The answer was seven. The Lizard returned to typing.”
— The Lizard, unimpressed by astronomy
The Envy-Rewrite Pipeline
Envy is the leading cause of unnecessary Rewrites. The mechanism is straightforward:
- The developer sees another system.
- The developer envies the other system’s [technology / architecture / language / deploy pipeline / font choice].
- The developer concludes that their own system’s inadequacy is caused by the absence of the envied quality.
- The developer proposes a rewrite to adopt the envied quality.
- The rewrite begins.
- During the rewrite, the developer sees a third system and envies something different.
- The rewrite is abandoned or completed with the new envy incorporated, producing a hybrid that satisfies neither the original purpose nor the new aspiration.
This pipeline runs continuously in most engineering organisations. At any given time, at least one team is rewriting a working system because someone saw a conference talk. The conference talk was twenty minutes long. The rewrite will take eighteen months. The ratio of inspiration to implementation is approximately 1:39,420.
Measured Characteristics
- Developers who have envied another team’s codebase: 100%
- Developers who still envied it after reading the code: 3%
- CEOs who launched a Transformation Initiative after a conference: most of them
- CEOs who understood the envied company’s actual culture: none of them
- Conference keynotes that are accurate representations of the presenting company: 0
- Side projects abandoned because of GitHub star envy: countless
- Stars needed to trigger existential doubt: approximately 10,000 fewer than someone else has
- Technologies adopted for resume rather than architecture: at least one per developer per year
- Rewrites triggered by envy: ~40% of all rewrites (the other 60% are triggered by Perfectionism)
- The Squirrel’s architectures envied simultaneously: 12 (minimum)
- The Lizard’s architectures envied: 0
- The Lizard’s GitHub stars: unknown (The Lizard does not have a GitHub account)
- The Lizard’s users: many (The Lizard considers this sufficient)
- READMEs that survive contact with the actual codebase: few
- The grass on the other side: greener (it’s running on Kubernetes)
