Make It Work First Before Optimizing

I once worked on a project where we spent days optimizing our database queries. We shaved milliseconds off response times. Our code was a thing of beauty. There was just one tiny problem: The core feature didn’t actually work.

Oops.

We’d gotten so caught up in making things fast that we forgot to make sure they worked in the first place. It’s a classic rookie mistake, but I’ve seen senior devs fall into this trap too.

So let’s talk about why you should focus on making your code work before worrying about making it fast.

The Siren Song of Optimization

Look, I get it. Optimization is sexy. There’s something deeply satisfying about seeing those performance metrics improve. It feels like real engineering.

Imagine walking into a meeting and saying, “I improved our algorithm efficiency by 400%.” Sounds a lot sexier than, “I made sure the ‘Submit’ button actually submits things.”

But here’s where it gets tricky:

• Premature optimization is a time sink: I once spent three days optimizing a function, only to realize later that it was called maybe once a week. Total time saved? Microseconds. Time wasted? Days.
• It can introduce new bugs: In my quest for speed, I’ve accidentally broken working code more times than I care to admit. Optimization often means making code more complex, and complexity breeds bugs.
• It can mask bigger issues: Focusing on making things fast can distract you from asking if you’re building the right thing in the first place.

Don’t get me wrong - optimization is important. But it’s like a turbocharger for your car. Really cool, but utterly useless if the engine doesn’t run in the first place.

A Tale of Two Developers

Meet Alice and Bob. They’re both tasked with building a new feature for their company’s app.

Alice dives right in. She writes messy, unoptimized code, but within a day, she has a working prototype. It’s slow, it’s clunky, but it works.

Bob, meanwhile, spends that first day researching the most efficient algorithms for the task. He meticulously plans out his data structures. His code is a marvel of efficiency… but after a week, the feature still isn’t functional.

Who do you think their boss is happier with?

The Power of Working Code

Here’s why Alice’s approach is often better:

1. Faster feedback: With a working prototype, Alice can get user feedback immediately. Maybe the feature isn’t even needed!
2. Easier debugging: It’s simpler to fix bugs in simple, straightforward code.
3. Clearer optimization targets: Once the code works, Alice can profile it to see where optimization is actually needed.
4. Motivation boost: Nothing kills motivation like spending weeks on something with no visible progress.

But What About Technical Debt?

I can hear some of you screaming, “But what about technical debt? Won’t we just have to rewrite everything later?”

Maybe. But here’s the thing: You don’t know what parts of your code will need optimization until you have a working system. Premature optimization isn’t just the root of all evil - it’s a waste of time.

This ties into a broader question: when should you actually worry about technical debt?