Why I Stopped Writing Messy Code (And You Should Too!)

It's Tuesday afternoon. I'm staring at my computer screen, feeling really frustrated. Our website's shopping cart is broken, and customers are complaining. I'm looking at code that looks like complete nonsense.

The worst part? I wrote this code myself just three weeks ago.*

---

Hey there! If you've ever written code before, you probably know this feeling. You write something, then come back to it later and think "What was I even thinking?"

I've been building websites for 10 years now, and I've learned something super important: writing clean code isn't about showing off. It's about not wanting to quit your job when you have to fix something you wrote months ago.

Let me share some simple tips that completely changed how I write code (and how I feel about my work).

Stop Writing Code Like It's a Secret Message

Here's some JavaScript I wrote back in 2016. It's pretty embarrassing:

```javascript

const p = fetch('/api/users');

p.then(r => {

if(r.ok) {

r.json().then(d => {

const f = d.filter(u => u.a && u.s === 'active');

updateList(f);

});

}

});

```

What does this even do? I have no idea! Back then, I thought using short names like `p`, `r`, and `d` made me look smart. Really, I was just making life harder for everyone (including myself).

Here's how I'd write the same thing today:

```javascript

const usersRequest = fetch('/api/users');

usersRequest.then(response => {

if(response.ok) {

response.json().then(users => {

const activeAdmins = users.filter(user => user.isAdmin && user.status === 'active');

updateUserList(activeAdmins);

});

}

});

```

Yes, it's longer. But when I'm trying to fix bugs late at night, I can actually understand what's happening!

Same thing with CSS. Instead of weird names like `.btn-sm-pr`, I now use `.button-small-primary`. My files are bigger, but my headaches are way smaller.

Do Everything the Same Way

Imagine joining a team where everyone does things differently.

This happened to me last year. We had:

- Three different ways to show dates

- Some people used tabs, others used spaces (people actually fight about this!)

- One person wrote camelCase, another used snake_case

- Every part of the website handled errors differently

My brain was always confused. "Wait, how do we do loading spinners in THIS part of the site?" I'd wonder while looking at completely different code.

The fix is simple: pick one way to do things and use it everywhere. I don't care if you like single quotes or double quotes. Just pick one and stick with it everywhere.

When our team finally made everything the same, the confusion went away. We stopped thinking "how should I write this?" and just wrote code.

Write Notes for Your Future Self

I used to think comments were for beginners. "Good code explains itself," I'd say while writing the most confusing stuff ever.

Then I'd look at that same code months later and have no clue what I was thinking.

Now I write comments like I'm leaving notes for myself after a really long day. Because that's exactly who will read them.

Bad comment:

```css

.header {

margin-top: 267px; /* adds space */

}

```

Good comment:

```css

.header {

margin-top: 267px;

/* This matches the big banner image height exactly.

If the marketing team changes the image, this will break. */

}

```

Last month, I found a comment I wrote two years ago: "Don't change this math — it fixes a weird iPhone Safari bug." That comment saved me from breaking our payment page!

My best comments usually start with:

- "This looks weird but..."

- "WARNING: This breaks if..."

- "Sorry about this mess..."

- "Special case: When users..."

Make Each Part Do One Thing

When I first started with React, I built huge components that tried to do everything:

- Get data from different places

- Handle big forms

- Process payments

- Do fancy animations

- Clean up all the data

- Manage who could see what

These giant components were impossible to fix, impossible to test, and impossible to use anywhere else. When I needed something similar, I'd copy and paste code, making even more problems.

Now I follow the "one job rule." Each component should do one clear thing. If I can't explain what a component does in one sentence, it's doing too much.

Instead of one huge `UserDashboard` component, I now have:

- `UserProfile` (shows user info)

- `ActivityFeed` (shows what they did)

- `NotificationPanel` (handles alerts)

- `SettingsMenu` (manages their settings)

Each piece has one clear job. When something breaks, I know exactly where to look.

Keep Your Folders Simple

If you think for more than a few seconds about where to put new code, your folders are too complicated.

I once worked on a project with folders like:

```

/components

/containers

/utilities

/helpers

/services

/managers

/handlers

/processors

/adapters

/transformers

```

I spent 10 minutes trying to figure out where to put a function that formats phone numbers. Was it a utility? A helper? A transformer? Who knows!

Now I keep it super simple:

```

/components (all the website pieces)

/hooks (shared React stuff)

/services (talking to other websites)

/utils (helper functions)

/assets (images, fonts, etc.)

/styles (how things look)

```

That's it. If I can't quickly decide where something goes, I've made things too hard.

Find the Right Balance

There's a sweet spot between code that barely works and spending forever making everything perfect.

When I was younger, I wrote messy code that worked for demos but caused weeks of problems later. Then I went too far the other way and spent way too much time building "perfect" systems for features that got canceled.

Now I try to write code that's:

- Clean enough that I can fix it when it breaks

- Simple enough that my teammates can understand it

- Flexible enough to handle changes

- But not so fancy that simple updates become huge projects

Some things are worth doing right from the start:

- Using clear names for everything

- Breaking big components into smaller pieces

- Adding comments for confusing parts

- Making everyone write code the same way

But I've learned to stop building crazy systems for problems I don't have yet. That "what if we need to support 20 languages?" thinking can waste tons of time.

Real Results I've Seen

These aren't just nice ideas — I've seen real benefits:

On my current team:

- New people become useful in their first week instead of their first month

- We fix bugs twice as fast

- Nobody freaks out when asked to change old code

- We stopped having "let's just start over" conversations

On my last project:

We started with scary code that everyone was afraid to touch. As we slowly cleaned it up, our team got twice as fast at building new features. Not because we got smarter, but because we stopped fighting our own code.

The code became helpful instead of something that got in our way.

Start Small Today

You don't need to fix everything at once. Pick one small thing and make it better today.

Maybe:

- Give better names to some confusing variables

- Move duplicate code into one shared function

- Add helpful comments to that weird fix everyone keeps breaking

- Split one big component into two smaller ones

Small changes add up fast. After a few weeks of steady improvements, you'll notice that working with your code feels different. Less frustrating. More predictable. Actually fun!

The Main Point

Clean code isn't about following rules or impressing people. It's about being nice to whoever has to work with your code later — usually that's you or your teammates.

Every time you write a clear name, add a helpful comment, or break up a messy function, you're making someone's day easier. Usually, that someone is you, months from now, trying to fix a bug on a Friday afternoon.

Your future self will thank you.

---

*What's the messiest code situation you've ever dealt with? Share your stories in the comments — we've all been there!*

If you want tools to help keep your code clean, check out this [Code Snippet Cleaner & Formatter](https://www.webutilitylabs.com/p/tool-1-code-snippet-cleaner-formatter.html) — it helps avoid those "tabs vs spaces" arguments.