Learning by building

I don't learn a technology by reading about it. I learn it by building something real, getting it wrong in a way that costs me something, and fixing it.

That's not a hobby habit that happens to sit alongside my job. It's the same method. The AI work, the infrastructure, the prototyping platform, all of it started as something I built badly at home first, on my own time and my own money, until I understood it well enough to be useful with it professionally.

If I'm recommending a technology at work, I've usually already broken it at home.

Licensed drone pilot, [A2 CofC / GVC], with Operator and Flyer IDs. The photography and video is the output; the discipline is everything that happens before takeoff.

Flying legally in the UK means airspace classes, flight restriction zones, weather minimums, battery margins and a pre-flight risk assessment every single time. The qualification isn't hard to pass, but it does force you to learn a regulated system properly instead of guessing, which is the part I found genuinely useful.

The output is aerial photography and video, mostly landscape and architecture. The kit has grown from a sub-250g starter to a proper camera platform, and my partner and children fly too, which adds an entirely different set of safety considerations.

What transfers.Planning in constrained systems. There's no improvising your way out of a restricted zone or a low battery over water, so you plan for the failure case before you commit. It's the same instinct behind gating a rollout at fifteen pages rather than running it across six hundred and hoping.

A small always-on estate at home: a 22TB NAS, an M4 Mac mini running around the clock, a private Tailscale mesh, and a stack of Docker services I use daily.

It runs media, backups, monitoring, self-hosted tools, and whatever I'm currently building. It also hosts game servers for a CS2 community I co-run, including a custom stats plugin I wrote in C# with a Node and Fastify API on Postgres behind it. That one has actual users who complain when it breaks, which is a useful kind of pressure to put on a side project.

Nothing is exposed to the open internet. Access goes through the Tailscale mesh or Cloudflare tunnels rather than open ports, which is a lesson I learned the correct way round rather than the expensive way.

• Compute
  NAS, Mac mini, spare workstation

  22TB UGREEN NAS for storage and backups, an M4 Mac mini as the always-on host, and a spare workstation earmarked as a GPU node for running local models.
• Network
  Tailscale, Cloudflare, no open ports

  A private mesh across every device including my phone, with Cloudflare tunnels where something genuinely needs to be reachable. Default posture is closed.
• Runtime
  Docker, Traefik, Postgres

  Everything containerised, routed by Traefik, with Postgres behind anything that needs state. I learned this here, understanding each piece by wiring it up myself, and later applied the same shape to the platforms I built at Zyte.
• Ops
  Documented, monitored, rebuildable

  Terminal-first tooling for monitoring and container management, tested backups, and setup documented well enough to rebuild from nothing.

The practice.Build in isolation, prove it works, then integrate. New services get stood up in a container where breaking them costs nothing, run in parallel with whatever they might replace, and only get promoted into the always-on set once they've earned it. Nothing goes straight into the path of something I rely on.

The rest is unglamorous and matters more: documented setup so I can rebuild from scratch, backups that are actually tested, and a rule that if a service can only be run by me remembering something, it isn't finished.

What transfers.This is Protozyte's architecture, honestly. Docker, Traefik, deploy on push, documented well enough to hand over. I'd been running that pattern at home for years before I built it for the company.

3D modelling and printing: mostly practical objects, mounts, brackets, fixes for things that don't have a part you can buy.

It's the most humbling of the three, because the feedback is unambiguous. A design either fits or it doesn't, and finding out takes hours rather than seconds. Tolerances, material behaviour, print orientation and support structure all have to be reasoned about before you commit, and you still get it wrong.

What transfers.Respect for iteration cost. When each cycle is cheap, iterate freely; when it's expensive, front-load the thinking. Knowing which situation you're in is most of the skill, and it's exactly the judgment behind prototyping fast in software and calibrating carefully before a full run.