Ewan’s Blog

I have a Cambridge Technicals Level 3 Diploma in IT. I have been writing software since 2020. I have spent years building things, maintaining things, contributing to other people's projects, publishing packages and putting actual software on actual hardware. I have a public GitHub, a personal website and a fairly ridiculous collection of projects considering I have never actually been employed as a software developer. And I still cannot get a fucking job. Not a senior job. Not some ridiculous six-figure systems architect position where I turn up on Monday and declare that everyone else has been doing software wrong. I am trying to get my first professional software role. I have applied for at least 22 suitable software and IT jobs over the last few months. I have had zero responses. That is the part that gets me. It is not even a case of getting through interviews and being rejected at the final hurdle. In a lot of cases, I am not getting far enough for a human being to decide that I am unsuitable. The application just disappears into the machine. And yes, I know the obvious response: "You need experience." That is precisely the fucking problem. ## Entry-level, sure it is There is a very obvious circular argument in early-career hiring. You need experience to get the job. You need the job to get experience. Entry-level jobs frequently want previous experience. Junior jobs want evidence that you have already done the work. Graduate jobs want degrees, placements or internships. Employers say they want people who can hit the ground running, which makes some sense when you have an application pile hundreds of people deep, but it creates a rather absurd situation for anyone trying to enter the industry from outside the standard pipeline. At some point, "entry-level" stops meaning "a job for someone starting their career" and starts meaning "a job for someone who has already managed to start their career somewhere else." I am not uniquely struggling with this. It is a wider problem for people trying to enter industries where employers treat previous employment as a prerequisite for being employable. There are people who have done years of self-directed work, projects, freelancing, open source, college work, community work or other practical work who still get reduced to one line on a form saying that they have no "professional experience". That phrase matters because I do not actually have no experience. I have no professional employment experience. Those are not the same thing. ## I have experience. I just don't have professional employment. Take Wolfram. I wanted to work with the AT Protocol from C, and there wasn't an option. So I built one. It is a C/C++ SDK and foundation for working with AT Protocol. It deals with protocol structures, generated clients, repositories, streaming, identity resolution, OAuth, DPoP, validation, moderation, persistence, XRPC and the awkward bits that appear when you are trying to make all of that work across multiple environments. It has releases. It has tests. It has CI. It has documentation. It is software that other software can actually use. Then there is Cobalt, a native Bluesky client for the Wii U. It is not a mock-up. It is not a screenshot of a hypothetical application. It runs on an actual Wii U, with a native TV and GamePad interface, authentication, persistent encrypted sessions, timelines, threads, images, alt text, searches, feeds, lists, muting and blocking. I built an OAuth flow around Wolfram because the client needed one. Indigo is a separate native client for the 3DS. It is not simply "Cobalt but smaller"; it has its own architecture and constraints, host tests, sanitizers, warnings-as-errors and testing against a real PDS and real hardware limitations. Platinum is a Classic Mac OS 9 Bluesky client, with a C89 client and a Node bridge. It is not released because I have not done the hardware verification I would want before calling it finished. That distinction matters to me. I have also contributed to other people's projects. I have worked in codebases I did not write. I have had to understand somebody else's structure, work within somebody else's assumptions and make changes without having the luxury of simply rewriting everything to suit myself. I built Malachite, an importer for bringing Last.fm and Spotify history into AT Protocol, and it has handled over 100,000 records. I built reusable packages around the work too, including @ewanc26/tid, a small package for AT Protocol TIDs which is used by my own projects and by MultiScrobbler. This is not me saying I am secretly a senior software engineer and the industry is too stupid to recognise me. There are absolutely things I have not experienced professionally. I have not spent years in a commercial engineering team. I have not had a manager assigning me tickets every morning. I have not spent months in somebody else's code review culture. I have not had to maintain a production service while eight other departments are simultaneously changing requirements underneath me. I am aware of the gap. I am not pretending the gap does not exist. The problem is that the missing piece is exactly the piece I am trying to obtain. Somebody needs to give me the first professional opportunity. ## I build this stuff because I want to help people There is another thing that makes this particularly strange. I do not generally build software because I am trying to turn every line of code into money. I build things because I want them to exist. Sometimes that means making something useful that somebody else has not bothered to make. Sometimes it means taking a ridiculous piece of hardware and getting it onto the internet because I thought it would be funny and technically interesting. Sometimes it means writing an abstraction because three different projects need the same thing. Sometimes it means fixing something because it annoyed me. I have support links. I have places where people can support the work. But that is what they are: support links. They are not a subscription wall and they are not "pay us £9.99 a month to keep using the software". I have seen enough of the modern software industry to be deeply suspicious of the idea that every useful thing should immediately become a revenue opportunity. That is how you end up with software that gets progressively worse because someone has discovered that removing a useful feature can be monetised. I don't want to build things that way. Inkwell is a good example. It costs roughly £3 as a one-off purchase through the official app stores. There is no recurring subscription. I made something, people can buy it if they want it, and then I leave them alone. The point of all of this is not that I am nobly refusing to make money. It is that my motivations for building software are not particularly well aligned with the assumptions embedded in a lot of commercial hiring systems. I have spent years doing real development without having a company sitting over me saying "this counts as work because we gave you a payslip". Apparently that distinction is enormous. ## I didn't stop just because nobody was paying me This is probably the part that makes the whole thing feel most absurd from my side. On 17 April 2026, I had emergency brain surgery to completely replace a ventriculoperitoneal shunt that had been in my head for seventeen years. That meant a new shunt valve, which felt fucking weird after having the old one for most of my life, stitches in my head and another surgical wound on my stomach from the distal catheter. My sleep schedule was completely fucked afterwards and recovery was not exactly a relaxing little break. I was still working on my software projects. Not because I had a manager expecting a deliverable. Not because I was being paid. Not because my mortgage depended on getting a release out on Tuesday. Because I wanted to. The Git history shows it. On 21 April I was working on Jasper's import system, including daily chunking, resumable imports, persistent state, progress tracking and file-hash verification. On 22 and 23 April I was working on AT Protocol document and Markdown conversion, facet handling and package dependencies. On 27 April I was dealing with Spark story and video importing, including blob uploads, record creation, deduplication and OAuth scopes. On 28 April there was more work across Malachite, Jasper and the web frontends, including extracting shared UI into @ewanc26/landing-ui and fixing browser and deployment issues. Then 1 May came around. Beltane. I started Opal, a migration and conversion tool for moving microblogging data from services including Twitter, Mastodon, Threads and Nostr into Bluesky. It grew into a real system with publishing, rate limiting, browser OAuth, an import wizard, parser rewrites and threading for long posts. I was also dealing with the wonderfully glamorous reality of getting the thing built and deployed properly: build ordering, browser-safe libraries, Vercel serverless timeouts and the usual collection of things that only appear once software has to actually run. Some of that work is deployed through Vercel, including projects under domains such as jasper.croft.click, malachite.croft.click and opal.croft.click. Again, none of that makes me professionally experienced. But it does make the phrase "has no experience" rather misleading. The missing part is much narrower than that. Nobody has employed me to do it yet. ## The qualification isn't the problem. The gate is. This is what makes the piece of paper so frustrating. I spent years in college. I now have an IT qualification. I have a public body of software work behind it. I have written low-level C. I have written TypeScript, Rust and Python. I have built services. I have worked with APIs and identity systems. I have dealt with OAuth, deployment, persistence, networking, packaging, testing and cross-platform constraints. And yet the piece of paper often seems to function less as evidence of what I can do and more as another field to tick before somebody decides whether to look at anything else. That is backwards. The same thing happens with "professional experience", where the definition quietly becomes "having already been hired by somebody else". That is not measuring technical ability. It is measuring whether another employer has already taken the risk. There is a difference. A hiring manager can quite reasonably want evidence that I can work in a team. They can want code review experience. They can ask whether I can take direction, communicate clearly, work to somebody else's requirements or maintain software I did not design myself. Those are legitimate questions. But there needs to be some route by which a person gets to demonstrate those things for the first time. Otherwise the gate just stays closed. ## The commercial software world feels fucking geriatric I do not mean that the people in it are literally old. I mean the assumptions can feel ancient. There is this persistent model of employability where the important things are the institution you came through, the company that previously employed you, the job title you held, the number of years you have spent doing that title and whether your previous employer happens to use the technologies currently listed on the advert. Meanwhile, the modern internet makes it entirely possible for one person to build and publish software used by people they have never met. I can put source code online. I can publish a package. I can deploy a service. I can contribute to another project. I can build something for a platform that effectively stopped receiving first-party support years ago. I can publish the whole history publicly so somebody can inspect what I actually did. And yet the hiring system can still look at all of that and ask whether I have "commercial experience". There are obviously reasons employers use that filter. They have limited time. They receive too many applications. Nobody wants to manually investigate every Git repository ever created. But at some point, the convenience of the filter becomes the problem. It is easier to ask whether I worked for a recognised company than to inspect whether I can actually build software. It is easier to count years than to look at what those years contained. It is easier to reject someone for lacking a particular credential than to decide whether their actual work demonstrates equivalent ability. So I end up with the same answer again and again: I need experience, except the experience that counts is specifically the experience that comes from having already been employed. That leaves me stuck in exactly the same place where I started. ## Most of the evidence is sitting in public That is why I find this particularly difficult to square with the idea that I am somehow an unknown quantity. My work is not hidden. My GitHub profile exists. My website exists. The repositories exist. The commits exist. The release history exists. The package publications exist. The deployment history exists. The documentation exists. People involved with the ecosystem I work in have seen the work. I have multiple current and former Bluesky employees following me on the platform, including Bryan Newbold, one of the people behind the original AT Protocol specification. That does not mean they have endorsed me, and it certainly does not turn my GitHub account into a job reference. It does, however, make the idea that I am completely detached from the technical community I work in rather harder to take seriously. And this is not really just about me. There are plenty of people whose actual abilities are obscured by the way hiring systems reduce a person to a chronology: school, college, university, employer, employer, employer. That works reasonably well if your life happened to follow the expected route. It works a lot less well if you learned independently, built things outside employment, had health problems, changed direction, could not afford unpaid internships, did not go to university, came through further education instead of the conventional academic pipeline, or simply failed to get that first opportunity at the right time. The system then tells you to get experience, while making the lack of experience the reason you cannot get it. ## "Just get any job" is not actually an answer There is also the rather exhausting assumption that if the career you actually want is difficult to enter, you can simply go and do some other job temporarily. I can't fucking do manual labour. I can't stack shelves. I am semi-paralysed and have virtually no dexterity in my right hand. That is not a minor inconvenience when somebody's solution to unemployment is "just get any job". A huge amount of the supposedly obvious fallback work available to someone without professional experience is physical work: retail, warehouse work, hospitality, stock handling, cleaning, delivery, whatever happens to be hiring locally. Those jobs are not interchangeable with sitting at a computer and writing software. And that matters to hiring because it removes one of the safety nets people casually assume exists. If I cannot get a software job, I cannot simply go and spend six months doing physically demanding work and then come back to software with some money and a shiny new line on my CV. I have to find work that I can actually physically do. My disability constrains the pool of jobs available to me before an employer has even started assessing whether I am qualified. That means the usual employment advice creates a particularly stupid loop. I am being told that I need professional experience to get into software, while one of the standard ways of "getting any experience" is through work that I may not physically be able to do. At the same time, the field I am actually capable of working in is the field where I am being told I need experience before I can enter it. Then there is the chronic illness side of it. Employment is not just a question of whether you technically can perform a task. It is whether you can sustain the hours, the commute, the physical demands and the predictability that a particular job expects. Those things vary enormously between people. Software engineering happens to be work where my limitations are much less of a barrier. I can spend hours debugging a C program. I can design an API, write a parser, investigate a deployment failure or maintain a package. I can do serious technical work from a computer. That should make software a fairly obvious direction for me. Instead, I am still being filtered by the fact that I have not previously been employed to do the thing I am capable of doing. And this is where disability becomes directly relevant to the hiring problem rather than merely being another fact about my life. A non-disabled person who cannot get their first software job may at least have more freedom to take an unrelated job temporarily, build up savings, gain workplace experience and keep applying. That route is not equally available to me. My options are constrained by what my body can actually do. I am not asking an employer to ignore that. I am looking for work where it is not a fundamental barrier to doing the job. There is a rather important difference between "I need reasonable accommodations to do this job" and "I cannot do this job". The fact that I cannot stack shelves does not mean I cannot write software. The fact that I have limited dexterity in one hand does not stop me designing systems. The fact that my health affects my energy and predictability does not erase years of technical ability. If anything, that makes the insistence on professional experience even more frustrating. The work I am actually equipped to do is the work I am trying to enter, while some of the supposedly obvious alternatives are not realistic options in the first place. And even leaving disability aside, taking an unrelated job does not solve the original problem. If I spend a year doing something completely unrelated to software, I still have no software employment experience at the end of it. I have simply spent a year being employed at something else. That might be perfectly reasonable advice for someone who needs immediate income and can physically do the job. It is not a magic solution to the experience paradox. ## I am not trying to skip the beginning I am not asking to be treated as if I have already spent ten years working in industry. I want the beginning. I want the first professional code review where somebody tells me that the way I approached something is wrong and I have to fix it. I want to work in a team. I want somebody else's requirements to constrain the architecture. I want to maintain a codebase where I did not write the original design. I want to learn how other engineers work and, ideally, become useful to them. Those things are exactly why I am applying for junior and entry-level work rather than pretending that a pile of GitHub repositories makes me senior. But there is a point where "you need more experience" stops being useful advice and starts being a closed loop. I have spent years building software on my own, I already have an IT qualification, I have contributed to other people's projects, I deploy things, I publish packages and I work on real systems. I can keep producing more evidence, but there comes a point where the only additional experience that would satisfy the filter is employment itself. That is the part I cannot manufacture in isolation. And no, I am not going to university just so I can spend the next several years slogging through another qualification and maybe, eventually, get a software job by the time I am twenty-six or something. A degree can be the right choice for plenty of people. Formal education has value. I am not claiming otherwise. But "go to university" cannot be the automatic answer to "why can't this person get their first software job?" when the person in question is already writing substantial software. I have already spent years learning this stuff. I already have an IT qualification. I already have a substantial body of practical work. I do not want another five-year holding pattern where I acquire more credentials purely so somebody might finally decide that I am allowed to start my career. At some point, the answer has to be that I should be allowed to start working. ## What the fuck am I supposed to do with the piece of paper? That is what keeps coming back to me. What the fuck am I supposed to do with the piece of paper if the piece of paper cannot even get me through the first gate? I know a qualification is not a magic key. I know employers have legitimate reasons for filtering applications. I know that open-source work is not automatically equivalent to commercial experience. I know there are things I still need to learn. None of that changes the basic problem. I have spent years building software because I wanted to. I have done it through college, through difficult periods of my life, through serious health problems, and through the complete absence of anybody paying me to do it. I have built libraries and clients and importers and services. I have contributed to projects I did not start. I have shipped things. I have broken things and fixed them. I have dealt with tests and build systems and deployment failures and strange hardware and stupid bugs and all the other tedious shit that comes with actually making software. The only "job" I have ever had is occasional help for my mum in her dog breeding business. There is no software company secretly buried somewhere in my CV that I have forgotten to mention. The reason I do not have professional software experience is not that I spent years refusing to work. It is that I have been trying to get the opportunity to work professionally and nobody has given it to me yet. That is the Sisyphean part. Every application becomes another attempt to push the same fucking boulder uphill. Every rejection, when there is one, tells you that you were not quite right. Every non-response tells you even less. You alter the CV, adjust the wording, apply to something else, submit another application, and the same wall is still there. I am not asking the hiring system to pretend I have already done the job. I am asking it to recognise that someone can be capable of doing a job before another employer has decided to pay them for it. Those are supposed to be different questions. Right now, they often seem to be the same one. And that leaves me sitting here with a qualification, years of software development behind me, a public record of the work, and a pile of applications that have gone nowhere, wondering the same thing I started with: What the fuck am I supposed to do with the piece of paper?

Samhain is in 25 days, and I've found myself thinking about Sabbat celebrations rather more than usual. I'm not oblivious to the fact that this is essentially me looking at the Wheel of the Year and going “can I please have one fucking Sabbat where I'm not recovering from something, celebrating a completely unrelated family holiday, or in hospital?” I know how that sounds. I'm still allowed to be a bit miserable about it. I spent Beltane recovering. I spent Litha celebrating Father's Day, which, fair enough. I'm not going to complain about spending time with my dad because the Summer Solstice happened to fall around the same time. Then Mabon came around while I was in hospital, and that one hurt. I couldn't really mark it at all, and nobody even noticed. I don't mean that as a criticism of anyone around me. Most of the people in my life aren't Pagan. Why would they know that Mabon was happening, let alone know that I'd normally want to do something for it? I don't expect my family and friends to suddenly acquire a Pagan calendar and start checking whether I'm available for the equinox. But when you're already feeling incredibly lonely celebrating your religion by yourself, having one of the Sabbats pass while you're stuck in hospital and having absolutely nobody notice is a particularly shit feeling. So yes, I'm feeling sorry for myself. I'm also self-aware enough to know that I'm feeling sorry for myself. Those things aren't mutually exclusive. ## I don't need validation. I want company. I'm not looking for a crowd of people to tell me that my religion is legitimate. I don't need a festival to prove that my gods exist, and I'm not particularly interested in finding some perfectly homogeneous Pagan community where everyone believes exactly what I believe. Paganism is far too diverse for that to be realistic anyway. I'm Hellenic-Celtic in my own practice. Selene is important to me. I have my own relationship with the seasonal cycle, with the symbols I wear, with the traditions I've adopted and the mythology that has stuck with me. None of that becomes more legitimate because somebody else agrees with me. But that doesn't mean I don't want other people around. There's a difference between needing somebody to validate your faith and simply wanting somebody to share it with. I want someone else to know what Beltane, Litha, Mabon or Samhain actually means without me having to explain the entire concept first. I want to be able to say “Happy Mabon” to someone and have them understand why I'm saying it. I want to share food, ritual, music, stories and whatever other nonsense happens when you put a bunch of Pagans in the same place. I'd love to sit around a fire with people whose practices are completely different from mine and still have that shared understanding of why we're there. I want the ritual, the food, the music, the conversations that somehow continue until two in the morning, the inevitable person who has brought far too much camping equipment, and the general chaos that comes from putting a bunch of Pagans in a field together for a weekend. I want to actually experience Paganism as a community rather than primarily as something I do by myself. ## That's probably why Samhain is getting to me Samhain being 25 days away makes all of this rather more noticeable. I'm going to celebrate it somehow. Of course I am. I don't need a festival ticket and a hundred other people to celebrate Samhain, and I'll figure out something that works for me. But I really, really want the other version. I want to be somewhere outside after dark, surrounded by people, with a fire burning and the year properly turning towards winter. I want to take part in a ritual rather than read about one. I want to talk to people who don't need the entire concept of a Sabbat explained to them. I want to eat something ridiculous at an unreasonable hour and end up talking about mythology with somebody I've known for half a day. I'd probably be awkward as fuck when I arrived. That's basically guaranteed. I'd spend at least some of the first few hours wondering whether I'm somehow doing everything wrong while everyone else appears to have magically received the social rulebook. But I'd still rather have that than another Sabbat where I do my little solitary ritual, pack everything away and go back to normal life without having spoken to another Pagan. And honestly, maybe there doesn't need to be some deeper point to this. I'm lonely. I want to go to a Pagan festival. I've spent Beltane recovering, Litha celebrating Father's Day, and Mabon in hospital, and now Samhain is coming up. After the year I've had, I think I'm allowed to feel a little sorry for myself about that. I just want to celebrate something with other people.

Slàinte, Restore, and you too, Reform.

I wanted to shove Bluesky onto ridiculous hardware.

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.