Computers Are Cheap, Developers Are Expensive

Your AWS bill is a rounding error compared to your payroll. That's not opinion: it's math. In the early 2000s, a friend whose judgment I deeply respect told me something that rewired how I think about code: "Computers are cheap. Good developers are expensive."

Updated January 2026: Added "The Intelligence Tax" section on GPU/LLM costs. The core principle holds for commodity compute—but AI inference is now a real budget line item that breaks the old math.

I pushed back. Of course I did. I'd spent decades learning to write tight, efficient code. I could tell you exactly how many instructions a loop would generate. Assembly never really left my thinking. I took pride in it. Wasn't that the whole point?

He'd worked at Facebook, Amazon, and Google at senior levels. Places where scale actually mattered. He wasn't dismissing optimization. He was reframing when it matters. And he was right.

The Perfectionist Trap

I understand why developers obsess over optimization. I was one of them for decades.

There's something deeply satisfying about shaving milliseconds off a function. Watching a profiler show your changes made a difference. Knowing your code is as efficient as it can possibly be. It feels like craftsmanship. It feels like you're doing your job right.

But here's what I didn't understand back then: that satisfaction can be a trap. The dopamine hit of optimization can lead you to spend a week perfecting code that runs once a day for three users.

There's also a perverse incentive nobody talks about: "Optimized database queries by 50%" looks great on a resume. "Shipped feature on time using straightforward code" doesn't. We optimize partly because it feels good, and partly because it's easier to measure than business impact.

The Economics Nobody Taught Me

Let's do the math that changed my thinking. According to Levels.fyi's 2024 compensation data, senior engineers at top companies earn $200-400K+ annually. Meanwhile, AWS EC2 pricing continues its steady decline, with on-demand compute now costing pennies per hour:

If a developer spends 8 hours optimizing code to save $10/month in compute costs, that's $800-1,600 in developer time to save $120/year. The payback period is 7-13 years, assuming the code even lives that long.

    THE OPTIMIZATION MATH
    ═════════════════════════════════════════

    8 hours × $200/hour = $1,600 spent

    $10/month × 12 months = $120/year saved

    Payback: 13+ YEARS

    Average codebase lifespan: 3-5 years

    Result: NET LOSS

Most code doesn't live long enough to pay back the optimization investment.

The True Cost of Optimization Calculator

Before optimizing, do this math:

The Rule of 10x

Only optimize if the hardware cost is 10x the developer's weekly salary.

A senior developer costs ~$4,000/week loaded. That means: don't optimize unless you're saving $40,000/month in infrastructure. Below that threshold, the developer time is more valuable than the compute savings.

This sounds aggressive, but it accounts for reality:

• Optimized code is harder to maintain (future developer cost)
• Requirements change (optimization becomes irrelevant)
• Hardware gets cheaper (savings shrink over time)
• Opportunity cost (features not shipped)

When I Was Wasting Time

Looking back, I can see all the hours I burned on optimizations that never mattered.

• Micro-optimizing database queries that ran in batch jobs at 3am when nobody cared if they took 2 seconds or 20
• Hand-tuning algorithms for datasets that would never exceed a few thousand records
• Rewriting readable code to be marginally faster but incomprehensible to the next developer
• Premature caching for endpoints that got hit twice a day

Every hour I spent on these "optimizations" was an hour I didn't spend shipping features, fixing real bugs, or going home to my family.

The Questions That Actually Matter

That conversation taught me to ask different questions before optimizing:

• How often does this code run? Once a day? Once a second? Once a millisecond? The answer changes everything.
• Who's waiting for it? A user staring at a loading spinner? A batch job that runs overnight? An internal tool three people use?
• What's the actual bottleneck? Is it CPU? Memory? Network? Database? Or is it fast enough and I just want it to be faster?
• What else could I build with this time? The opportunity cost of optimization is the feature you didn't ship.

I've written before about how users don't care about your architecture. They also don't care if your code is "elegant" or "optimal." They care if it works and if it's fast enough.

The Dangerous Exception

Here's where it gets nuanced. Sometimes optimization absolutely matters.

I wrote recently about Grace Hopper's nanosecond wire: the physical limits that no amount of hardware can overcome. When you're fighting physics, when latency is the product, when milliseconds mean money, optimization isn't optional.

The trick is knowing which situation you're in:

The pattern: optimize when humans are waiting or when the code runs at massive scale. Otherwise, ship it and move on.

What "Good Enough" Actually Means

This isn't an argument for sloppy code. There's a difference between "not optimized" and "badly written."

Good enough means:

• Readable. The next developer can understand it without a decoder ring.
• Correct. It does what it's supposed to do.
• Fast enough. Users don't notice or complain.
• Maintainable. You can change it without breaking everything.

What it doesn't mean is "as fast as theoretically possible" or "using the cleverest algorithm" or "optimized for a scale you'll never reach."

The Readability Trade-off

Here's a truth I learned too late: optimized code is often harder to read. And code that's hard to read is expensive to maintain. As Poul-Henning Kamp wrote in ACM Queue, "premature optimization is the root of all evil" isn't just a clever saying. It's a warning about where developer time actually goes.

That clever bit-manipulation trick that saves 3 nanoseconds? The next developer will spend 30 minutes understanding it. If ten developers touch that code over its lifetime, you've traded 3 nanoseconds for 5 hours of human time. And that's before anyone introduces a bug because they didn't understand what the code was doing.

The economics don't work.

The Cloud Changed Everything

When I started programming, compute was genuinely expensive. You optimized because you had to. Memory was measured in kilobytes. CPU cycles were precious.

That world is gone.

Today, if your code is slow, you can often just throw more hardware at it. Spin up another instance. Add more RAM. Use a bigger database. The cloud makes horizontal scaling trivial in ways that would have seemed like magic in 1995.

The RAM Tax caveat: While CPU is cheap, memory capacity and bandwidth are the hidden scalers. A Redis cluster holding 500GB of hot data isn't cheap. Memory-optimized instances cost 2-4× more than compute-optimized. When your working set exceeds what fits in RAM—whether it's a recommendation engine, a graph database, or an in-memory cache—you're suddenly paying the "RAM Tax." This is where physics reasserts itself: the difference between hitting RAM vs. hitting disk is 1,000×.

This doesn't mean optimization never matters. It means the default becomes "ship it and see" rather than "optimize first."

The Exception: The Intelligence Tax

Here's where I need to eat some of my own words: not all compute is cheap anymore.

Moore's Law made CPUs cheap. But there's no "Token Law" making reasoning cheap. If your application is making LLM calls on every user request—running chain-of-thought loops, RAG pipelines, or agent workflows—you're not paying for commodity compute. You're paying for intelligence. And intelligence is expensive.

The distinction matters: Commodity compute is cheap. Cognitive compute is expensive.

If your "lazy code" is burning 1M tokens a day on chain-of-thought loops because you didn't optimize the prompt, you are burning money. I've seen startups with $50K/month LLM bills because nobody optimized the prompt engineering. And it's not just the API cost—waiting 8 seconds for GPT-4 to generate 500 lines of code destroys the developer's flow state. The real cost is the context switch, not the token fee.

The rule still applies to traditional compute. But when AI inference enters the picture, do the math again. The economics flip.

The AI Code Trap

Here's something nobody wants to admit: AI generates verbose code. It's often inefficient. It creates functions that could be shorter, loops that could be tighter, abstractions that nobody asked for.

The instinctive response: "It's still cheaper to pay for the extra RAM than to fix it." And for runtime costs, that's usually true.

But that's not the real cost.

The real cost is complexity debt. AI writes a 500-line function that should be 50 lines. That function doesn't just use more RAM—it takes 10x longer for the next developer to understand. It has 10x more surface area for bugs. It's 10x harder to modify when requirements change.

I've written about how AI coding assistants have no memory and why LLMs have no intent. They optimize for plausibility, not maintainability. The code compiles. It passes tests. And six months later, someone spends three days debugging a hallucinated edge case buried in line 347 of a function that should have been five lines.

Here's the brutal math:

It's cheaper to buy RAM than to "optimize" AI code. But it's not cheaper to debug a hallucinating 500-line function that should have been 5 lines. The sloppy code ships fast. Then it bankrupts you slowly in maintenance hours.

Developer time is more valuable than ever. Most compute is cheaper than ever. The gap is widening—but the exceptions are growing too.

What I Tell Junior Developers

When someone shows me beautifully optimized code for something that doesn't need optimization, I share what that engineer told me. Then I add:

• Measure first. Don't optimize based on intuition. Profile the code. Find the actual bottleneck.
• Optimize last. Make it work, make it right, then make it fast—if you need to.
• Question the premise. Before optimizing, ask if the code even needs to be faster.
• Value your time. Your hours are worth more than CPU cycles. Spend them wisely.
• Check your Token Tax. If an API call runs inside a loop, the "computers are cheap" rule is suspended. Optimize that immediately.

The best optimization is often the one you don't do.

"Computers are cheap and getting cheaper. Good developers are expensive and getting more expensive."