The Difference Between Work and Side Gigs

Intro

I recently got back into the gym and the trainer advised that I need to track everything from workouts, reps, sets, progress, maybe even the damage from leg day.

So I went hunting for the perfect app. I explored what felt like all of them. Clean UI. Beautiful dashboards. Smart analytics. And then… the paywall.

All of the good ones were premium and the free ones I’m very sure in the next update will introduce subscriptions.

I respect it. Developers need to eat. Servers cost money. Features don’t build themselves. But poverty is a bastard. “Thy pocket of my garment consist of nothing but emptiness.”

So naturally, instead of paying for one, I decided: “I’ll just build my own.”

Simple, right?

Except I then spent several days procrastinating because I couldn’t settle on anything. Which stack? Mobile or web? Minimalist or overengineered? Also should it be that serious so I can sell it to my fellow gym buddies?

And that’s when it hit me.

We’ve all been there.

Usually late afternoons. You’re staring at a issue from QA that reads something like:

“Refactor validation logic for conditional asset selection when parent node is selected.”

You read it once. Twice. You sigh. You follow the instructions, stick to the company style guide, update the tests, push the branch, and move the issue from In Progress to Done.

It’s productive. It’s responsible. It pays your bills.

But here’s the uncomfortable question:

Did it actually make you better?

Compare this to a random Wednesday when you’re building something pointless and beautiful; maybe a blog no one reads, or a tiny app that solves a problem only your friend group has.

There’s no product manager. No stand-up tomorrow. No code reviews basically no one is watching.

And somehow, that’s when the magic happens.

The Comfort of Work Constraints

Work is built on guardrails. That’s not a bad thing. Guardrails keep systems from collapsing and companies from losing money.

When you’re handed a task at work, most of the heavy decisions have already been made:

• The Tools – You use the approved stack. The version. The package manager and so on.
• The Stakes – You can’t experiment too much because this code might affect a no. of users and three enterprise clients.
• The Scope – You’re solving one carefully sliced piece of a much larger puzzle.

This structure is efficient. It’s scalable. It’s safe.

But it can also be limiting.

You become very good at operating within a system. You know exactly how to navigate the codebase. You know which folder things belong in. You know which person to send a Teams message when something breaks (fyi Teams is so buggy nowadays).

It’s like being handed a detailed map every day.

The map is useful. But if you only ever follow maps, you forget how to navigate.

You never really learn what east feels like.

Side Projects

Then comes the side gig. No guardrails. No roadmap. Just a blinking cursor.

Suddenly you’re not just “the backend person” or “the frontend person.” You’re the everything person.

You’re:

• Developer
• Designer
• QA
• DevOps
• Product manager
• Marketing department
• Customer support (even if the only customer is you)

And at first? It’s chaotic.

You spend 45 minutes choosing a font. You rewrite your database schema three times. You Google something embarrassingly basic. You break everything. Twice.

But here’s what’s happening underneath that chaos: You’re learning ownership.

At work, if something breaks, there’s a process. A channel. A handoff. A ticket escalation. Someone else eventually helps carry the load.

On a side project?

It’s just you.

If it’s broken, you fix it. If it’s slow, you optimize it. If it’s ugly, you redesign it.

There’s nowhere to hide and that’s exactly why it builds depth.

The Freedom to Be “Bad”

At work, you are expected to be competent.

There are standards. Reviews. Expectations. You can’t just say, “I want to try something weird.”

In a side project, you can.

You can choose a framework just because you’re curious. You can write code that would never pass code review. I’m not recommending this though. You can refactor something three different ways just to see what feels right.

Sometimes it fails miserably. And that’s the point.

Failure in a side project isn’t expensive. It’s educational.

You finally understand why the “best practice” is a best practice and not because someone told you, but because you tried the opposite and watched it explode.

That kind of learning sticks.

Big Picture Thinking vs. Small Slices

At work, you might spend a week “fixing the login button.” It matters. It’s valuable. But it’s just a piece of the whole.

On a side project, you build the login system.

You think about:

• Where user data lives
• How authentication works
• What happens when someone forgets their password
• How it looks on mobile
• Whether anyone will even use this thing

You’re forced to think in systems, not tasks.

And once you’ve built something end-to-end, even something small, you start seeing work tickets differently.

You don’t just see “refactor validation logic.” You see how that logic affects UX, performance, maintainability, and future features.

Curiosity vs. Deadlines

Work is driven by deadlines. Side projects are mostly driven by curiosity.

Deadlines push you to finish. Curiosity pulls you to understand.

When you’re curious, your brain stays active. You’re not just trying to close a ticket; you’re trying to figure something out.

You might spend three hours diving into a concept that isn’t strictly necessary. You might watch random talks. Read documentation for fun. Experiment just because you want to know what happens.

That creates something like to sticky knowledge. The kind that doesn’t disappear after the sprint ends.

Be honest — how many issues logged on tracker from six months ago can you remember in detail?

Now think about that one side project bug that kept you up until midnight.

You remember that one because you cared.

Turning Your Passion Into a Second Job

Side projects can also become traps.

It’s easy to turn them into unpaid overtime. To start measuring them by productivity instead of joy. To compare them to startups raising millions and suddenly feel behind.

That defeats the purpose.

Your side project doesn’t need users. It doesn’t need revenue. It doesn’t need a launch plan.

It just needs to belong to you.

If it starts feeling like another manager is hovering over your shoulder — even if that manager is your own ambition — take a step back. Sometimes we can be over-ambitious.

The goal isn’t to work more hours but to work with freedom.

Finding the Balance

Work gives you:

• Discipline
• Collaboration
• Real-world constraints
• Financial stability

Side projects give you:

• Ownership
• Exploration
• Risk tolerance
• Creative stamina

You need both.

Work sharpens your reliability. Side projects sharpen your edge.

It’s like being a mech who changes oil all week — efficient, precise, dependable — but spends weekends restoring an old engine in the garage.

One pays the bills while the other builds mastery.

And sometimes, if you’re lucky, the skills from the garage start showing up in the shop.

If You’re Feeling Stuck

If work feels repetitive, it might not mean you’re in the wrong career.

It might just mean you haven’t built a playground.

Start small.

A blog. A tool for yourself. An automation script. A tiny app that solves a personal annoyance.

No pitch deck. No roadmap. No pressure.

Happy Coding!