Six Years of Building Things

I've been thinking recently about just how much stuff I actually do.

Not in the "look at my incredible productivity" sense. I don't particularly think of myself as productive. Most of the time I'm just doing whatever happens to be in front of me. There's a bug to fix, something I want to redesign, documentation that needs writing, a project I've suddenly become interested in, or some technical question that has been bothering me for long enough that I eventually decide to investigate it properly.

It's only when I stop and look backwards that the amount of it becomes slightly ridiculous.

I've been writing software for years. I maintain websites and open source projects, run my own infrastructure, build tools and SDKs, experiment with protocols, write about what I'm doing, and generally find increasingly elaborate ways of occupying my time with computers.

None of this was some carefully planned career trajectory.

It just accumulated.

I've always been interested in computers

I've been interested in computers for as long as I can remember. Scratch was probably my first real exposure to the idea that I could tell a computer what to do rather than simply use whatever someone else had made. In secondary school I also had things like an RC car and a little robot, and I was fascinated by the fact that code could make something physical respond to you.

So this isn't really a story about somebody who suddenly discovered computers and decided to learn programming. I was already that child.

What I didn't particularly like was being taught IT.

I dropped the mandatory GCSE IT course because I found it monotonous and repetitive. I didn't hate computers. I hated being bored by computers.

College wasn't originally the plan

I went to college in 2021 through the SEN department, initially doing Employability Skills Levels 1 and 2. My original plan had actually been to do A-Level English Language, but my mum pushed me towards IT instead.

I was put straight into Level 2 because I already had enough experience to skip Level 1. From 2023 onwards I moved into the IT course, eventually completing the OCR Cambridge Technicals in Information Technology in 2026. Level 3 was split across two years and two tiers, so I didn't do every possible Level 3 unit.

I was one of the stronger students when it came to the practical side of things and quizzes, even if that didn't necessarily translate directly into every test. I got a distinction in Unit 1 of Level 3, and one of my teachers had seen my GitHub, so they generally left me alone unless I actually needed clarification on the practical work.

In that sense, college gave formal structure to something I was already doing.

The important distinction is that I didn't start programming because I went to college. The serious programming came first.

It started with a worm

The point where programming really became a serious interest was summer 2020.

I wanted to make a computer worm.

Not because I wanted to destroy anything. I was fascinated by the idea behind things like Creeper and Reaper: software that could replicate itself and move between systems. I wanted to understand how that actually worked.

I started with Python, using CodeWithMosh's one-hour Python course as my introduction. The worm itself stopped being particularly important. The curiosity didn't.

Once I had started learning how programs worked, I kept finding another layer underneath. Networking led to protocols. Protocols led to systems. Systems led to infrastructure. Eventually I was writing software simply because I wanted to understand whatever I had become interested in.

That's still more or less how I work.

I see something interesting and want to understand it, and one of the ways I understand things is by trying to build them myself.

Curiosity became the method

If I want to understand an SDK, I might write one.

That's essentially what happened with Wolfram, my AT Protocol SDK and infrastructure work. Rather than just consuming someone else's implementation, I wanted to understand the underlying system well enough to build my own.

The same thing happened with the AT Protocol itself. I ended up running my own PDS, working on things like ATperson and MetalBear, and gradually building up a collection of software around the protocol.

It isn't always the most efficient way to learn something. It is, however, remarkably effective at leaving me with a lot of software.

The pattern is fairly consistent: learn something, build something, discover another thing I don't understand, investigate that, then build something else.

A lot of those projects are related

Some of my projects look completely unrelated if you only look at their names.

They aren't.

Malachite grew out of my frustration with having years of listening history spread across services like Last.fm and Spotify. I wanted that data represented as AT Protocol records that I could actually control. It was also my first genuinely major public project alongside my website, and, honestly, I created it out of spite. If a service is going to trap years of my own data behind its walls, apparently my response is to write software to get it out.

Inkwell took that same interest in open infrastructure in a different direction. It's a native reader and writer for Standard.site on AT Protocol, letting me read, discover, subscribe to and publish long-form writing from my own account and PDS rather than handing everything over to another platform.

It's also one of the projects where I care most about the details. OAuth storage, rate limiting, input handling, link verification, release integrity, accessibility, testing and platform differences all become part of the software rather than things to worry about later.

I use Inkwell myself constantly, which makes it rather difficult to hide from its problems. If something annoys me, I encounter it again. If something breaks, I notice. If the interface is awkward, I have to live with it.

AI is part of how I work on that now, but it doesn't replace the engineering. I use it to investigate things I might have missed, generate possible implementations and help work through problems. I still decide what the software should do, review what gets written, understand the systems involved and expect the resulting code to meet my standards.

Then there's croft.click, which is probably the clearest example of those individual projects starting to become an ecosystem of their own.

It brings together my AT Protocol tools rather than leaving them as a collection of unrelated repositories. Malachite, Bismuth, Opal, Jasper, Hasharium and Tourmaline all do different things, but they share the same broader idea: moving, converting, analysing and working with data on an open social web rather than assuming every service needs to keep your data trapped inside itself.

That's increasingly what my software work looks like. Individual projects are useful on their own, but they often end up connecting to something else I've built.

My website is much the same. It's not just a place where I happen to publish things. It's an ongoing software project with its own AT Protocol architecture, interfaces, content systems and infrastructure. I've redesigned it repeatedly because, apparently, leaving a website alone is not something I'm particularly capable of doing.

I keep publishing things too

The other thing that can make the amount of work look larger in retrospect is that I tend to publish it.

There are repositories, commits, pull requests, documentation, websites, infrastructure, experiments and small tools scattered around GitHub and the wider web.

Then there's the writing.

I write about software, web design, accessibility, disability, AI-assisted development, Apple, online culture, open source, politics, corporate communication and whatever else has managed to occupy my brain for long enough.

I don't sit down and decide that I need to "produce content". Usually I have a thought, an annoyance, a project or something I've learned, and eventually it turns into a post.

The result is that a lot of the things I build leave some sort of public trace.

My GitHub looks slightly ridiculous

If you look at my GitHub profile, you get a slightly strange collection of things.

There are AT Protocol projects, Malachite, ATperson, my website, croft.click, infrastructure, smaller libraries, games, experiments and assorted tools.

And, if we're being precise about education, there's ECCL. That's the exception.

ECCL was actually built as coursework for my Cambridge Technicals: a Visual Basic/.NET 8 Windows Forms prototype for a fictional computer shop, with demo accounts, component selection, live pricing, VAT, deposits and an invoice screen.

It was also a fucking pain.

I rewrote the entire project three times, largely thanks to the joys of Windows development.

I had to use Windows for college, and I made it very clear that I hated it. The laptops certainly didn't help. Our supposedly "high-end" laptops had Intel i3 CPUs and a tonne of college bloatware smeared all over them. These weren't even old machines either, which somehow made it worse. It genuinely took about half an hour just to open Word.

Thankfully, most of the actual programming units were done on the desktop computers. Those were genuinely high-end, gaming-level machines, so at least we weren't trying to compile and run our coursework on the laptops. I rarely used the laptop at all for programming; I probably touched it about five times over the entire year.

And whenever I could avoid using the college machines altogether, I did. I'd use my Mac mini at home instead. My normal computing life was already centred around macOS, with Linux handling my servers and other machines, so being forced onto Windows for college was very much the exception rather than the rule.

So the hardware wasn't the reason I rewrote ECCL three times. The laptop experience was just an additional reminder of why I didn't particularly enjoy being forced to use Windows in the first place.

Thanks, Windows.

ECCL is basically the only repository I'd actually put in the "educational" category. The rest of my public work isn't a collection of college assignments that happened to escape onto GitHub. It's software I built because I wanted to understand something, needed something to exist, or got sufficiently annoyed by an existing problem that building my own solution seemed preferable.

Six years of building things

The timeline makes more sense when I stop treating the projects as isolated things.

There was the childhood interest in computers, then the more serious programming that started in summer 2020. College came afterwards, first through Employability Skills and then IT from 2023 to 2026. The qualification formalised some of what I already knew, but most of the software development continued to happen outside the classroom.

The projects became milestones along the way.

Wolfram represents wanting to understand a protocol deeply enough to build an SDK around it.

MetalBear and the other AT Protocol projects represent that interest growing into an ecosystem of its own.

Inkwell represents what happens when that interest meets interface design, accessibility, security and the simple desire to have a proper native application for long-form writing on AT Protocol. It's also one of the clearest examples of how I work now: build something I actually use, dogfood it constantly, find the rough edges and keep improving it.

Malachite was the first project that really felt like a major public project alongside my website. It started out of spite over my own data being scattered across services, but became a substantial piece of software and one of the things that pushed me further into AT Protocol development.

ATperson is a much stranger project, but that's part of the point. Not everything I build needs to be practical in the conventional sense.

croft.click represents the point where the individual projects started becoming a coherent public ecosystem rather than a collection of isolated repositories.

My website represents the other constant throughout all of this: an ongoing personal software project that I keep redesigning, rebuilding and experimenting with.

And then there's ECCL, the odd one out. That's the project I can point at and say, "Yes, that one really was college coursework."

There are plenty of other things that don't fit neatly into those examples too: self-hosted infrastructure, libraries, games, platform-specific experiments, documentation, deployment tooling and countless small projects that were useful for precisely as long as I needed them.

None of this was part of some six-year master plan.

I started programming in 2020 because I wanted to understand how something worked. I kept building because there was always something else I wanted to understand.

Six years later, that curiosity has left me with a body of work that is unmistakably my own: weird in places, unfinished in others, occasionally unnecessary, but built because I wanted it to exist.

I didn't follow a roadmap. I built my own.