Why You Should Write 'Stupid' Code First

We've all stared at a blank editor, paralyzed by the sheer number of ways to solve a problem.

Should we use a state machine? Is this the right place for the Factory pattern? What if the requirements change next month and we need to support three different types of users?

This paralysis usually comes from trying to write the "smart" code on the first attempt.

The antidote to this paralysis is simple: Write stupid code first.

The Anatomy of Stupid Code

What does "stupid" code look like?

• It's a single, massive function.
• It uses deeply nested if/else statements instead of polymorphism.
• It has hardcoded values.
• It duplicates logic instead of abstracting it.
• It has no regard for performance (within reason).

It is, essentially, the code you would write if you only had 15 minutes to solve the problem before your laptop exploded.

Why Stupid Code Works

1. It Defeats the Blank Page

The hardest part of any task is starting. By giving yourself permission to write terrible code, you lower the barrier to entry. You bypass the critic in your brain and just get words on the screen.

2. It Clarifies the Problem Domain

Often, you don't actually understand the problem until you try to solve it. While writing your nested if/else block, you'll suddenly realize, "Oh, I need to account for users who don't have an active subscription."

If you had started by designing an elegant SubscriptionStrategy interface, you might not have discovered that edge case until much later. Stupid code forces you to confront the reality of the business logic immediately.

3. It Gives You a Baseline

Once the stupid code works, you have a baseline. You can write tests against it. Now, when you decide to refactor it into that elegant state machine, you can do so with the confidence that you aren't breaking anything.

The Crucial Second Step: Don't Leave It Stupid

This is the caveat. "Write stupid code first" is not an excuse to push garbage to production.

It's a two-step process:

1. Make it work (The stupid phase)
2. Make it right (The refactoring phase)

Once the test passes, look at the mess you've created. Now is the time to apply design patterns. Now is the time to extract functions. Because now, you know exactly what the code actually needs to do, rather than what you guessed it needed to do an hour ago.

The next time you're stuck on a feature, don't try to be clever. Just be stupid. Make it work. Then, and only then, make it smart.