Most developers polish code like museum curators—endless care for artifacts nobody visits. They'll spend a Tuesday afternoon refactoring a function that calculates tax rates for discontinued products, debating whether a nested loop or functional approach reads cleaner.
What if I told you the most productive thing you could do with that function is delete it entirely?
I learned this watching a CTO at a Series B startup. Every week, engineers would present their "optimization wins"—10% faster API calls, cleaner component hierarchies, reduced bundle sizes. Meanwhile, their core product was buckling under feature bloat, user complaints were piling up, and new developer onboarding took three weeks because nobody could explain what half the codebase actually did.
Then something shifted. Instead of asking "How do we make this faster?" the CTO started asking "Why does this exist?" Instead of optimizing, they started subtracting. Six months later, they'd removed 40% of their codebase and doubled their development velocity.
The uncomfortable truth? Most code optimization is creative avoidance disguised as productivity.
Buck the Crowd: Delete Before You Optimize
While everyone else is chasing the latest performance patterns, try reversing the entire premise. The fastest code is the code that never runs. The most maintainable feature is the one that doesn't exist. The cleanest architecture eliminates entire layers of complexity.
I once worked with a team that spent three months optimizing their notification system. They built elegant queues, implemented retry logic, added monitoring dashboards. Beautiful engineering work. Then someone asked: "What if we just sent fewer notifications?"
They analyzed user behavior and discovered 80% of their notifications were ignored or actively annoying users. Instead of optimizing the delivery system, they deleted most of the notifications entirely. User satisfaction went up, server costs went down, and the engineering team could focus on features that actually mattered.
This is what happens when you buck the conventional wisdom that more code equals more value. Sometimes the boldest technical decision is the one that makes previous technical decisions irrelevant.
Reverse Your Perspective: Start With What's Missing
Most developers look at slow code and think "How do I make this faster?" Try flipping that question: "How do I make this unnecessary?"
That authentication middleware you're optimizing? Maybe the real solution is designing user flows that require less authentication. That complex state management system you're refactoring? Maybe the interface is trying to do too much at once. That database query you're tuning? Maybe you're storing data you don't actually need.
I've seen teams spend months optimizing checkout flows when the real problem was having too many steps. The solution wasn't faster form validation—it was eliminating half the forms. They weren't solving an engineering problem; they were solving a product design problem that manifested as slow code.
When you reverse your perspective from "fix" to "eliminate," you start noticing how much engineering effort goes toward solving problems that shouldn't exist in the first place.
Find What's Out of Whack: The Code That's Working Too Hard
Every codebase has functions that are suspiciously complex for what they accomplish. They're the digital equivalent of Rube Goldberg machines—impressively overcomplicated solutions to simple problems.
These functions usually start innocently. Someone adds a parameter. Then an edge case. Then another parameter. Then some conditional logic to handle the parameter combinations. Before long, you have a 200-line function that does twelve different things, none of them particularly well.
The optimization instinct says "refactor this into smaller functions." The deletion instinct says "why does this function need to do twelve things?" Usually, it doesn't. Usually, eleven of those things can be handled elsewhere, or eliminated entirely, or were solving problems that no longer exist.
I've found that the most complex functions in a codebase are often the ones working hardest to maintain backward compatibility with features nobody uses anymore. Deleting those features is often easier than optimizing around them.
Seek Other Right Answers: Beyond Faster Code
When you're staring at slow code, "make it faster" feels like the only right answer. But there are always other right answers hiding in plain sight.
Make it run less frequently. Make it run asynchronously. Make it someone else's problem by using a third-party service. Make it irrelevant by changing the user experience. Make it disappear by questioning why it exists at all.
I worked with a startup that had a notoriously slow search feature. For months, engineers tried different algorithms, caching strategies, and database optimizations. Nothing moved the needle significantly.
Then someone suggested they weren't really solving a search problem—they were solving a navigation problem. Users weren't searching because they enjoyed searching; they were searching because they couldn't find things. By improving the information architecture and navigation, search usage dropped 60%. The slow search became a non-issue because fewer people needed to use it.
The right answer wasn't faster search. It was less need for search.
The Discipline of Productive Laziness
Deleting code requires a particular kind of intellectual honesty that optimization doesn't. When you optimize, you can always claim you're making things better. When you delete, you have to admit you might have built the wrong thing in the first place.
This is why deletion feels riskier than optimization, even though it's usually safer. Optimization preserves your past decisions while making them marginally better. Deletion questions whether those decisions were correct to begin with.
But this questioning is exactly what separates valuable engineers from code janitors. Anyone can make existing code faster or cleaner. It takes judgment to recognize when existing code is solving the wrong problem entirely.
Use tools like Claude 3.7 Sonnet not to generate more code, but to analyze what you already have. Ask it to identify functions that haven't been called recently, features with low usage, or components that seem to duplicate functionality elsewhere. Let it help you find the dead weight in your system.
When you're tempted to refactor, try Document Summarizer on your own code documentation first. If you can't explain why a piece of code exists in a few sentences, that's often a signal it shouldn't exist. If the explanation is more complex than the code itself, you're probably over-engineering.
The goal isn't to delete everything—it's to develop the instinct to question everything. That instinct, more than any optimization technique, is what will make your systems truly faster, more reliable, and easier to maintain.
The Paradox of Less
Here's what I've noticed about the best engineering teams: they ship more by building less. They solve problems faster by working on fewer problems. They create more reliable systems by having fewer moving parts.
This paradox only makes sense when you realize that most technical complexity comes from trying to solve too many problems at once, or solving problems that don't need solving, or maintaining solutions to problems that no longer exist.
The code you delete today is code you don't have to debug tomorrow, maintain next month, or explain to new team members next year. Every line you remove is a small gift to your future self.
Start small. Find one function that seems unnecessarily complex and ask why. Look for one feature with suspiciously low usage and question whether it's worth maintaining. Identify one piece of technical debt that exists only to support something you're not sure anyone uses.
The most elegant code isn't the most clever code. It's the code that doesn't need to exist because you solved the problem at a different level entirely.
What would your system look like if you optimized for simplicity instead of performance? What problems would disappear if you stopped trying to solve them?
-Leena:)
Top comments (0)