For three years my job title said "senior" and my brain said "imposter."
I shipped tickets. I closed sprints. I got decent reviews. And I still couldn't have explained how half of our system actually worked, because I'd only ever touched the small corner someone handed me.
Then I built a dumb little app on a weekend, and it quietly rewired how I think about software.
A side project teaches you more than your day job because you own every layer — database, deploy, bugs, design, the lot. At work you're handed a slice; on your own thing you eat the whole stack. That end-to-end ownership is where real engineering judgment comes from. If you feel stuck despite a "good" job, build one small thing you fully control and ship it to real users.
My day job was good on paper. Stable team, clear backlog, code review, CI that mostly worked.
But here's the quiet trap: a well-run company protects you from almost everything that teaches you. Someone else owns the database. Someone else owns deploys. Someone else decided the architecture two years before you arrived.
I was a very productive passenger.
I could add a field to a form, wire it through three services, and ship it. Ask me why there were three services and I'd shrug. I knew the path through the maze. I'd never seen the maze from above.
The danger isn't that you stay junior. It's that you get paid like a senior while staying junior in the ways that matter. Comfortable. Stuck. Quietly nervous you'd be exposed. This is the same gap I keep coming back to in the brutal truth about becoming a senior developer — title and competence drifting apart.
The app itself was nothing. A tiny tool to track which books my friends and I had lent each other, because we kept losing them. A list, some auth, a database. The kind of thing you'd estimate at "a weekend."
It took three.
And in those three weekends I touched everything I'd been insulated from for three years:
Every one of those was a layer my job had quietly done for me. Owning all of them at once is a completely different sport.
At work you learn a codebase. On a side project you learn software.
Here's the shift that surprised me most. When you own everything, you stop thinking in tickets and start thinking in systems.
At my job, a slow page was "a backend ticket." On my own app, a slow page was my fault, and it could be the query, the index I forgot, the image I never compressed, the cold serverless function, or my own bad loop. I had to hold the whole chain in my head and reason across it.
That's the actual skill. Not React, not SQL, not any one tool — the ability to reason across boundaries and ask "where in this whole pipeline is the problem actually living?" It's close to what finally clicked for me when I learned system design without a CS degree: seeing the shape of the whole thing, not just one corner. Industry data backs this up — the Stack Overflow Developer Survey consistently shows the most valued engineers are the ones who own delivery end to end, not the ones who know the most frameworks.
I started bringing that to work immediately. In the next incident, instead of waiting for the "right" team, I traced the request end to end myself. I was wrong about the cause, but I was useful in a way I'd never been. People noticed.
A few months in, I'd absorbed a pile of practical instincts I now lean on every day:
| What the job taught me | What the side project taught me |
|---|---|
| How to navigate our codebase | How to design one from nothing |
| How to close a ticket | How to decide what the ticket should be |
| How to use the deploy pipeline | What a deploy pipeline is actually for |
| How to read an error in our logs | How to set up logging so errors are findable |
| How to ask the senior dev | How to be the person who answers |
Let me be specific, because "build a side project" is useless advice on its own. Here's what genuinely moved the needle.
1. Constraints teach faster than freedom. Because I had no team, I couldn't over-engineer. No room for a microservice fantasy. One small app forced me to feel the real cost of every abstraction I added, which made me ruthless about the ones I keep.
2. Real users are a different teacher than tests. My test suite was green when my friend hit a bug on his Android phone in a tunnel with bad signal. Tests check what you thought of. Users check what you didn't.
3. Shipping is a skill, separate from coding. Writing the feature was maybe 40% of the work. The rest was the boring, character-building stuff: domains, environment variables, a deploy that wouldn't, a database migration that scared me. That boring 60% is most of professional engineering, and the job had hidden it from me.
4. You learn the tools you actually choose. When someone hands you a stack, you learn it shallowly. When you pick it — and have to defend the choice to yourself at 1am — it sticks. I now understand the database I chose for that toy app better than the one I've used at work for three years.
5. A finished small thing beats an unfinished big thing. I have a graveyard of clever abandoned projects. The one that taught me everything was the boring one I actually shipped. Done is the teacher. Ambitious-and-abandoned teaches you nothing but how to feel bad.
Most side-project advice tells you to "build your passion." I think that's backwards. Build the smallest thing that forces you through the whole stack.
Here's the filter I use now:
That's it. No grand vision required. The grand vision is the trap.
If this nudged you toward building one small thing you fully own, that's the whole point — try it this month, and if you want more of these field notes on growing as an engineer, the senior-developer pillar is a good place to keep reading.
Q: Won't my employer see a side project as competition or a conflict? Check your contract, genuinely. But a tiny tool for tracking lent books is not a conflict — it's a learning exercise. Keep it unrelated to your company's domain and you're almost always fine.
Q: I have no time. How do people do this with a full-time job? You don't need much. The whole point of "smallest thing that finishes" is that it fits in the cracks. A few focused weekend hours beats a heroic all-nighter you never repeat. Protect a small, regular slot and guard it.
Q: Does the tech stack matter? Less than you think. Pick something popular enough to have good docs and move on. The transferable lessons — ownership, debugging across layers, shipping — are stack-agnostic.
Q: What if my side project fails or I abandon it? Then you abandoned it after learning the deploy and the database, which is already a win. The only true failure is the one you never start because it has to be perfect.
Q: Should I tell people about it? Yes. Putting it where someone can poke at it changes how carefully you build. A little public stakes goes a long way.
My job paid me to be a passenger. My side project made me a driver. Same brain, same hands — completely different relationship to the work.
You don't become a senior engineer by being handed bigger slices. You become one by owning a whole, small thing end to end.
If you've felt that quiet gap between your title and your confidence, you already know what I'm describing. The fix isn't another course or a bigger job. It's one tiny app you fully own, shipped to one real person, this month.
So — what's the smallest thing you could finish in three weekends? Build that one.
Leaving my job wasn't a leap of faith. It was a spreadsheet. Here's the runway math that turned a terrifying gamble into a boring, calculate…
No following, no network, no luck. Just an unglamorous system I ran for eighteen months. Here's exactly what I did.
I went from 200 to 11,000 subscribers without hiring anyone. AI didn't write my newsletter — it did everything around it.
Comments
Sign in to join the conversation
No comments yet. Be the first to share your thoughts!