# I wasted 3 years writing bad code. Here’s how I finally improved.

For the first three years of my career, I was writing code that “worked” — but barely. It got the job done, but it was messy, hard to maintain, and a nightmare for anyone else to read. Looking back, I wasn’t really writing *software*; I was duct-taping logic together until something stuck.

Here’s what changed everything.

### 1\. **I Stopped Hiding Behind StackOverflow and Started Reading Source Code**

For years, I’d copy-paste solutions without understanding them. If it worked, I moved on.

The turning point? I forced myself to dive into the source code of the libraries I was using. Instead of Googling “how to do X in NestJS,” I started asking “why does this decorator behave like that?” That shift taught me more about design patterns and best practices than any tutorial ever could.

### 2\. **I Treated Code Like a Product, Not a Puzzle**

Before, I approached problems like a hacker in a coding competition — how fast can I make this work?

Now, I ask:

* Will someone else understand this?
    
* Will *I* understand this in six months?
    
* How easy is it to test or refactor?
    

The shift came when I started thinking more like a software *architect* than a coder. Writing clean, scalable code became the goal — not just passing tests or meeting deadlines.

### 3\. **I Asked for Real Feedback (and Took It Seriously)**

Early in my career, code reviews felt like a formality. I either brushed off feedback or defended my decisions too much.

Eventually, I started actively asking senior engineers *what they’d do differently*, *why they’d change something*, and *what habits I should drop*. That humility accelerated my growth more than anything else.

### 4\. **I Started Building Outside of Work**

Side projects taught me what production-quality code really looks like — because I had to live with my decisions.

When I built my own tools and tried to make them usable by others, I learned to:

* Write better error handling
    
* Structure projects cleanly
    
* Automate tests and deployments
    
* Choose the right abstractions (not just clever ones)
    

And because no one else was reviewing my code, I had to be my own harshest critic.

### 5\. **I Learned to Read Before I Write**

Now, I study architecture patterns, read books like *Clean Code* and *The Pragmatic Programmer*, and spend time understanding existing systems before jumping in.

I used to write by instinct. Now, I write with intention.

## Final Thoughts

If you feel like you’re just "writing code that works," you probably are — and that’s okay. We’ve all been there.

The key is to stop optimizing for speed and start optimizing for clarity, reusability, and maintainability.

Bad code is a phase. But staying there? That’s a choice.

Want help leveling up your engineering skills or moving into software architecture? I’ve been there — and I’m building systems to help other devs avoid the mistakes I made. Reach out if you’re interested.