Constructing a skyscraper is a massive undertaking. You need blueprints, permits, and safety audits before the first beam hits the site. It takes hundreds of people months of coordination—you can’t just toss up some drywall and pray it holds. But then there’s the backyard shed. No permits, no audits. Just you, some timber, and a saw. It might be a little drafty, or maybe the roof leaks if it rains too hard, but you built it yourself in a weekend. I can still smell the sawdust from the last time I tinkered in mine.
For years, my career felt split between these two worlds. By day, I was building banking systems at enterprise scale. By night, I was in the shed, building whatever popped into my head—some projects landed, others just sort of faded away. It’s easy to label these as separate lives, but looking back, I realize they’re codependent. The enterprise taught me how to engineer at scale, sure, but it was the personal projects that kept me an engineer. I’ve always told younger devs that maintaining a side project will do more for your career than any amount of interview prep or LeetCode grinding ever will.
Early on, you learn that professional engineering is mostly documentation, architecture reviews, and test plans. It feels like the actual building is just a fraction of the job. But when you’re handling transaction volumes for a major bank, you can’t skip the design phase. You get access to things like Cloud Spanner, which you just can’t simulate on a laptop. You learn defensive design. You learn to fear failure before you even start coding. It’s powerful, but it’s rigid. You’re just one person on a massive site. You don’t get to pick the materials, and you rarely get to experiment with the foundation. Actually, you almost never get to experiment at all.
That’s where the shed comes in. It’s where you take those professional blueprints and play with them. My early projects were messy, classic shed behavior. But over time, the patterns from work started bleeding in. The homelab is the best example—what started as one container turned into a managed cluster with automated deployments. I brought the skyscraper’s discipline into the space where I had total freedom. The projects stopped falling over. They were still built fast, on my own terms, but they were anchored. It turns out you can have both.
When you build for yourself, the cost of a bad decision is just a wasted Tuesday night. That rapid feedback loop is the real value. I built a Game Boy Advance emulator in Go, not because the world needed it, but because I wanted to understand hardware at that level. I’ve stood up services using tools I’d never touch at work. Most don’t turn into startups, but they leave behind a lesson in what *not* to do, or a new pattern to keep in your back pocket. The enterprise work is valuable, but it can wear you down—sprints blend together, the ticket queue never shrinks, and the problems feel repetitive. Sometimes, you just need to break things to remember why you started coding in the first place.
Bringing the hammer to the skyscraper works both ways. Because I was messing with containers on my own time, I was getting reps in outside of work hours. When the team later needed to evaluate a new tool, I wasn’t starting from zero. I’d already felt the pain points. I could 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 personal projects at all costs. It’s where your curiosity lives, where you define yourself as a builder rather than just an employee. The enterprise teaches you how to write code that survives, but the shed? The shed is what ensures you actually still want to write it.