Why You Must Protect Your Shed: The Engineering Secret
Constructing a skyscraper is a massive undertaking. You need architectural blueprints, council permits, and safety audits before the first piece of steel is even ordered. It requires hundreds of people coordinating over months or years. You can’t just throw up some drywall and hope the building holds weight. Then there is the backyard shed. No blueprints, no permits, no audits. You just grab some timber, a saw, and start hammering. It might be a little drafty, and the roof might leak if it rains too hard, but you built it yourself in a single weekend. Honestly, balancing these two worlds—the enterprise skyscraper and the personal shed—is the secret to career longevity for any serious developer.
For the last six years, my life as an engineer was split between these two modes. By day, I was building banking systems at enterprise scale. By night, I was in the shed, building whatever I felt like. Side projects that sometimes went somewhere and sometimes didn’t. It is easy to view these as two separate lives: the work you do for a paycheck and the work you do for fun. But looking back on this chapter of my career, I’ve realised something fundamental. The enterprise work taught me how to engineer at scale, but it was the personal projects that kept me an engineer.
Maintaining side projects will do more for your career than any amount of interview prep or LeetCode will.
Working in that enterprise environment gives you access to unattainable scale. You get to work with tools like Cloud Spanner, a globally distributed, strongly consistent database that you simply cannot simulate on a laptop. You learn defensive design. You start thinking about failure modes before you think about features. But that scale comes with a cost: rigidity. You are a single worker on a massive site. You don’t often get to choose the materials, and you rarely get to experiment with the foundation. This is where you must protect your shed, because it is the only place where the architectural rules you learned at work can be safely broken and rearranged.
When you’re building for yourself, the cost of a bad decision is a wasted evening. At work, choosing the wrong approach affects real teams and real customers. That rapid feedback loop is what makes the shed so valuable. You are the developer, the reviewer, and the user. You can tear something down and rebuild it just to see how it feels. I built a Game Boy Advance emulator in Go not because the world needed one, but because I wanted to understand how hardware works at that level. I’ve stood up services using tools I’d never touch at work just to understand their tradeoffs. That is how you keep your professional edge.
The trap of software engineering is thinking that your day job is the entirety of your craft. The engineer who only builds skyscrapers eventually burns out. The problems become repetitive, the process becomes suffocating, and the creative spark starts to dim. You stop building things because you want to, and start building them because the business says so. Protect your personal projects at all costs. It is where your curiosity lives, where you experiment, and where you define yourself as a builder rather than just an employee. The enterprise will teach you how to write code that survives, but the shed is what ensures you actually still want to write it.