Now the cursor is just mocking me, blinking at the top of a 201-line file that should have been 11 lines of simple configuration. I spent the last 41 minutes picking literal coffee grounds out of the crevices of my mechanical keyboard with a toothpick-a penance for a morning spill-and it occurs to me that this is the perfect metaphor for what I am currently doing with the codebase. I am picking through the grit left behind by someone who thought they were being brilliant, but was actually just being selfish. The ‘package.json’ file is a list of 51 dependencies that sound like indie bands from the mid-2000s. Why are we using a custom-built, experimental state-management library that hasn’t seen a commit in 101 days? Because Dave, who is now a ‘Principal Architect’ at a crypto startup in Berlin, wanted to prove he could master functional reactive programming on the company dime.

Dave’s ghost haunts every corner of this project. He was the kind of engineer who never met a stable, boring technology he didn’t want to replace with something ‘paradigm-shifting.’ He didn’t build software to solve the business’s problems; he built software to solve his own career trajectory issues. This is the Resume-Driven Developer (RDD). For Dave, every project was a training ground, a place to accumulate 11 or 21 niche skills that would look impressive on a LinkedIn profile. The problem, of course, is that Dave isn’t here to maintain the 31 microservices he spawned for a tool that serves exactly 401 active users. He’s gone, and we are left with the architectural equivalent of a house built out of expensive, custom-made glass bricks that no one knows how to replace when they inevitably shatter.

The Hospice Musician vs. The Paradigm Shifter

I think about Theo B.-L. quite often in these moments. Theo is a hospice musician I met a few years ago. He doesn’t play for crowds of 1001 people. He plays a small, weathered harp for 1 person at a time, usually someone who is in their final 11 hours of consciousness. Theo doesn’t care about the ‘industry.’ He doesn’t try to innovate the structure of the scales or introduce jarring, avant-garde techniques to prove his mastery. He plays what the moment requires: something stable, something resonant, something that provides peace rather than friction.

“He once told me that the greatest sin a performer can commit is making the performance about the performer instead of the listener.”

– Theo B.-L. (Recounted)

“

In tech, we have forgotten this entirely. We have made the performance about our personal tech stacks, our GitHub contributions, and our ‘innovative’ approaches, while the user-the person we are supposed to be serving-is left shivering in a cold room while the music is too loud and too complex.

Incentive Misalignment

The developer vs. the company goals creates a gap (represented below by scale).

There is a fundamental misalignment in the industry that we rarely talk about because it feels like a betrayal of our own ambitions. A developer’s personal incentive is almost always to learn the newest, most marketable thing. If you spend 201 days working on a legacy Java app, your market value might stagnate. If you spend those same 201 days forcing a project to use Rust, Kubernetes, and a headless CMS that is currently in alpha, you are suddenly a ‘high-value asset’ in the eyes of recruiters. The company’s incentive, however, is the polar opposite. The company needs 1 thing: reliability. They need a system that doesn’t fall over when the lead dev catches a cold. They need something that can be maintained by a junior with 1 year of experience, not a wizard with a PhD in category theory.

The Cost of Vanity Innovation

This gap creates a toxic cycle. We build systems that are 31 times more complex than they need to be. We add layers of abstraction that solve problems we don’t even have yet. I recently saw a project that used a complex message queue system to handle a task that occurred roughly 11 times a day. A simple cron job would have sufficed. But the engineer didn’t want to put ‘cron job’ on his resume. He wanted to say he ‘scaled a distributed event-driven architecture.’ The fact that it cost the company an extra $1201 a month in cloud fees and required 61 hours of configuration was secondary to the fact that his resume was now shiny. It is a form of soft sabotage, a way of stealing organizational time to fund personal education.

I’m not saying we should never innovate. That would be a lie, and I hate it when people pretend the old ways were always better. I’ve spent 41 percent of my career fixing things that were ‘stable’ but actually just broken in predictable ways. But there is a massive difference between necessary innovation and vanity innovation. When you look at companies that actually deliver value over the long haul, they usually have a profound respect for the ‘boring’ stuff. They understand that the goal isn’t to have the most sophisticated infrastructure in the world; it’s to have the infrastructure that stays out of the way. Take the world of high-stakes communication, for instance. If you are handling critical infrastructure like Email Delivery Pro, you don’t experiment with the fundamental protocols just for the sake of novelty. You lean into what is proven, what is reliable, and what actually gets the job done without requiring a 91-page manual to understand.

The Debt We Leave Behind

The complexity we leave behind is a debt that we never have to pay ourselves. We move on. We get the new job, the 31 percent raise, the fancy new title. But the engineers who come after us are the ones who have to pick the coffee grounds out of the keyboard. They are the ones who have to explain to the CEO why a simple feature update is taking 21 days instead of 2 hours. They have to navigate the 501 different dependencies that are all conflicting with each other because the original author wanted to use a ‘bleeding edge’ build tool that was abandoned by its creator 11 months ago.

The Relational Lie

I remember one specific project where the lead dev insisted on using a custom-built NoSQL database for a relational data set. He argued that it would allow for ‘limitless horizontal scaling.’ We had 401 customers. We didn’t need horizontal scaling; we needed a JOIN statement. But he spent 61 days writing a translation layer to make the NoSQL database behave like a relational one. When he left, the translation layer was a ‘black box’ that no one dared to touch. Every time a new field needed to be added to the user profile, it was a 11-hour ordeal of debugging and fear. We were paralyzed by his ‘innovation.’ We were stuck in a cage he built to show off his bars.

The Comfort of Being Replaceable

There’s a strange comfort in simplicity that many developers find terrifying. If the code is simple, anyone can understand it. If anyone can understand it, you aren’t ‘special.’ You aren’t the indispensable genius who is the only one who can fix the 2:01 AM production crash. I suspect that a lot of Resume-Driven Development is actually a defense mechanism against being seen as ordinary. We build labyrinths so that we can be the only ones with the map. But the map is always changing, and eventually, even the creator gets lost in their own design.

I once spent 31 hours straight trying to find a memory leak in a system that was using a ‘revolutionary’ new memory management library. In the end, the leak was caused by a single line of code that the library’s documentation hadn’t bothered to mention because it was ‘too obvious.’ If we had used the standard library, the leak would have never happened. I remember sitting there, staring at the screen at 3:01 AM, feeling a profound sense of exhaustion. I wasn’t learning anything valuable. I was just cleaning up after someone else’s vanity. It felt like I was being robbed of my time and my sanity to satisfy the curiosity of a person who wasn’t even in the room anymore.

We should be asking: ‘Have you ever maintained a system for 1001 days?’ or ‘Tell me about a time you chose a boring technology over a shiny one to save the company money.’

– Proposed Interview Question

“

How do we fix this? It starts with a shift in what we value during the hiring process. If we only hire based on who knows the ‘latest’ framework, we are signaling that novelty is more important than utility. We should be asking: ‘Have you ever maintained a system for 1001 days?’ or ‘Tell me about a time you chose a boring technology over a shiny one to save the company money.’ We need to celebrate the engineers who write code that is so clear and so standard that they are essentially replaceable. That is the highest form of professional selflessness.

Theo B.-L. doesn’t have a flashy website. He doesn’t have a 51-page portfolio of his most ‘disruptive’ harp techniques. He just has a list of people who found comfort in his music during the hardest moments of their lives. That is his legacy. In the end, our codebases are the same. No one will care that you used the first-ever implementation of a specific library in a production environment. They will only care if the system worked, if the data was safe, and if the next person who had to touch it didn’t want to throw their keyboard out the window.

The Final Choice: Genius or Gardener?

I’m finally finished with the coffee grounds. My keyboard is clean, but the codebase I’m looking at is still a disaster. I have to decide now: do I rip out Dave’s experimental garbage and replace it with something that will last for the next 11 years, or do I just add my own layer of ‘cleverness’ to the pile? It’s tempting to fight fire with fire, to add a new library that I’ve been wanting to play with, just to make the day go faster. But then I think about the person who will be sitting in this chair 201 days from now, wondering why I did what I did. I think I’ll go with the boring option. I think I’ll play the harp. Is the urge to be remembered as a genius worth the cost of leaving a mess for those who follow?