Building Software Outside of Work
Dev Leader Weekly 123
TL; DR:
It’s NOT required
... You probably will find value in doing it
Check out the live stream on Monday, January 19th at 7:00 PM Pacific!
Building Software Outside of Work Hours
This topic gets people weirdly emotional.
On one side, you have the crowd that treats side projects like a moral requirement. If you aren’t coding after work, you are falling behind, you don’t want it enough, and you are basically doomed. On the other side, you have people who act like building anything outside of work is automatically unhealthy, or that anyone who does it must be compensating for something.
Both extremes are missing the point.
You don’t need to build software outside of working hours to be a legitimate software engineer. Your life does not have to revolve around your job. You can love software and still want to spend your evenings with your family, at the gym, playing games, reading, or doing literally anything that has nothing to do with code. That is normal. That is healthy. And it does not make you less serious as a developer.
But if you are someone who wants to build outside of work, then we can talk about how to make it effective. Not performative. Not guilt-driven. Effective.
Because here is the reality: building outside of work can be a career accelerator, a learning tool, a confidence booster, and sometimes even a path to income. It can also be a fast track to burnout if you approach it like a second job with no boundaries. So the question is not, “Should everyone do side projects?” The question is, “What are you trying to get out of it, and does your approach actually match that goal?”
That is where people get stuck, and you can watch my Code Commute video on the topic too:
Start with the why, not the what
Most people start with, “What should I build?” and that’s the wrong first question, in my honest opinion. If you don’t know why you are building, you will pick a project that does not fit your life, does not fit your energy, and does not fit your outcomes. Then you will quit and assume you lack discipline, when really you just started with the wrong framing.
In my experience, most “why” buckets fall into four categories.
The first is skilling up in an area you are not getting to touch at work. Maybe you build backend services all day, but you want frontend experience. Maybe you have done mobile for years and want to learn web. Maybe you have been living inside one stack and you want to explore something else because you are thinking about a role change. If your workplace supports internal mobility and your manager can help you find opportunities, that is ideal. Learn on the job, get real constraints, and get paid while you do it. But if those opportunities are not there, building outside of work can fill the gap.
The second bucket is resume and portfolio material. This is especially common for junior devs, but it applies at any level when your resume feels light in a specific area. I want to be careful here though: the goal is not to create shiny projects. I have never hired someone because their side project had tons of users. The value is being able to talk about what you built, why you built it, the tradeoffs you made, what you learned, and what you would do differently. If you can’t explain it, the project does not help you. It sets you up for an awkward interview where you are basically forced to admit you do not understand your own work.
The third bucket is income or entrepreneurship. Sometimes you have a problem in your own life, you solve it, and then you realize other people might pay for it too. Sometimes you want freelance work, consulting, or a product business. This is a completely different game than learning for learning’s sake. If your goal is customers, you should optimize for shipping and reliability, not novelty. And this is where I see people shoot themselves in the foot by trying to learn an entirely new stack while also trying to build something sellable. That combo is brutal. It slows you down, increases frustration, and makes the whole thing feel like a grind.
The fourth? Well, you probably don’t need to read a newsletter article on it if your why fits into this bucket: Because you find it fun. I spent a lot of time in this bucket of building things, especially super early in my programming journey. I just liked building games and things related to games! I realize not everyone will fall into this category, and that’s totally fine. If you find yourself here, the nice thing is that you can get coverage on all three other buckets and it won’t even feel like work.
So whatever your why is, be honest about it. And don’t be afraid to change it. The mistake is pretending your goal is learning when you are actually chasing resume validation, or pretending your goal is income when you are really just curious and experimenting. Different goals demand different approaches.
Activation energy is real, NOT a character flaw
Even with a solid why, building outside of work can feel hard. Not because you are lazy, but because doing “more work” after you already worked all day is hard. That is just reality.
There is a massive difference between wanting to build because you are excited and forcing yourself to build because you feel like you should. When it feels like obligation, the activation energy is huge. You sit down, open the laptop, and suddenly cleaning your kitchen feels like a thrilling adventure.
If you want consistency, your best lever is making the starting friction lower. A simple way to do that is aligning the project with something you already care about. It does not have to be deep passion. Just enough interest that it pulls you in.
Video games are an easy example because a lot of developers already like them. If you have a favorite game, build something adjacent to it. Not a massive community tool. Something small:
A tracker
A checklist
A loot log
A build comparison tool
A stat calculator
Even something dumb and fun is fine, because the point is not the app. The point is lowering the barrier to starting.
And if you are thinking, “Yeah but I don’t care about games,” cool. Use whatever you do care about:
Fitness
Cooking
Music
Personal finance
Sports
Your hobbies are full of tiny problems that can become tiny projects. Tiny projects are what get finished. Finished projects are what create momentum.
Too many ideas? Pick one.
Some people don’t have an activation energy problem. They have an overwhelming problem. They have a list of ideas, and they cannot pick the “best” one, so they pick none.
There is no best idea. There is only the idea you actually start.
If you have ten ideas, write them down and pick one. Literally pick one. Random number generator if you need it. You will learn more by building the “wrong” project than by spending three months optimizing your decision.
Starting is a skill.
Scoping is a skill.
Finishing something small is a skill.
Those skills transfer to every other project you will ever do.
Keep most variables fixed, or risk drowning
One practical guideline that saves people a ton of pain is this: don’t make everything new at once.
If you want to learn Postgres, don’t also simultaneously learn:
a new language
a new framework
a new cloud provider
and a new deployment approach.
That’s a recipe for stalling. The more unknowns you stack, the more likely you are to hit a wall, and once you hit the wall the motivation drops fast.
Instead, pick one or two things you want to learn and keep the rest familiar.
If you are a C# developer and you want database experience, keep C# and learn Postgres.
If you want to learn Python, build a small service with a database you already know.
If you want to learn cloud deployment, keep your stack familiar and focus on the deployment pipeline.
You are trying to create a learning environment, not a chaos environment.
Match process to goal, or risk wasted effort
This is where people get lost in the sauce. They start building, they get distracted by architecture, they rewrite everything twice, they chase the perfect framework, they reorganize folders for a week, and they feel productive because they were busy. But they aren’t necessarily moving toward their goal.
... Unless your goal was practicing refactoring and system rewrites. In which case, heck yeah!
If your goal is learning, you need to slow down enough to understand what you are doing. AI tools can help, but they can also trick you into thinking you learned something when you just shipped something. If you can’t explain it, you didn’t learn it. If you are using AI, use it to ask “why” questions, explore tradeoffs, and clarify concepts. Don’t use it like a slot machine until code appears that compiles.
If your goal is resume material, focus on projects that create good stories. You want to be able to walk someone through the situation, what you built, why you chose that approach, what you struggled with, and what you learned. That is what makes a project valuable. Not the number of stars, not the number of users, not whether it looks fancy in screenshots.
If your goal is customers or income, you need to bias toward shipping and stability:
Reduce novelty.
Use known tools.
Build the smallest viable version.
Get it in front of people.
Iterate.
Don’t turn the project into an excuse to rebuild your entire identity as an engineer.
A reality check before we wrap up
Building outside of work is optional. It’s a tool. It can be a great tool. But it’s not a moral requirement and it’s not the only path to growth. You can grow by:
Taking on harder work at your job
By mentoring
By reading
By deliberate practice
By learning through reviews
By pairing with stronger engineers
AND by being intentional about the work you accept.
If you do want to build outside of work, do it intentionally. Start with the why. Keep it aligned with your life. Reduce activation energy by aligning with interests. Keep most variables fixed. Match your approach to your goal. And build small enough that you can actually finish and learn.
That is how side projects become something that improves your career and your confidence instead of something that just makes you feel guilty on a Sunday night.
Join me and other software engineers in the private Discord community!
Remember to check out my courses, including this awesome discounted bundle for C# developers:
As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.
Nick “Dev Leader” Cosentino
social@devleader.ca
Socials:
– Blog
– Dev Leader YouTube
– Follow on LinkedIn
– Dev Leader Instagram
P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!