The dry-erase marker squeaked against the board, a high-pitched protest that felt like it was drilling directly into my temple. Marcus was drawing another set of interlocking boxes, each one representing a microservice that, in his view, was absolutely non-negotiable for our new internal inventory tool. ‘We need to think about horizontal scaling from day one,’ he insisted, his eyes bright with the kind of fervor usually reserved for religious awakenings or winning the lottery. He wasn’t looking at the product requirements. He wasn’t looking at the fact that only 17 people would ever use this application at any given time. He was looking at his LinkedIn profile, specifically the ‘Skills’ section that currently lacked any mention of distributed systems orchestration. My hand throbbed from a failed encounter with a stubborn pickle jar earlier that morning-a humiliating defeat where the glass remained sealed and my ego remained bruised-and the physical discomfort only sharpened my irritation with the whiteboard architecture sprawl.
Diagnosis
We were witnessing a classic case of Resume-Driven Development (RDD), a phenomenon where technical choices are dictated not by the needs of the business, but by the marketability of the stack on a developer’s future job application. It’s a quiet, pervasive betrayal.
We sit in these meetings and talk about ‘future-proofing’ and ‘high availability,’ but the subtext is often much simpler: ‘I want to be paid $187,000 at my next gig, and nobody is hiring for monolithic Rails apps anymore.’ It’s a career survival mechanism masquerading as engineering excellence. In a volatile market where job security feels like a fever dream, engineers naturally gravitate toward the hottest, most complex technologies to ensure they don’t become obsolete.
The Citizen of the System
Oliver A.J., a digital citizenship teacher who occasionally consults with our team on the ethics of handling data, sat in the corner of the room, leaning back in a chair that creaked every time he shifted. He doesn’t write code, but he understands human behavior better than most of us who live behind compilers. He watched Marcus draw a 37th box on the board and finally spoke up.
“
Marcus, who is the citizen of this system? Is the citizen the person trying to track a pallet of lumber, or is the citizen the engineer who wants to put “Kubernetes Expert” on their CV? Because right now, the infrastructure you’re proposing has more layers of bureaucracy than a small nation-state.
There was a long silence. I looked at the whiteboard. To support a simple database and a few forms, Marcus was proposing a tech stack that included 7 different managed services, a message bus that could handle 10,007 transactions per second, and a frontend framework that had been released exactly 47 days ago. It was a masterpiece of over-engineering. It was also a ticking time bomb of maintenance debt. Every new tool added to a stack isn’t just a line on a resume; it’s a permanent tax on the company’s velocity.
For every trendy tool adopted without direct need.
[The company bears the long-term cost of an employee’s short-term career optimization.]
The Cost of Polish
This misalignment of incentives is where projects go to die. We tell ourselves we are building for the future, but we are often just building for our own exit strategy. I’ve been guilty of it myself. Years ago, I insisted on using a graph database for a project that could have been handled by a simple CSV file. I spent 27 nights in a row debugging edge cases in a query language I barely understood, all because I thought it would make me look ‘cutting edge.’ I failed the product, I frustrated my stakeholders, and in the end, the company had to hire a consultant for $7,777 to fix the mess I made. I was so focused on being a ‘visionary’ that I forgot to be a problem solver.
When we choose complexity over utility, we are essentially stealing from the future of the product to pay for our own professional polish. It’s a form of technical debt that is rarely discussed in agile retrospectives because it’s deeply personal. We wrap these selfish choices in the language of scalability and performance. We use 107 lines of code where 7 would suffice, justifying the bloat with vague warnings about ‘tight coupling’ or ‘lack of extensibility.’
Craftsmanship vs. Laboratory Work
Experimental Polymers
Durable, Tested Materials
This approach is taken by professionals like LVP Floors, where the focus is on suitability, not trendiness. Engineering should be no different.
Digital Citizenship
Oliver A.J. often tells his students that digital citizenship is about responsibility to the community you inhabit. In the context of a software team, that community includes the stakeholders who pay the bills, the users who rely on the software, and the future maintainers who will have to live with your decisions long after you’ve hopped over to a Series B startup for a 27% raise.
The Two Legacies
The Shiny Stack
High complexity, immediate resume boost, high maintenance tax.
The Simple Path
Zero outages in 107 weeks, low entry barrier for juniors.
[Technical decisions are career decisions in disguise.]
Honesty in Selection
We need to start having more honest conversations about why we choose the tools we do. If a developer says we ‘need’ a certain technology, the follow-up question shouldn’t just be about its technical merits. It should be: ‘If you knew you were going to stay at this company for the next 17 years, would you still choose this tool?‘ Usually, the answer changes. When you’re the one getting paged at 3:07 AM because a sidecar container in your service mesh decided to stop communicating with the control plane for no apparent reason, the ‘shiny’ wears off real fast.
The Pickle Jar Test
I’m still thinking about that pickle jar. I tried to force it with brute strength instead of using a bit of leverage or a simple trick like running it under hot water. Software development is the same. We try to force these massive, complex architectures onto simple problems because we want to feel powerful or relevant.
Oliver A.J. eventually walked over to the whiteboard and picked up an eraser. He didn’t erase the whole thing, just a few of the outer boxes. ‘Let’s start with the middle,’ he suggested. ‘Let’s build the part that actually solves the user’s problem. If we find out later that we really, truly need the other 27 boxes, we can add them then.’
“
We weren’t talking about keywords anymore; we were talking about helping people.
There is a certain dignity in choosing the simple path. It requires more discipline to build something small and robust than it does to build something large and fragile. Good companies-the ones you actually want to work for-value problem solvers over tool-collectors. They want the person who can open the pickle jar, not the person who builds a $77,000 robotic arm to do it for them.
Utility over Vanity.
Ultimately, our code is our footprint. We can choose to leave behind a clear, well-paved path for others to follow, or we can leave behind a tangled jungle of ‘revolutionary’ tech that eventually chokes the very product it was meant to support. The choice is made in every architectural meeting, in every pull request, and in every moment where we decide whether we are building for the user, or building for our next recruiter call. I’ve made my share of mistakes, but I’m trying to be better. I’m trying to remember that a floor is meant to be walked on, and code is meant to be run, and neither one should be a monument to the architect’s personal insecurities. It’s about the foundation. If we can get that right, the rest-the resumes, the titles, the salaries-will take care of itself.