I’m Matt Cockayne. I’ve been building software for about twenty years, most of it in the middle of things: the frameworks, the release pipelines, the GPU clusters, the bits that have to work before anyone else can do the interesting part. For a good chunk of that I was also leading the people building them.
In my own time it’s Go and Rust, in an open-source estate that’s grown well past where it started. Release trust is still a big part of it (when you ship something, can anyone prove it came from you?), but these days it sits next to config, messaging and the plumbing a long-running service needs, and tools for making video and sorting photographs. There’s an AI dungeon master that talks back, too, though that one’s a product of its own rather than open source.
The rule
The site’s motto is the whole of it: always leave the codebase better than you found it.
That’s the Boy Scout Rule, and I take it more literally than most people do, because I met it somewhere other than a book. It’s not about grand refactors. It’s the small, cumulative discipline of leaving the campsite tidier than you found it, applied to a function, a module, a pipeline, a team. Do it for long enough and you stop being able to walk past things.
It’s also the reason so much of what I build is plumbing. Somebody has to pick up the litter.
Where the name came from
I was a Cub as a kid, in a small town in the north-east of Scotland, and I loved it. Years later I went back to it as an adult volunteer, because I wanted my children to have the same thing and, if I’m honest, because I wanted some of it back myself. I ended up spending about a decade of evenings and weekends as a leader, mostly with Cubs and Scouts.
It taught me more about mentoring, and about the sheer range of ways people learn, than any job has. It also taught me that a weak leadership team makes volunteering miserable and a strong one makes it joyful, which turns out to be true of engineering departments too.
I stepped back some years ago, when the time simply wasn’t there any more. I don’t rule out going back.
The handle itself was a gift. Around 2015 I was climbing out of a company collapse and a fairly comprehensive burnout, and a friend from the PHP community who’d talked me back into writing code suggested I give a conference talk about the Boy Scout Rule, on the grounds that I’d been a Scout Leader for years and clearly couldn’t stop mentioning it. The name stuck to me, and eventually to everything else. I’ve written about that before.
So: yes, the PHP is real. It’s where the name came from, not where it stopped.
Where the PHP went
I’ve been the boss of my own consultancy and the chief architect for over a hundred engineers, and sat in most of the seats in between. Running my own place is where I learned, the hard way, that I’m a much better engineer than I am a salesman. Along the way I did the technical director’s job at a development agency, and ran engineering teams at a startup and at a national research organisation.
The research organisation is the one I still talk about most. They had a team of exceptionally clever data scientists with no way at all of getting anything they’d built into production, and they’d hired me as a DevOps engineer because that’s what they thought they needed (I made a point at interview of saying I was rather more than that). So we built the engineering around them: a GPU cluster that straddled the cloud and our own hardware, the plumbing for training and serving models, and the pipelines feeding them. One machine was powerful enough that we had to sign a declaration it wouldn’t be put to military use before it was allowed into the country, which still makes me laugh. It was a big title and I was still hands-on most days, and I’m fairly sure that’s why it was the best of the lot.
Setting the technical direction for those hundred-plus engineers was a different animal. I stood up a platform team, and we started the long walk off one big legacy monolith toward smaller services that talk to each other through events and agreed contracts. I was also stepping into a role whose previous owner was still around and very well respected, which takes a bit of nerve and a fairly broad pair of shoulders (luckily I’ve got both). Work like that pays off slowly, and most of what I know about steering people comes from it.
AI has run through nearly all of it, kinda by accident. Computer vision and language tooling for clients when I ran the consultancy, that research cluster, and later the platforms underneath products that leaned on machine learning. The language work in the research team sat on the same branch of the tree today’s large language models grew from, so when coding agents arrived they weren’t a new idea to me, just a much louder version of one I already knew…
Why I climbed back down
I came down off the chief architect’s chair on purpose, and I’d make the same call again. I like leading people, and I think I’m decent at it, but the sort of leadership that slowly peels you away from the work is the sort I’ve learned to walk away from. I’d sooner lose a title than lose the keyboard! The research job had already shown me the two can live together, so my quarrel was with the distance from the craft and never with management itself. I’ve written about the ladder side of that separately.
Most of what I believe about leading people is the rule above, pointed at humans. I always treated code review as teaching first and gatekeeping a distant second. I’d rather the good habit was baked into the tooling, so you don’t have to be a hero to do the right thing on a deadline. And the thing I found most teams short of was the confidence to stop and fix the small thing nobody asked for, so a big part of the job, as I saw it, was handing that confidence out and backing people when they used it. The campsite post is the long version.
My day job now is solutions architect at an AI cloud, where I’m the technical person a handful of its biggest customers call on. That means helping them design, deploy and scale training and inference across hundreds or thousands of GPUs, and taking what they need back to the people building the product. There’s a lot more listening in it than leading, and it’s a funny sort of full circle after that research cluster… the same kind of problem, at a scale I’d have laughed at back then!
In my open-source estate the team I lead is a bit stranger: a fleet of AI coding sessions, with handovers between them, escalations when one gets stuck, and the occasional one that burns out and has to be taken off the job. A surprising amount of what I learned leading people carries straight over, including the bit where I’m not always a very good lead. The difference is that the blame is now entirely mine, which is either very freeing or slightly terrifying, depending on the day.
What I actually build
My open-source estate is a fairly large collection of Go and Rust modules, most of it extracted from two toolkits I use for everything, plus the infrastructure to sign, release and prove it. It is all public, all documented, and all built the same way, which is the only reason one person can keep it standing.
If you’re asking where my heart is, though, it’s in the things that started with a real problem in front of a real person (more often than not, me). go-tool-base is the one I’m most attached to: the framework most of the estate was pulled out of, and the first thing I reach for whatever I’m building. krites exists because my wife had four thousand wedding photos and a weekend to get through them, so it judges them on her own machine and tells her why it judged each one the way it did. keryx is the content machine behind this blog, making the covers and the reels and sending the posts out on time (most of the pictures on this site came out of it). And Scout is the AI dungeon master, which is where my D&D habit and my tooling finally collided, and it’s the one I find hardest to put down!
Underneath all of that is the stuff I’m stubborn about, which is mostly trust. Signing where the private key never leaves the key store, colophon for releases that tag the commit that actually landed, and the pipeline that builds and ships the lot. Every so often there’s something I did mainly to see if it could be done, like running FFmpeg inside a Go program with nothing to install and no temp files. And if you’re more curious about how one person keeps around a hundred and fifty repositories standing with a fleet of agents, How I work is the page for that.
The showcases have a page for each of the bigger projects, and the projects page has the lot. Start with whichever solves a problem you actually have.
Getting hold of me
The code lives on GitLab. There’s a Discord if you want to ask something, report something, or tell me I’ve got it wrong. Issues and merge requests on any of the projects are genuinely welcome, especially the ones that start “this didn’t work for me”.