For years I treated side projects like a second job I was failing at. 😅
I was still building. The fuel was not a trophy list. It was ideas: problems I could not drop, small "what ifs," things I wanted to exist whether or not anyone asked. Some turned into code and demos. Some stayed half-born in notes. When something did ship, I parked it on Side Projects so I could point back without turning the build into a performance. The hard part was not a lack of sparks. It was guilt. Every hour on a personal repo felt like an hour I stole from rest, from my day job, from whatever version of adulthood the noise online says you should perform.
If you have ever closed your laptop at 1 AM 🌙 and thought, this does not count, you know the feeling.
Here is the lesson that took me too long to learn: side projects add up over time even when they never become startups. Not because every repo needs a prize. Because they train skills your sprint board rarely optimizes for. ✨
What side projects teach beyond your job 🧾
At work, someone else shapes the problem, writes the ticket, and often picks the hard choices for you. That is not a knock on you. It is how real companies ship.
Side projects push you into the step before that: choosing what is worth building when no one asked, when the scope is yours, when the only deadline is your own pride. That is where you practice decisions when nothing is spelled out, the same habit that later helps when two technical options are both "fine" and someone has to pick.
You also get shipping in public if you publish the work. 📣 A private spike teaches syntax. A public repo teaches taste, communication, and the slow work of explaining your own mess.
Figure from Austin Kleon's Show Your Work!.
That book is where I first saw the learn and teach loop drawn as one circle. You learn, you share what you know, and sharing feeds the next round of learning. Austin Kleon's "show your work" idea is not about showing off. It is about letting your thinking meet real people. I wrote about why that cycle is a career catalyst for builders, and how I use it in mentorship, in this LinkedIn post.
And Guess what? The web is not fair. Polished demos can flop. Rough hacks can take off. You cannot chase likes without turning the whole thing into a second social media job. You can still chase practice reps: ship, write it down, cut scope, finish something. 🎯
What compounding means for side projects 📈
When I say compound, I do not mean every project becomes a clean story for interviews. I mean a set of skills that still help you after you stop opening the repo every week.
Spotting patterns is the big one. After you debug your own auth flow, deploy surprises, and your own "why is this slow" hunts, incidents at work start to look familiar. The details change. The shape of the problem often does not.
Knowing your tools is the quiet kind of compound interest. 🛠️ You learn a framework because a weekend idea needed it. Two years later that is not just a resume line. It is speed when the team needs a prototype, or when you read someone else's system and you actually get the constraints.
Proof you can ship matters more than people say, especially early. ✅ Not proof you are a genius. Proof you can take an idea from zero to something another person can run. That is a different signal than "I finished courses."
There is a follow-on effect too. 🤖 You can ship side projects lightning fast now: AI handles boilerplate, glue code, and first drafts so an idea can become a working thing in hours, not weeks. As that wall gets lower, the hard part moves earlier. The rare skill is not typing UI faster. It is naming the problem, picking limits, and knowing what "good enough" means for a user. Side projects are a low-risk place to grow that product sense without treating a tutorial like owning a real feature.
Product engineering is part of that same stack, and it grows fast when you build for yourself. You are the user, the scope owner, and the engineer in one loop, so tradeoffs land in your head instead of across three roles in a meeting. I wrote about why that mindset is the skill that survives when AI handles more of the code in product engineering in the AI era.
Side projects are not free ⚖️
Growth needs finish lines, not only new ideas. If every spark becomes a new foundation and nothing ships, you get the joke instead of the skills.
Strip: West Side-project story (CommitStrip, 2014).
Side projects still cost something. Sleep. 😴 Relationships. The trap of using "hustle" to skip rest. I will not tell you every engineer needs a perfect GitHub graph. That is not wellness. It is stress with a brand. 😬
The useful idea is smaller: if you already build on the side, stop treating it like a character flaw. Call it practice that stacks over time, then guard your time like a grown person. A side project that ships in six weeks with weekends intact beats a "rewrite everything" dream that eats six months of guilt.
What I would do differently 🧭
I would pick smaller scope and celebrate done more loudly. I would treat docs as part of the product, not an afterthought, because future me is also a user. 📝
I would split real learning from "learning for the feed." Some spikes stay private. Not everything needs a post. The value still lands in your head. 🧠
Most of all, I would stop forcing side projects to prove themselves in the same frame as my job. They are not copies of each other. They are different gyms. One pays your salary. The other builds more choices, speed, and confidence when you see a work problem no one filed yet.
If you are building something odd this weekend and part of you feels guilty for not "optimizing" your career, that build might already be the optimization. Ship the smallest version. Ship it. Then step away.
The compound part was never the repo. It was the person all those reps built. ✨
Originally published at souravdey.space.
Top comments (0)