Constructing a skyscraper is a massive undertaking. You need blueprints, permits, and safety audits before the first piece of steel arrives. It requires hundreds of people coordinating over months or years. You can’t just throw up drywall and hope for the best. Then there is the backyard shed. No permits, no audits—just some timber, a saw, and the smell of cedar sawdust hitting the floor. It might be drafty, or the roof might leak, but you built it yourself in a weekend.
For the last six years, my life as an engineer has been split between these two modes. By day, I built banking systems at enterprise scale. By night, I was in the shed, building whatever I felt like. Some projects went somewhere, others just… sat there. It is easy to view these as separate lives: the work you do for a paycheck and the work you do for fun. But I’ve realized something fundamental: the enterprise work taught me how to engineer at scale, but the personal projects kept me an engineer.
I’ve always told junior devs that maintaining a side project does more for your growth than endless interview prep. You learn the physics of scale at work—things like Cloud Spanner, a database you cannot simply simulate on a laptop. You learn defensive design and failure modes because, in banking, you don’t have a choice. But that scale comes with rigidity. You are just a single worker on a massive site. You don’t get to choose the foundation.
The shed is where you take those blueprints and play. At first, my personal projects were messy—classic shed behavior. But over time, the patterns from work started bleeding in naturally. My homelab, once a single container, turned into a managed cluster with infrastructure-as-code. That’s taking the structural discipline from the skyscraper and applying it to a space where I had total freedom. The projects stopped falling over. They were still built fast, but they were finally anchored.
Actually, the best part is the speed of failure. When building for yourself, the cost of a bad decision is just a wasted Tuesday night. At work, a bad decision affects real customers. This rapid feedback loop is invaluable. I built a GBA emulator in Go once—not because the world needed one, but because I wanted to understand hardware. Most experiments don’t become startups, but they leave something behind. Maybe a new design pattern or just a better sense of what’s out there. Or maybe not; sometimes you just learn what not to do.
Earlier in my career, I was struggling with cloud infrastructure. But because I was already running containers on GCP at home, the concepts landed faster. I was getting reps in from both sides. That’s the secret. You try something in the shed on a weekend. You hit the rough edges. When the team at work eventually evaluates that same tool, you aren’t starting from zero. You’ve already felt the pain points. You make informed calls instead of guesses.
The trap is thinking your day job is the entirety of your craft. The engineer who only builds skyscrapers eventually burns out. Protect your shed at all costs. It is where your curiosity lives, and it is the only thing that ensures you actually still want to write code when Monday morning hits. Don’t let the corporate process—no matter how “efficient” it seems—stifle that.