A few days ago, a controversial tweet made me reflect. If you’re a software engineer and you don’t have some kind of side project humming along, you're leaving serious experience on the table. For some reason, people treat them like a hobby, a nice-to-have, like building Lego models or learning to knit. And sure, they can be relaxing, but they are also absolutely critical to your career health.

Honestly, think of it this way: your 9-to-5 job is the syllabus, but your side projects? That’s where you actually grind your EXP before going back to the main story. They let you step outside the sometimes stifling boundaries of corporate tech stacks and company policies. It’s where the real, messy, wonderful learning happens.

Escaping the Tech Stack Straitjacket

The biggest limitation we face at work is usually the established tech. Maybe your company is still using an ancient version of Java, or maybe they’re locked into a single cloud provider like AWS. That’s just the cost of doing business. Everything is about stability, maintenance, and keeping the lights on.

The Freedom to Fail (and Learn) Hopefully

But what about that shiny new framework, like Svelte or maybe even something weird like Elixir? You can't simply switch the entire production stack just because you think the latest thing is cool. That’s where your personal time pays off. A side project is your sandbox. It's the only place where you can:

Try something truly bleeding edge. Want to mess around with serverless functions on Google Cloud Platform? Build a little project with it. Worst case? It costs you $2, you delete the repo, and you learned three things that don’t work. That L is still a massive W.
Go full-stack, even if you’re pigeonholed. Are you a dedicated front-end enjoyers? Building a simple API in Python (maybe using Flask) and hooking up a Postgres database will teach you more about latency, security headers, and deployment than any online course ever could. You become the whole damn team, the front-end guru, the database admin, the DevOps expert.

That kind of hands-on, end-to-end perspective? It changes how you communicate with other teams at your job. You don't just ask for a feature, you understand the cost of building it.

It's Your Portfolio, Not Just Your Resume

A resume is just a static piece of paper. It claims you know TypeScript. A side project is a living, breathing demonstration of that skill. This is perhaps the most immediate, tangible benefit, especially if you're looking for a new role.

The Interview Cheat Code

When you walk into a technical interview, everyone says they’re a "problem solver." Big deal. When they ask you, "Tell me about a challenging technical decision you made," you don’t have to resort to a vague story about a work meeting. Instead, you get to say:

"On my personal finance tracking app, I initially used Firebase, but I realized the lack of granular relational queries was causing massive slowdowns on the dashboard view. So, I took a week, learned how to use Prisma, and migrated the entire data layer to a self-hosted PostgreSQL instance. The trade-off was the added DevOps complexity, but the query performance improvement was 7x."

See? That’s gold. It demonstrates judgment, ownership, and the ability to execute a difficult architectural shift. You aren't just reciting skills, you’re telling a story of execution. Make sure to always link the live application and the GitHub repo, it’s non-negotiable.

Learning to Be the Product Owner

Here’s a subtle but essential benefit that developers often miss. When you're working on an internal tool or a company product, the requirements are handed to you. Someone else decided what needs to be built.

The Secret Ingredient: Product Sense

On your own project, you're the CEO, the designer, and the janitor. This forces you to develop "product sense." You have to ask the hard questions:

Does anyone actually need this feature?
Is this UI intuitive, or am I building a slop nightmare that nobody likes?
Should I spend three days perfecting the landing page, or should I ship the core functionality first?

That ability to scope and prioritize is what separates a truly great Senior Engineer from a good one. It's not just about writing clean code, it's about writing the right code. Building your own thing teaches you discipline because every hour you spend on it is yours. It makes you a more valuable, well-rounded asset to any team you join.

So, Should I Start with A or B?

The biggest hurdle is always starting. We tend to overthink it, wanting to build the "next Instagram." Don't. Start ridiculously small. Scratch your own itch.

Build a tool that:

Automates a tedious task in your personal life (i.e., using OCR on a receipt instead of manually inputting).
Clones the core feature of a popular app (e.g., just the drag-and-drop feature from Trello, nothing else).
Solves a tiny problem for someone you know (a little dashboard for your friend’s Padel matches, maybe).

The key isn't the scale, it's the completion. Finish the thing, deploy it, and let it live on the web. The satisfaction you get from seeing your creation run in the wild, that’s the real energy source.

Your career isn’t something that happens to you, it’s something you actively build. And honestly, your side projects are the architectural blueprint and the foundation. What little piece are you going to start building this weekend?

Why Side Projects Are Non-Negotiable