Cargo Cults and Resume Driven Development: Building What Matters, Not What's Trendy

Intro

Two mindsets quietly destroy more software projects than bad code ever could: cargo cult programming and resume driven development.

Neither is about incompetence. Both come from smart people making decisions for the wrong reasons. And both lead to over-engineered systems, bloated tech stacks, missed deadlines, and frustrated teams.

This article explains what these patterns look like, why they’re so damaging, and how to build technology choices around what actually matters: solving real problems.

Cargo Cult Programming

The term comes from Richard Feynman’s 1974 Caltech commencement speech about “cargo cult science.” During World War II, Pacific Islanders watched planes land with supplies — cargo — and associated the rituals they observed with the arrival of goods. After the war, they built bamboo runways, wooden control towers, and coconut headphones, mimicking the form without understanding the function.

Cargo cult programming is the same instinct. Developers adopt patterns, tools, and architectures from companies like Google, Netflix, or Amazon without understanding the problems those solutions were built to solve.

What It Looks Like

A three-person startup building a todo app with a microservices architecture, Kubernetes, a service mesh, and a Kafka cluster. Why? Because that’s what the Netflix engineering blog described, and Netflix is successful, so their architecture must be the reason.

But Netflix has thousands of engineers and millions of concurrent users. Their architecture solves Netflix’s problems. It doesn’t solve the three-person startup’s problems — it creates new ones.

The Pattern

You see it everywhere:

• Event sourcing for a basic CRUD app that tracks inventory
• GraphQL because “REST is dead” — even though REST would have shipped in a week
• Kubernetes for a static website with 500 monthly visits
• Microservices for a system with three endpoints and one developer

The common thread: adopting the output of someone else’s solution without understanding their input. Copying the what without the why.

Resume Driven Development

Resume driven development (RDD) is cargo cult programming’s career-focused cousin. Instead of copying successful companies, you’re optimizing your tech stack for your next job interview.

What It Looks Like

A team chooses Rust for a web service that processes forms. Rust is a great language. But the team has no Rust experience, the ecosystem for web services is less mature than alternatives, and the performance benefits are irrelevant for the workload.

The unspoken reason: Rust looks better on a resume than Node.js or Python. It signals sophistication. It generates conference talk proposals.

The Pattern

RDD shows up as:

• Choosing the hot new framework over the stable, well-documented one
• Rewriting a working system in a new language “for performance” when performance wasn’t a problem
• Adding blockchain to an application because someone wants “Web3 experience”
• Picking the tech stack based on HN front page trends rather than team expertise and project requirements

The rationalization always sounds technical. The real motivation is career signaling.

The Real Cost

Both patterns share the same consequences:

Complexity without value. Every technology choice adds maintenance burden, onboarding friction, operational overhead, and cognitive load. When that technology doesn’t solve an actual problem, you’re paying the cost without receiving the benefit.

Slower delivery. Learning unfamiliar tools, debugging novel failure modes, integrating unproven libraries — all of this delays shipping. In a startup, shipping speed is survival.

Hiring difficulty. A stack built around rare skills reduces your hiring pool and increases your costs. There are far more developers who know PostgreSQL and Python than developers who know niche distributed databases and Rust.

Team burnout. Working with unfamiliar, unnecessarily complex tools is exhausting. Smart engineers leave when they spend more time fighting the stack than solving problems.

Choosing Better

Understand Before Adopting

Before adopting any technology, answer three questions:

1. What problem does this solve for us, specifically?
2. What new problems will this create?
3. Could we accomplish the same thing with tools we already know?

If you can’t answer question one concretely — not with “it’s the industry standard” or “Netflix uses it” — you’re not ready to adopt.

Choose Boring Technology

Dan McKinley popularized the concept of “choose boring technology” at Etsy. The idea: your innovation budget is limited. Spend it on the things that differentiate your business, not on your database, your deployment platform, or your programming language.

Boring technology doesn’t mean bad technology. It means technology that’s well-understood, well-documented, and widely deployed. You know where the sharp edges are. You can hire people who know it. You can find answers when things break.

PostgreSQL is boring. It’s also one of the most reliable, capable databases ever built. Express.js is boring. It’s also one of the fastest ways to ship a web application. Boring works.

Match The Tool To The Problem

Start with the problem, not the solution. What are you actually building? Who uses it? How many users? What are the constraints?

A distributed system for a global real-time application is a different problem than an internal dashboard used by five people. The tools should be different.

Ask Better Questions

When someone proposes a technology choice, ask:

• “What problem does this solve that our current approach doesn’t?”
• “What’s the simplest thing that could work?”
• “What happens if we don’t do this?”
• “How will we maintain this in three years?”
• “Can we hire people who know how to use this?”

If the answers are weak, push back.

When To Use New Technology

This is not an argument against learning or adopting new technology. It’s an argument against adopting it for the wrong reasons.

Use new technology when:

• It solves a concrete problem your current tools can’t
• The team has time to learn it properly
• The risk of adoption is proportional to the value it provides
• You’re willing to maintain it for the life of the project

Don’t use it because it’s trending, because it makes your resume look good, or because a famous company blog described it.

Conclusion

Cargo cult programming and resume driven development are symptoms of the same underlying failure: making technology decisions based on external signals rather than internal needs.

The best engineering decisions are boring from the outside. They’re driven by the specifics of the problem, the constraints of the team, and the needs of the business. They optimize for delivery, maintainability, and sustainability — not for conference talks or job interviews.

Before you add that new framework, that new database, or that new architectural pattern, ask yourself: am I solving a real problem, or am I building a bamboo runway?