It's okay to write dirty code

Many developers feel they need to write clean code. They’re good developers only if they write clean code. They’re lousy developers if they don’t.

I feel the same way too. And I try to make my code as clean as possible.

But this attempt to write clean code actually slows most of us down. We learn slower. We make fewer things. And as a result, we contribute lesser to this world.

I want to make a point that it’s okay to write dirty code. I want to give permission for myself and for you to write dirty code in this article.

When to write dirty code

There are a few occasions where its okay to write dirty code:

1. When you’re stuck
2. When you want to write good code
3. When you want to make things quickly

Point number 2 sounds contradictory yeah? We’ll get to this. Promise.

Write dirty code when you’re stuck

Any progress is better than no progress when you’re stuck. This applies to everything in life, even coding.

For example, I usually get stuck when I try to write articles. I get stuck because I censor myself. These thoughts went through my mind when I wrote this article:

1. This idea isn’t good enough
2. I shouldn’t write this way
3. What if someone sees this article and decide I’m a lousy developer?

It’s scary.

Writing dirty code is equally scary because we developers pride ourselves in writing good and clean code. We wear it like a badge of honor. If we don’t write clean code, we’re lousy developers.

We get stuck because we focus on trying to write clean code. Our ideas don’t flow.

Here’s why.

Think of thoughts like water in a tap.

1. Good ideas, good work, good writing, good code, etc is hot water.
2. Bad ideas, bad code, bad writing, bad work is cold water.

If you want thoughts to flow, you have to turn on the tap. If you censor yourself, you plug your thumb into the tap.

Try turning on the tap with your thumb plugged into it. What happens? Water gets stuck. You won’t be able to let any of your thoughts flow.

If you want to make anything worthwhile, you need to stop censoring yourself. This begins the creation process. It lets water flow.

Next, when you turn on the tap, cold water will invariably come out first. It doesn’t matter how long you’ve turned the heater up for. This is because cold water already ready to come out. Hot water only comes after cold water empties.

You have to let your bad ideas out first because good ideas don’t come until all the bad ones are gone.

1. You don’t come to work with good ideas.
2. You don’t stare at a screen and hopefully know how to code

Good ideas surface as you work. They surface only if you stop censoring yourself.

Want to guess how I came up with this cold water/hot water analogy?

I started writing this article with “I am censoring myself right now…“. Look at what you’re reading now. You’re not even halfway done, and you want to read more. Yes? :)

Let’s continue.

Write dirty code when you want to write good code

How can you write dirty code to write good code? This sounds contradictory.

But its the truth.

Good code comes from bad code. Just like how good writing comes from bad writing.

You can blurt out your thoughts (without editing) an put in on your blog. This is easy. But it’ll be bad writing. It’ll contain all sorts of irrelevant information.

Good writing comes from refining bad writing. It’s called editing. It’s where we slash and burn anything that doesn’t help us deliver the message we want to deliver.

Good code comes from editing too. Except we call this process refactoring: Changing code the way its written without affecting its behavior.

You have to write bad code to get the creative juices flowing. Then you have to edit your bad code so others can understand it.

This process takes time. It requires patience.

When you want to make things quickly.

Developers have this habit of adding features we don’t need into our code. For example:

1. We put code into functions when we don’t have to.
2. We write OOP or FP or other programming paradigms when we don’t have to.
3. We use map/filter/reduce when its easier to write a for loop.

In these three examples, I only talked about using different JavaScript features when we’re writing code.

We often add for more complexity than we need to when we make things. For example, when I made a countdown timer for the Learn JavaScript sales page, I added timezone support for every timezone in the world… even though I only needed PST.

I did this because I wanted to release the countdown timer as a library for others. But I never released it anyway. I spent hours researching about timezones while there are more pressing items on my todo-list.

It’s okay to write bad code at first. It prevents you from overengineering things. It helps you make things faster.

How to write good code (consistently and quickly)

Essentially the process of writing good code boils down to:

1. Write bad code
2. Don’t censor yourself when you write bad code
3. Refactor when you’re done writing bad code

The refactoring process is critical if you want to write good code consistently and quickly. It rewires your brain. You’ll see how you can write better code from the get-go without going through the uber-lousy code in the first place. You’ll also learn to spot what good code looks like.

Wrapping up

If you want to write good code, we need to write bad code first. Let the lousyness pour out of you, and the good ones will follow.

It’s risky. It’s scary. But it’s what we have to do.

Writing this article gave me permission to write dirty code (and also to publish dirty code). I hope it gave you the permission to write dirty code too.

Here’s to making better things by writing shitty code first. 🍻.