Why the best engineers win by building less — and how to convince everyone else that’s not laziness.
The #1 Skill: Selling Simplicity to a Complex World
Why the best engineers win by building less — and how to convince everyone else that’s not laziness.
The hardest engineering problems are solved by removing constraints, not adding components — but try explaining that in a standup.
The best senior engineers I’ve worked with weren’t the ones building massive Kubernetes clusters with seventeen microservices. They were the ones who quietly deleted three services last quarter and made the oncall rotation actually survivable.
I spent my first three years adding things. Every problem needed a new service, a new queue, a new database. My PRs were these 2,000-line monuments to “thoroughness.” Then I joined a team maintaining 47 microservices for what was essentially a CRUD app with some background jobs. Half of them hadn’t been deployed in six months. Two were running different versions of the same business logic because nobody knew which one was canonical anymore. The oncall rotation was hell — you’d get paged, and your first twenty minutes were just figuring out which service was actually broken.
That’s when I learned the real skill isn’t building simple systems. It’s convincing everyone else that simple is better. And honestly? That second part is way harder.
The Complexity Trap is a Career Trap
Resume-Driven Development is real, and I’ve been guilty of it. I once pushed Kafka into a perfectly fine cron-job pipeline just because I wanted to say “we’re on Kafka now” in a performance review. The jobs ran once an hour. They processed maybe 5,000 records. A cron job with a database queue would’ve been fine — no, it would’ve been better because everyone on the team already understood cron and SQL. But Kafka was trendy. I wanted it on my resume.
This is how technical debt compounds, by the way. Every new technology is a promise: “This will make X easier.” What it actually means: another thing to monitor, another dependency to upgrade during security patches, another concept for the next hire to learn, another potential failure mode at 3 AM when you’re half-asleep trying to remember if Kafka auto-creates topics or not.
Junior engineers solve problems by adding code. Senior engineers solve problems by removing it. I learned that the hard way the first time I deleted 800 lines in a sprint and got asked in standup why my velocity was “low.”
Ah. So that’s the actual problem.
The Art of Subtraction
The PostgreSQL team has a saying: “Postgres is boring” — and that’s the highest compliment. Boring is what lets you sleep. I only understood that when I reviewed a design doc proposing Neo4j for a recommendation engine. The engineer’s argument was technically correct: “Graph databases are optimized for graph queries.” Sure. But our “graph” had 30,000 nodes, fit entirely in RAM, and could be queried with a recursive CTE in Postgres in 40ms. Oh wait — we already ran Postgres. We already monitored it. We already had automated backups. We already knew how to tune it when things got slow.
The proposed solution meant adding a new database, new backup procedures, new monitoring dashboards, new deployment pipeline, new oncall training docs. For 40ms queries that happened twice a day.
We stuck with Postgres. Wrote 30 lines of SQL. Moved on.
-- Find recommended items based on user behavior patterns
WITH user_interactions AS (
SELECT user_id, item_id, interaction_weight -- Weight based on action type
FROM interactions
WHERE user_id = $1 -- Current user
AND created_at > NOW() - INTERVAL '30 days' -- Recent activity only
),
similar_users AS (
SELECT i2.user_id, SUM(i2.interaction_weight) as similarity -- Aggregate by user
FROM user_interactions i1
JOIN interactions i2 ON i1.item_id = i2.item_id -- Users who liked same items
WHERE i2.user_id != $1 -- Exclude current user
GROUP BY i2.user_id
ORDER BY similarity DESC -- Most similar first
LIMIT 50 -- Don't need the whole universe
)
SELECT DISTINCT i.item_id, i.title, SUM(i.interaction_weight) as score -- Rank items
FROM similar_users su
JOIN interactions i ON su.user_id = i.user_id -- What similar users liked
WHERE i.item_id NOT IN (SELECT item_id FROM user_interactions) -- Not already seen
GROUP BY i.item_id, i.title
ORDER BY score DESC -- Best recommendations first
LIMIT 10; -- Just the top ones
That’s it. Runs in 40ms. No new infrastructure. No new failure modes. The next person who reads this doesn’t need to learn graph query syntax — they just need to understand SQL, which they already do.
I spent a week once building a feature flag system with percentage rollouts and user targeting. Wrote tests, deployment scripts, monitoring. Then someone pointed out we already had feature flags in our config management tool. We just weren’t using them creatively. All that code? Gone. The system got simpler. The team moved faster because there was one less thing to check when debugging.
That week taught me what I now call “negative coding”: solving business problems without writing new code at all. Sometimes the answer is using an existing service differently. Sometimes it’s changing a business process so the technical problem just… disappears. Sometimes it’s realizing that the feature request is actually asking for better documentation, not new functionality.
Maintainability isn’t about clean code. It’s about deletable code.
Every line you write is a liability — full of bugs you haven’t found yet and assumptions that will quietly become false. Ask anyone who’s tried to untangle a “clever” caching layer two years later. The question isn’t “How elegant is this?” It’s “How quickly can the next person rip this out when requirements change?”
Constraints force clarity — but only if you’re willing to admit most of your clever abstractions weren’t needed.
The Hard Part: Selling It
I once proposed using Postgres instead of Elasticsearch for a 100MB dataset because tsvector was plenty for our full-text search needs. The PM asked why we weren't using "industry standard tools." A junior dev said Elasticsearch would be great for their resume. My manager quietly wondered if I was being too conservative.
Doing less looks like doing nothing. Avoiding complexity looks like avoiding work. This is where simplicity dies — in the sprint planning meeting where you can’t show a Gantt chart of all the problems you’re not creating.
I learned this on a migration project where we were moving from a monolith to microservices — classic resume-driven architecture from two years prior. I proposed consolidating three services back into one because they were always deployed together, shared a database anyway, and the network calls between them added 200ms of latency to every single request.
The pushback was immediate: “We already built the microservices. You want to throw away that work?” Nobody wanted to hear that the work itself was the mistake. I thought I could just show them the latency graphs — like, look, P99 latency is 1.2 seconds and 200ms of that is just services talking to each other. Wrong approach entirely.
What changed my approach: watching a staff engineer sell a similar proposal by reframing it. He didn’t talk about simplicity or elegance. He talked about risk. He talked about money. He made the business case impossible to ignore.
So I rewrote the proposal like a cost report, not a philosophical essay about code aesthetics:
Current state: Three services, three deployment pipelines, three sets of logs to search during incidents. Mean time to deploy: 45 minutes because you had to coordinate three releases. Mean time to diagnose production issues: 30 minutes, minimum, because you had to check three services to find which one was actually broken.
Proposed state: One service, one pipeline, one log stream. Mean time to deploy: 15 minutes. Mean time to diagnose: 10 minutes because there’s only one place to look.
Savings: 6 engineering hours per week in deployment overhead. Estimated $50K/year in reduced oncall burden, calculated from incident frequency and average time engineers spent awake at 3 AM trying to trace requests across service boundaries.
Risks: Migration takes two sprints. Rollback plan: keep old services running for one release cycle in case we need to revert.
It wasn’t the elegance that convinced them — it was the discovery that we were burning 6 engineer-hours a week on deployment glue work nobody enjoyed. It was the $50K number. It was framing it as “risk reduction” instead of “I want cleaner code.”
Here’s the strategy: don’t argue for simplicity on aesthetic grounds. Argue on operational grounds. Count the costs. Measure the risks. Show the math. Write it down so it can be forwarded to directors who weren’t even in the meeting.
You’re not being lazy. You’re being responsible for the system’s total cost of ownership. But you have to make that case explicitly, in writing, with numbers.
Code is a Liability, Not an Asset
Companies don’t value lines of code. They value working systems that don’t wake people up at night. They value features that ship without derailing the roadmap six months later. They value teams that can still move fast when half the original engineers have left.
Every line of code is a commitment — to maintain it, to test it, to deploy it, to monitor it, to debug it when it breaks in production, to explain it to new team members who are trying to understand why things work this way. That’s not an asset. That’s a recurring cost that compounds over time.
The best engineering decision I ever made was killing a project I’d spent two months building. It was a caching layer that reduced API latency by 40%. Beautiful code, really. Well tested. Production ready. I was proud of it.
Then we profiled the actual user experience from their perspective. The API latency wasn’t the bottleneck — the frontend bundle size was. Users were waiting three seconds for JavaScript to download and parse on their phones. Our 40% API improvement saved them 80 milliseconds. Nobody noticed. Nobody could possibly notice 80ms when they were waiting three full seconds for the page to load.
We scrapped the cache. Optimized the bundle instead. Suddenly users actually noticed the improvement.
Here’s your challenge: open your current sprint. Look at every task, every story, every ticket on the board. Ask yourself this question: What can I remove from this solution?
Not “What can I add?” Not “What new technology could I introduce?” Not “What would make this more robust?” What can you delete? What can you simplify? What can you solve without writing new code at all?
Then — and this is the critical part — write it down. Show the savings in concrete terms: hours saved per week, dollars saved per year, incidents avoided per quarter. Show the risks you’re preventing: fewer failure modes, simpler oncall procedures, faster time to diagnose issues. Show the operational burden you’re eliminating: fewer dependencies to upgrade, fewer services to monitor, fewer concepts new engineers need to learn.
Make the case for subtraction. That’s the skill that separates people who build systems from people who build careers maintaining them.
The best code you ship this year will be the code you delete. The best system you design will be the one that looks obvious in retrospect — so obvious people forget how much complexity you had to kill to get there, how many tempting technologies you said no to, how many “but what if we need to scale” arguments you had to shut down with actual math instead of hypotheticals.
Just kidding. They’ll still ask why you’re not using Kubernetes.
Enjoyed the read? Let’s stay connected!
- 🚀 Follow The Speed Engineer for more Rust, Go and high-performance engineering stories.
- 💡 Like this article? Follow for daily speed-engineering benchmarks and tactics.
- ⚡ Stay ahead in Rust and Go — follow for a fresh article every morning & night.
Your support means the world and helps me create more content you’ll love. ❤️
Top comments (0)