Why Your Side Project Will Always Be Better Than Your Day Job
Because that's how we operate as devs
At 10:42pm on a Tuesday, you fix a bug that’s been annoying you for a week.
No code review, no Jira ticket, no deployment checklist. Just save, reload, done.
You didn’t ask anyone if this feature was valuable. You just wanted it to exist. And now it does.
The irony is that this code — the thing you wrote half-tired on a couch, with no deadlines, no standups, no budget — might be the most satisfying work you’ve done in weeks.
Meanwhile, at your actual job, progress feels like pushing glue uphill. The features are scoped by someone else, the stack is predetermined, and even small changes require navigating a bureaucratic maze of planning, sign-off, and process. You get paid more, but build less.
This isn’t just vibes. There’s real science behind why your side project feels better: you’re working with the grain of how motivation and creativity actually function — not against it.
This essay isn’t a manifesto for quitting your job. It’s an attempt to understand why side projects feel so good, why jobs so often don’t, and what that contrast says about how we structure modern engineering work.
The Science: Autonomy, Mastery, and Intrinsic Motivation
In 1985, psychologists Edward Deci and Richard Ryan introduced Self-Determination Theory, one of the most widely supported models of motivation in behavioral science. At its core, it argues that people feel most energized and engaged when three basic psychological needs are met:
Autonomy – the sense that you're in control of your own actions
Competence – the ability to get better at something that matters
Relatedness – the feeling of connection to others or a shared purpose
Most side projects hit all three. Without trying.
When you’re working on your own thing:
You choose the stack.
You decide what to build, when to ship, and when to rewrite it all from scratch.
You solve problems at your own pace, in your own order, with no one telling you it's out of scope.
And if you’re collaborating — even informally — it starts to feel like something communal, not just functional.
The autonomy is total. The competence is real. The relatedness is optional — but when it’s there, it’s intimate.
At work, even in good jobs, the dynamic shifts.
Autonomy gets narrowed: you inherit legacy systems, work within team constraints, and execute on someone else’s roadmap.
Competence becomes conditional: you grow at what the company values, not always what you do. You may become excellent at internal tools or bespoke edge cases — but less so at your own craft.
Relatedness is mediated through HR policies, Slack etiquette, and the churn of teammates leaving every quarter.
This isn’t inherently bad. It’s just structurally different. Work is a machine. Side projects are a mirror.
And when it comes to motivation, side projects line up more cleanly with how human beings are wired to stay engaged.
The irony is that many developers feel more like engineers when they're not being paid to be one. That isn’t failure. That’s design.
The Creative/Technical Flow Difference
There’s a kind of quiet intensity you fall into when something finally clicks — a bug that’s resolved, a feature that compiles, a design that just works the way you hoped it would.
It’s not excitement exactly. It’s not pride either. It’s more like... disappearance. You forget the tabs you left open. You forget you meant to go to bed an hour ago. The space between intention and result collapses — and suddenly you’re in it.
Psychologists call this flow. Mihaly Csikszentmihalyi, who coined the term, described it as “the state in which people are so involved in an activity that nothing else seems to matter.” In neurological terms, it’s associated with a temporary reduction in activity in the prefrontal cortex — the part of the brain responsible for self-criticism, time awareness, and impulse control. In other words: the part of you that second-guesses everything finally shuts up.
Most side projects invite flow almost accidentally. There’s no meeting to interrupt it. No cross-team dependency to block it. No five-person thread debating edge cases before you’ve even built the thing.
It’s just you and the work. Challenge and response. You don’t need permission. You don’t need a spec. You don’t even need to be right. You just need to be curious and not interrupted.
That’s not how employment works.
At work, you rarely get to stay in that state for more than an hour. Not because you’re not capable — but because the system isn’t designed to protect it.
You get halfway through refactoring something and then you’re in a 30-minute sprint retro about process improvements. You’ve just loaded the mental model of a bug when someone pings you to “quickly look at a metrics dashboard.” Even on a good day, flow is fragile. In most orgs, it doesn’t just break — it fractures into ten smaller tasks, each demanding a different headspace.
And the worst part? You start to internalize this. You stop expecting to go deep. You become a tab-switching operator who measures progress in completed tasks instead of solved problems. You forget what it feels like to actually sink into code.
Until you open your side project and feel it again. That quiet intensity. That strange calm. That sense of being fully engaged without needing to prove anything.
Flow isn’t magic. It’s not even rare. But it is endangered. And most jobs — by design — don’t know how to keep it alive.
Constraints in Employment vs Side Projects
People like to say that constraints breed creativity. That’s true — but only if you control the constraints.
In a side project, constraints are chosen. You might decide to use a language you’ve never touched, or limit yourself to one file, or rebuild something from scratch just to see if you’ve learned anything since last time. The constraint exists to sharpen the work — not slow it down.
At your job, constraints are handed to you like an inheritance. Not earned, not chosen — just yours now. A CI pipeline that breaks if you touch the yarn.lock. A test suite no one understands. A vendor contract that means you can’t use the good tool — only the expensive one that sort of works. Oh, and don’t forget the shared service your team depends on that hasn’t been updated in three years and throws a 500 every time you deploy on a Friday.
Work constraints aren’t guardrails. They’re baggage. Historical. Political. Sometimes legal. Almost never intentional.
And they’re not just technical. They’re social.
You can’t push an unapproved change. You can’t delete a feature even if no one uses it. You can’t ignore the product brief even if it’s wrong. You can’t just build something weird and see how it feels.
Even when you’re told you have “freedom,” it comes pre-structured — inside an OKR, inside a quarter, inside a backlog that someone else has already filled with things they think matter more.
Your side project doesn’t have those layers. There is no product owner. No architecture review. No two-week cadence that resets your momentum. You’re allowed to chase things that look useless. You’re allowed to build something just because the shape of the idea is interesting.
That freedom doesn’t always lead to brilliance. But it often leads to motion — which is where insight comes from.
In most jobs, motion has to be justified. In most side projects, it only has to be felt.
But My Side Project Isn’t “Better”
Let’s get this out of the way:
Your side project probably isn’t useful.
It doesn’t have users. It doesn’t generate revenue.
It might not even compile right now.
There’s no roadmap. No test coverage. The README is outdated. The domain name expired last year. You haven’t touched it in four months and you’re already thinking about rewriting it in a different language just for fun.
So how is this “better”?
It’s not. At least, not in the way job titles and shipping velocity and production uptime define better.
Your side project won’t pass a code audit. It won’t scale. It won’t change anything.
But here’s the thing: it’s not supposed to.
Your side project doesn’t have to meet enterprise goals. It doesn’t have to prove anything. It doesn’t need to justify its existence to a stakeholder or a sprint planner or a budget committee. It only needs to remind you of something you’ve probably forgotten:
That you’re allowed to build things without asking permission.
That not everything needs to make sense on a roadmap.
That your creativity is still intact, even if it’s out of practice.
“Better” doesn’t mean cleaner or more efficient. It means more alive. It means more yours.
And sometimes, that’s enough.
What We Can Steal Back for Our Jobs
You’re probably not going to quit. And you don’t need to.
But if your job feels like a slow erosion of the parts of you that care about building things, then the goal isn’t to escape — it’s to recover the conditions that made your side project feel alive in the first place.
No one’s going to hand you that freedom. You have to steal it.
Start with Autonomy (but smaller)
You won’t get to pick the roadmap. But you might get to carve out a weird edge case and own it completely. You might get away with writing the internal tool no one asked for but everyone uses later. You might be able to say: “I want to explore this myself before we decide.”
In orgs where autonomy is rationed, initiative is the loophole.
Shrink the Feedback Loop
Most developers suffer not from complexity, but from latency.
When you’re building your own thing, you get to test, break, and see it work — all within an hour. At work, that feedback loop is padded with ceremony.
Break it.
Merge smaller PRs.
Set up preview environments.
Build with fewer mocks.
Pair program, even temporarily, just to feel the momentum again.
If you can’t shorten the project, shorten the distance to dopamine.
Protect Flow Like a Resource
No one will defend your focus for you.
Start blocking time. Actually block it. Two hours. No meetings. No Slack. Put a calendar event on and name it something boring so people don’t ask questions.
If your team culture can’t tolerate two hours of uninterrupted work, you don’t have a time problem — you have a trust problem.
Ship Something That Isn’t Meant to Last
Not everything has to be robust, extensible, or future-proof. Once in a while, ship something quick, shitty, and useful. Skip the governance. Skip the proposal doc. Write the damn script and post it in Slack.
If it breaks, fix it. If it doesn’t, great.
If someone’s mad about it, now you have a conversation worth having.
Side Projects Aren’t Escapes. They’re Rehearsals.
You don’t build your side project to escape your job. You build it to remember what it feels like to care.
The point isn’t to replicate that feeling at work entirely. You can’t. The constraints are real, the politics are baked in, the scale is nontrivial.
But you can still borrow from the parts that work.
And if you do it enough — the autonomy, the clarity, the motion — you might end up with something rarer than a perfect side project: a day job that feels like yours.
This Isn’t Therapy. It’s Maintenance of Your Sanity.
You don’t need a rebrand. You don’t need to become a founder. You don’t need to monetize your side project or turn it into a startup or write the blog post that finally goes viral on Dev.to.
You just need to remember that the feeling you get when you build something on your own terms is real — and that it’s worth protecting.
Because work isn’t broken. And you’re not broken either. But the gap between how we build when no one’s watching, and how we build when everyone is — that gap is where burnout begins.
Your side project is a mirror. Not because it shows you what you could be doing full time, but because it shows you what it feels like to be in flow, in control, in motion. It reminds you that you still care. That you still can.
It’s not therapy. It’s maintenance. And some weeks, that’s the only thing keeping your career from calcifying into a checklist.
So yeah — your side project will probably always be better than your day job. Not because it’s useful. Not because it’s perfect. But because it’s yours.