Hello and welcome. As you can probably tell, my name is David Collom.
I originally started this blog because I had spent years solving problems, collecting snippets and learning lessons that were useful in the moment but easy to lose afterwards. Writing felt like a way to make those lessons useful to somebody else—and to force myself to explain what I thought I understood.
Where the curiosity started
Computers were around from a young age. One school summer holiday, my Mam—a teacher for more than 40 years—brought home a BBC Micro. It was not a polished consumer device that tried to hide how it worked. It invited experimentation.
I wrote small text applications, calculators and stories in BASIC. Most were probably terrible, but they taught me something important: a computer was not just a thing you used. It was a system you could inspect, change and persuade to do something new.
By roughly 12, I was teaching myself PHP from examples and from code shared by friends. That eventually became professional PHP and MySQL work between 2007 and 2012. The web was my entry point, but the questions pulling me forward were often underneath the application: how it was deployed, how the server was configured, why one release was safe and another was not, and why so much operational work depended on somebody remembering a checklist.
From application code to the systems around it
My early roles combined development and system administration. At Visualsoft, that meant working around an estate of more than 400 e-commerce sites while security, patching and PCI requirements remained very real constraints. The scale changed the problem. A manual action that looks harmless once becomes a source of risk when repeated hundreds of times.
At City Electrical Factors, I moved further into Ruby and Ruby on Rails. Coming from environments where third-party libraries and open source were often discouraged, the Ruby ecosystem felt enormous. There seemed to be a library, discussion or working example for almost every problem.
The attraction was not only syntax. Ruby made testing approachable and made it natural to build small tools that improved the delivery system around the main application. I found myself increasingly interested in automation rather than only feature development.
That direction led through container platforms, Mesos and Marathon, early Kubernetes adoption, cloud infrastructure, service meshes, GitOps, reliability engineering and internal developer platforms. The vocabulary changed; the underlying problem did not.
The thread I can see more clearly now
Looking back from 2026, there is a consistent thread through the work:
- make the complicated part understandable;
- remove repeated manual decisions;
- create a safer default path;
- preserve an escape hatch for the cases that genuinely differ;
- give engineers enough context to trust the automation;
- share what worked—and what failed—with the next team.
At William Hill, platform work compressed delivery that had taken weeks into hours. At Sky Betting & Gaming and Credit Karma, Kubernetes and infrastructure automation moved from an interesting technology choice to a production operating model. At Jetstack, customer platforms, custom controllers, training systems and open-source work made the human side of platform engineering impossible to ignore.
A platform can be technically elegant and still fail if developers do not understand it, trust it or find it useful. That realisation shaped the way I now describe the work: I help engineering organisations build platforms that developers love.
Why open source and community matter
The most useful parts of my career have rarely happened in isolation. They came from reading somebody else’s post, opening a pull request, asking an awkward question in a community channel, teaching a workshop or telling the honest version of an incident on stage.
That path eventually led to speaking at ArgoCon and KubeCon, contributing to open-source projects and helping organise DevOpsDays London. It also reinforced why writing matters. A polished architecture diagram shows the destination; the failure modes, trade-offs and discarded options are often where the lesson actually lives.
What this blog is for now
The original post promised tips, snippets, reviews and experiences. That still fits, but the scope is broader.
These field notes will cover Kubernetes, platform engineering, developer experience, reliability, FinOps, automation and the organisational edges where tools alone stop being enough. Some posts will be deeply technical. Others will be about careers, community, cycling or the personal systems that make difficult work sustainable.
I do not want this to become a stream of perfect answers. I would rather write about decisions with constraints, automation with failure modes, and the messy middle between an idea and something teams can rely on.
The tools will keep changing. Curiosity, empathy and a healthy dislike of unnecessary toil are likely to remain.