Skip to content
Tech News
← Back to articles

Protect your shed

read original get Shed Security Lock → more articles
Why This Matters

This article highlights the importance of side projects in developing engineering skills that are crucial for managing large-scale enterprise systems. It emphasizes that the foundational work of design, testing, and planning learned through personal projects translates directly into professional success, especially when working with complex, scalable infrastructure. For both consumers and the tech industry, fostering hands-on experience outside of formal work can lead to more robust, innovative solutions at scale.

Key Takeaways

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.

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.

I’ve always told younger developers that maintaining side projects will do more for your career than any amount of interview prep and LeetCode will.

Learning the physics of scale#

Early on, what stands out is how much of the work isn’t actually writing code. There are design documents, test plans, architecture reviews. It can feel like the actual building part is a fraction of the job.

But that surrounding work is what makes the building possible at scale. When you’re processing the volume of transactions a major bank handles, you can’t skip the design phase or cut corners on testing. Each of those steps exists because someone before you learned the hard way what happens 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 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.

... continue reading