Keeping the Fire Alive - Why Side Projects Matter for Your Career

Crack the Code game screenshot showing a code-breaking puzzle interface

Overview

There's a special kind of energy that comes from making something purely for enjoyment. In my playground project, arcadezombie.uk, I've given myself permission to create simple web games in Angular—no pressure, no deadlines, no performance reviews. Just the thrill of building something because it's fun.

In 35+ years of software engineering, I've learned something crucial: Side projects aren't a luxury. They're essential for your long-term career satisfaction and growth.

The Reality of Day Job Development

Most of us spend 40+ hours a week building software for employers. We write production code, attend meetings, manage stakeholders, and solve business problems. This work is important—it pays the bills and builds our professional reputation.

But there's a cost.

In corporate environments, you build within constraints:

  • Business requirements that might not be technically elegant
  • Deadlines that force pragmatic (not perfect) solutions
  • Technologies chosen for organisational reasons, not learning
  • Risk management that limits experimentation
  • Processes and bureaucracy that slow innovation down

You become specialised. A React engineer. A backend specialist. A DevOps person. Over years, you become very good at your narrow slice—and potentially limited outside it.

You lose the joy. The reason you got into software engineering—the pure love of building things—gets buried under sprints, standups, and stakeholder management.

Why Side Projects Change Everything

1. You Control the Direction

At work, someone else sets the priorities. Your side project is entirely yours. Want to learn Rust? Build it. Want to experiment with a new framework? Go for it. Want to build something completely impractical but technically interesting? Perfect.

This autonomy is energising. You're not solving someone else's problem—you're solving the problems that fascinate you.

2. You Can Experiment

Day job code has constraints: performance requirements, scalability concerns, security reviews, code standards. For good reason.

Side project code? Build it quick and dirty. Learn from failures without production consequences. Try architectural patterns you've always wondered about. Make mistakes in private.

The experimentation you do in side projects often pays dividends at work. You learn faster, spot patterns, and build intuition that makes you better at your day job.

3. You Keep Skills Sharp

When you specialise, other skills atrophy. If you're only writing React, your database knowledge gets rusty. If you're only backend, your CSS skills vanish.

Side projects force you to be full-stack again. You end up touching UI, backend, infrastructure, deployment. This breadth keeps you flexible and makes you a better engineer.

4. You Reconnect with Why You Started

I got into software engineering because I loved making things work. That kid who would spend hours trying to get a program to do something cool—side projects bring that back.

When you build for joy rather than paychecks, something shifts. Work stops feeling like an obligation and starts feeling like craft again.

5. You Build Your Own IP

Everything you build at work belongs to your employer (usually). Your side project belongs to you. You control it, you own it, you can commercialise it, share it, or just keep it for yourself.

This creates a sense of ownership and investment that's different from day job work.

6. You Build Your Brand

Whether you're showing side projects on GitHub, deploying them publicly, or writing about them—side projects become evidence of your capabilities. They demonstrate that you're someone who builds things, who learns, who takes initiative.

For career progression, especially into leadership, demonstrating that you're self-directed and passionate about your craft is invaluable.

My Side Projects

Over the years, I've maintained various projects. arcadezombie.uk is my current playground. It's a collection of browser-based games I build in Angular.

Recently, I've added:

  • Blocks: A puzzle game where the goal is to fit pieces together with satisfying mechanics. It explores spatial logic and game design principles.

  • Crack the Code: Inspired by classic code-breaking games, requiring logic and pattern recognition. Each puzzle is unique.

  • Hangman: Simple but teaches me about game state management and user experience.

These aren't sophisticated games. They're not meant to be. They exist to:

  • Keep me practised in Angular
  • Explore game design patterns
  • Experiment with UI/UX
  • Have fun building something complete
  • Create something people can enjoy

And they serve a practical purpose: when I'm mentoring junior engineers or discussing Angular architecture, I can point to these live examples. "Here's how I'd structure state. Here's how I handle animations. Here's real working code."

The Difference in Career Trajectory

I've noticed something over 35 years: engineers who maintain side projects tend to progress faster.

Why? They tend to be:

  • More curious: Always exploring new technologies
  • More capable: Broader skill sets, full-stack understanding
  • More confident: They've shipped code, dealt with real problems
  • More engaged: They're doing this by choice, not obligation
  • More resourceful: They've solved problems without a team
  • More disciplined: They manage time to fit projects in

These qualities matter more as you move into senior and leadership roles.

The Time Investment

The biggest objection I hear: "I don't have time for side projects."

I understand. You're busy. You have family, commitments, day jobs that demand energy.

Here's the thing: You don't need hours. You need consistency.

My side projects are maintained in 3-5 hour bursts, maybe twice a month. Not every weekend. Not a second full-time job. Just enough to:

  • Stay current with technologies
  • Experiment and learn
  • Ship something complete
  • Reconnect with the joy of building

Even 2 hours a week (roughly 100 hours/year) is enough to maintain a meaningful side project.

How to Get Started

  1. Find something that fascinates you. Not something you think you "should" build. Something that excites you enough to spend free time on it.

  2. Start small. Don't build the next Spotify. Build a simple tool, game, or utility that solves a real problem (even if it's just your problem).

  3. Commit to finishing something. Completed projects matter more than perfect incomplete ones. Finish, deploy, ship.

  4. Share it. Put it on GitHub. Deploy it live. Show it to people. The accountability helps and the feedback teaches you.

  5. Build on it. Side projects evolve. Add features, refactor, improve. This teaches you long-term maintenance—something day jobs often don't.

The Long-Term Payoff

After 35 years, I can tell you: the engineers I've worked with who maintained consistent side projects tended to:

  • Move into senior and leadership roles faster
  • Earn more (because they were more capable)
  • Feel more satisfied with their careers
  • Handle career transitions better (new skills already learned)
  • Mentor more effectively (they had recent experience with learning)

These aren't coincidences. Side projects develop characteristics that matter for career growth.

Why This Matters for Your Career

Whether you're early in your career or established:

  • Early career: Side projects help you learn faster than day job alone allows. You'll stand out.
  • Mid-career: Side projects keep you current and prevent specialisation from becoming limitation. They show leadership potential.
  • Late career: Side projects keep you engaged and relevant. They demonstrate you're still growing, still passionate about the craft.

The engineers I respect most are the ones who, at any stage of their career, are still building things for the joy of it. That's not a phase you outgrow—it's a practice that sustains a long technical career.

Start Today

You don't need perfect conditions or a great idea. You need:

  • Something that interests you
  • Permission to spend a few hours on it
  • Commitment to finish at least one small thing

Try it. Build something. Ship it. See how it feels.

The fire that brought you into software engineering doesn't have to fade. Side projects keep it alive. And that fire—that passion for building—is one of your greatest assets.

If you're curious about mine, check out arcadezombie.uk and try Blocks or Crack the Code. And if you have a side project, I'd genuinely love to hear about it. What are you building? What draws you to it? Reach out on LinkedIn—I'm always interested in what keeps other engineers fired up about their craft.