There’s a tired version of the side-project story where the day job is a prison and the side thing is the escape hatch. That isn’t mine. I have a job I genuinely care about — people I like, problems bigger than I’d ever reach alone. And I still, most nights, go and build something that’s entirely my own. This is about why you’d do both when the job is good, and what it actually costs.
What a job gives you, and what it can’t
A good day job gives a lot. A team. Scope you couldn’t touch on your own. Deadlines that force a decision instead of letting you polish forever. The quiet fact that the building isn’t a personal gamble. Problems big enough to be genuinely interesting. Employed work is not a consolation prize — some of the best engineering of my life has happened inside it.
But there’s one thing a job, however good, structurally can’t hand you: total authorship. At work you own your piece, not the whole. You argue for decisions; you don’t simply make them. That’s correct — it’s how a group builds things bigger than any one person. It’s just not the same as a thing where every choice, down to what it’s called and where the comma goes, is yours and only yours.
That feeling is the whole reason for the thing on the side.
The thing on the side isn’t a hobby
Let me be honest about what counts. A side thing is only real if it’s real — not a folder of half-started ideas, but something you actually ship, that real people use, that can let a real person down. The moment it’s real, it stops being relaxation and becomes a second set of responsibilities: messages to answer, bugs to fix, a name to live up to. People picture “build your own thing” as pure freedom. It is — but it’s the freedom of being the founder, the developer, the support desk, and the janitor, all at once, usually the same evening.
I wanted that anyway. Owning the whole thing, mess included, is the point.
Where the hours come from
Nobody hands you the time; you carve it out of the edges. Early, before the day’s first obligation. Late, after it’s done. The slow quiet of a weekend morning. The work happens in the seams of a life that’s already full — most of it with a glass of tea going cold beside the keyboard while I forget it’s there.
And the boundary matters more than the hours. The job gets my real, rested attention during the day; it deserves that, and so do the people counting on it. The thing on the side gets the edges. Letting either one bleed into the other is how you end up doing both badly. Protecting the line is how you manage to do both at all.
What each one does for the other
Here’s the part I didn’t expect: they make each other better.
The discipline you learn working with other people — testing, reviewing, not shipping cowboy code at 2am because you’re tired and it probably works — is exactly what keeps a solo project from collapsing under its own ambition. And the solo project, where you own every decision, keeps a certain spark lit that even good employed work can quietly dim: the muscle of starting from nothing, naming it, and being entirely on the hook for whether it’s any good. Each one turns out to be the other’s gym.
It isn’t for everyone, and that’s fine
I don’t want to turn this into a sermon. You do not need a side project to be a real developer. Plenty of people I admire go home, close the laptop, and live a full and unhurried life — and they’re better for it. Rest is not a failure of ambition, and “always be building” is a great way to burn out and call it virtue.
But for some of us, the thing of our own isn’t really optional. It’s where a part of you lives that the job — however good, however much you care about it — simply doesn’t have room for. You keep it not to run from the day, but because something in you needs a corner that is entirely, stubbornly yours.
That’s what the thing on the side is. Mine happens at the edges of the day, over tea, and I wouldn’t trade it.