Then there’s the backyard shed. No blueprints, no permits, no audits. You just take some wood, a saw and start banging with a hammer. It may be a little dry, and if it rains too hard the roof may leak, but you built it yourself in a single weekend.
For the last six years, my life as an engineer was divided between these two modes. Day by day, I was building the banking system at the enterprise level. By night, I was in the shed, building whatever felt like it. Side projects that sometimes went somewhere and sometimes didn’t.
It’s easy to think of these as two separate lives: the work you do for a paycheck and the work you do for fun. But looking back at this chapter of my career, I’ve realized something fundamental. Enterprise work taught me to be an engineer on a large scale, but it was the individual projects that kept me an engineer.
I always tell young developers that any preparation for interviews and maintaining side projects will be more beneficial to your career than Leetcode.
Learning the Physics of Scale#
Initially, what stands out is how much work isn’t actually writing the code. There are design documents, test plans, architecture reviews. It may feel like the actual building part is a part of the work.
But it is the work of the surroundings that makes building on a large scale possible. When you are processing the volume of transactions handled by a major bank, you cannot skip the design phase or cut back on testing. Each of those steps exists because someone before you learned the hard way what it means without it.
Working in that environment gives you access to unattainable scale. You get to work with tools like Cloud Spanner, a globally distributed, strongly consistent database that you can’t easily 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 the only employee on a huge site. You don’t often get to choose the ingredients, and you also rarely get the chance to experiment with foundation.
Taking the Blueprint Home#
The Shed is where you take the blueprints you learned on the job and get a chance to actually play with them.
In the early days, my personal projects were in disarray. If it was an idea, architecture was an afterthought. Classic shed behavior. But over time, work patterns began to bleed naturally.
You spend enough time designing systems that need to handle failure gracefully, and you start to do it on autopilot. HomeLab is probably the best example of this. What started as a container on a single machine turned into a managed cluster with automated deployment and infrastructure defined in code.
It’s like taking the structural discipline from the skyscraper and applying it to a place where I had complete freedom. Private projects stopped falling through. They were still made quickly and on my own terms, but they stuck. The venture taught me the rules of structural integrity, but the shed gave me the space to truly be an architect.
Freedom to break things#
When you’re creating for yourself, the cost of a bad decision is a ruined evening. In the workplace, choosing the wrong approach impacts real teams and real customers.
That rapid feedback loop is what makes Shade so valuable. You are the developer, reviewer, and user. You can break something down and rebuild it to see what it feels like.
I created a Game Boy Advance emulator in Go, not because the world needed it, but because I wanted to understand how the hardware worked at that level. I’ve built services using tools I would never touch at work, just to understand their tradeoffs. You can try a tool you’ve never used before without having to write a proposal for it.
Most of these experiments don’t turn into startup ideas, but they all leave something behind. A new pattern, a lesson in what not to do, a broader understanding of what is.
More than anything, the shed is where curiosity comes alive. Enterprise work is highly valuable, but it can exhaust you. Sprints get merged together, the ticket queue never goes down, and problems start getting repeated. Personal projects are where you remember making software is actually fun.
Bringing a hammer to a skyscraper#
Early in my career, I was new to containerization and cloud infrastructure, and there was a steep learning curve on the job. But because I was standing up containerized systems and running them on GCP at home on my own time, the concepts emerged quickly. I was getting representatives from both sides.
This pattern repeated throughout my career. You try something out in the shed over the weekend because you’re curious. You learn about tradeoffs, hard edges, things the docs don’t tell you. Then months later, when the team at work is evaluating the same tool or approach, you’re not starting from scratch.
Because you’ve already broken things down in your environment, already evaluated your tools, and already felt the pain points, you can come to work and make informed calls instead of guesswork.
Protect your shed#
The trap of software engineering is to think that your daily work is your entire art.
The engineer who builds only skyscrapers eventually burns out. Problems become repetitive, the process becomes stifled and the creative spark dims. You stop making things because you want to, and start making them because the business says so. You lose your edge.
Protect your personal projects at all costs. This is where your curiosity lives, where you experiment, and where you define yourself as a creator rather than just an employee. Enterprise will teach you how to write code that survives, but Shade is the one that makes sure you actually still want to write it.
<a href