I do have experience. I have years of it. I have written software, built applications, developed libraries, implemented protocols, worked with unfamiliar programming languages, targeted hardware that is older than I am, published open-source projects, maintained packages, investigated bugs, written tests, dealt with build systems, and built things that other people actually use.
What I don't have is the particular kind of experience employers seem to recognise: a previous employer who paid me to do it.
And apparently, that distinction is everything.
I have been writing software since 2020. I have repositories with actual code, documentation, tests, release histories, dependencies, users and ongoing maintenance. I've built a native Bluesky client for the Wii U, another for the 3DS, an AT Protocol SDK in C23, a Personal Data Server, an iOS and Android application, and a frankly ridiculous collection of smaller tools and libraries.
My website alone has accumulated 1,955 commits authored by me since February 2024. That includes maintenance, documentation, merges and all the other work involved in keeping a project alive. It isn't 1,955 shiny new features, but it is a rather substantial record of actually working on software.
I'm not trying to claim that this makes me a senior engineer. I'm trying to explain that I'm not somebody who has just discovered programming and decided to apply for a job.
I'm trying to get into professional software development. I've been applying for suitable software and IT roles, and I've previously written about submitting at least 22 applications over several months without receiving a single response. I wrote about that experience in What the Fuck Am I Supposed to Do With the Piece of Paper?.
Not a rejection. Not an interview. Nothing.
I keep running into the same wall: employers want professional experience, and I cannot get professional experience without somebody first giving me the opportunity to gain it.
At what point does that stop being a reasonable recruitment requirement and start being a self-perpetuating barrier?
I do have qualifications. Here's the paperwork.
I want to be clear about my education, because the shorthand version doesn't really capture the journey.
I am not a university graduate. I didn't take the conventional route. I went to college in 2021 through the SEN department, initially studying Employability Skills. 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.
I have, however, completed a sequence of recognised qualifications, culminating in a Level 3 Cambridge Technical Diploma in IT, specialising in Application Development.
My original GCSE results were in 2021:
GCSE English Language: Grade 2.
GCSE English Literature: Grade 3.
GCSE Mathematics: Grade 2.
GCSE Biology: Grade 4.
GCSE French Language: Grade 5 (Merit).
I was very depressed at the time, and I didn't revise as a result. Those were the grades I came away with.
I subsequently retook English Language and Mathematics:
June 2023: AQA GCSE English Language, grade 5, with a Merit in Spoken Language.
June 2023: Pearson Edexcel GCSE Mathematics, grade 3.
November 2025: Pearson Edexcel GCSE Mathematics, grade 4.
The rest of my qualifications document the progression from Employability Skills into IT:
7 July 2022: City & Guilds Level 1 Extended Certificate in Employability Skills.
1 July 2024: OCR Level 2 Cambridge Technical Diploma in IT, Pass.
8 January 2025: OCR Level 3 Cambridge Technical Unit 1, Fundamentals of IT — Distinction.
10 January 2025: OCR Level 3 Cambridge Technical Unit 2, Global Information — Pass.
27 June 2025: OCR Level 3 Cambridge Technical Introductory Diploma in IT (Application Developer), Pass.
14 January 2026: OCR Level 3 Cambridge Technical Unit 3, Cyber Security — R (Near-Pass).
24 June 2026: OCR Level 3 Cambridge Technical Diploma in IT (Application Developer), overall qualification grade Pass Pass.
Those are not estimates from memory. The qualification titles, dates and results are taken from my certificates or otherwise confirmed by me.
The Mathematics result is worth spelling out. I received a grade 2 in my original GCSEs in 2021, a grade 3 in June 2023, and eventually a grade 4 in November 2025. English Language went from a grade 2 in 2021 to a grade 5 in 2023.
Across five years, I sat eight Mathematics exams.
Eight exams. Five years.
And I achieved it in psychosis. Somehow.
I fully expected to fail.
That is the part I don't want to gloss over. I wasn't going into these exams confident that everything would work out. I genuinely expected to fail. I was dealing with psychosis, trying to keep up with education, and struggling to see how I was supposed to get through it.
And yet, here are the results.
I don't want that reduced to a neat little story about perseverance. I don't want to pretend that I simply believed in myself and worked hard enough. I expected to fail, and I was dealing with circumstances that made completing the work and sitting the exams exceptionally difficult.
Somehow, I got through them.
Eight Maths exams. Five years. Psychosis. And I still came out with the qualification.
One episode. One mark. Again.
My Level 3 Cambridge Technical Diploma was a two-year course. The first-year and second-year examinations weren't all sat together, and that distinction matters.
In January 2025, during Year 1, I sat:
Unit 1 — Fundamentals of IT: Distinction.
Unit 2 — Global Information: Pass.
I achieved a Distinction and a Pass in my first year. Those are results I am happy to have earned.
The following year was different.
The psychosis that affected my November 2025 Mathematics resit was the exact same episode that was still affecting me when I sat my Year 2 Cyber Security exam in January 2026. These weren't two unrelated periods of illness. It was the same episode extending across both examinations.
My Mathematics result improved to a grade 4, finally getting me the GCSE pass I'd spent years trying to achieve. But that result doesn't tell you what state I was in when I sat the exam.
Then came Cyber Security.
On 14 January 2026, I sat OCR Cambridge Technical Unit 3 while still experiencing that same episode of psychosis.
My result was R — Near-Pass.
I am fairly sure I scored 21 out of 60. I don't have the raw-mark statement in front of me, so I won't pretend that the 21 is independently confirmed. But OCR's January 2026 Cambridge Technicals raw-mark grade boundaries make the significance clear: the Pass boundary for Unit 3: Cyber Security was 22 marks. The Near-Pass band ran from 15 to 21.
If my recollection is correct, I was literally one mark away.
One fucking mark.
It felt like Mathematics all over again. Another exam, another occasion where I came incredibly close to the next boundary, another result that left me thinking about how little separated me from the grade I wanted.
There is an important technical distinction here, though. OCR's R grade isn't the same as an unclassified result. It is a formal Near-Pass grade for externally assessed Level 3 Cambridge Technical units. OCR explains the grading in its Cambridge Technicals grade scales guidance. A Near-Pass can contribute towards the overall qualification, subject to the qualification's other requirements.
For a 60-guided-learning-hour unit, an R contributes 12 points towards the qualification, compared with 14 for a Pass. That's covered in OCR's guidance on calculating Cambridge Technicals grades and its Level 3 Cambridge Technicals in IT Diplomas Handbook. My Cyber Security result therefore contributed towards the overall diploma rather than disqualifying me from it.
And I did receive the full Level 3 Diploma in IT, with an overall grade of Pass Pass.
I stopped chasing Merits.
Something changed after that Cyber Security result.
I remember genuinely deciding that I wasn't going to keep focusing on getting Merits. I just wanted Pass marks.
I had spent so much time trying to get through examinations and qualifications while seriously unwell. I had experienced the same psychosis across my Mathematics resit and the Cyber Security examination. I had expected to fail, and then I had come away one mark short of a Pass in a subject I was studying as part of my IT diploma.
At that point, my priorities changed.
I wasn't particularly interested in chasing higher grades anymore. I wanted to finish. I wanted to get the qualification. I wanted to get through the remaining work and come out the other side with something I could actually use.
There is a difference between not being capable of achieving a Merit and deciding that pursuing one is no longer the priority. I had already achieved a Distinction in Unit 1. I knew I could do well. But I also knew what I was dealing with, and I needed to get through the course.
My final diploma grade was Pass Pass.
That is the qualification I earned. I am not going to apologise for it, or pretend I should have achieved something higher under circumstances that were anything but ordinary.
I wanted to pass. I passed.
The rest of the journey
The IT qualifications show a progression from Level 2 into Level 3, and then from the introductory diploma into the full diploma. The final qualification is specifically in Application Development. It isn't a degree, and I am not claiming that it is one. But it is a legitimate, regulated Level 3 technical qualification.
I also spent years working towards these qualifications while dealing with circumstances that made the usual expectations around education considerably harder to meet.
In April 2026, my shunt failed catastrophically. The tubing snapped. I needed emergency brain surgery on 17 April.
Two weeks later, I was expected back in the IT classroom, with a shaved head and visible surgical scars. I was given only another three weeks to rush through outstanding work across three units.
And this is where I need to talk about the course manager.
The year before, she had already gone off at me over what she considered "low" attendance and punctuality. Those figures were around 85–90%.
I find that particularly difficult to accept when I consider what I'd actually achieved: I finished Level 3 Year 1 a whole fucking month early.
I had completed the year's work ahead of schedule. I had achieved a Distinction in Unit 1 and a Pass in Unit 2. Yet somehow, the conversation was still about my attendance and punctuality percentages, as though those numbers told the whole story of my commitment to the course.
They didn't.
I don't care if someone has been in the job for 20 years. That is no excuse for blatantly ignoring the fact that I'd finished the year a month early. Experience in a role doesn't excuse a failure to consider context, and it certainly doesn't make it acceptable to reduce a student's circumstances to an attendance percentage.
And the meeting itself didn't simply upset me. It caused me to have a mental breakdown in the support hub.
I genuinely ended up hysterically cry-laughing because I couldn't believe what had just happened. I was so utterly incredulous at how blatantly disrespectful I felt I'd been treated that I couldn't process it normally. It was one of those moments where the absurdity of the situation became almost impossible to comprehend.
I had completed the year's work a month early. I'd passed my examinations. I'd demonstrated that I was capable of progressing through the course. And I was still being made to feel as though an attendance and punctuality figure of 85–90% somehow invalidated all of that.
I couldn't believe it. I still struggle to believe it.
It took my shunt failing, emergency brain surgery and the events of April 2026 for the impact of my chronic illness to be properly acknowledged.
That is what makes the earlier treatment so frustrating. I'd already demonstrated that I could complete my work, and complete it ahead of schedule. I shouldn't have needed to go through catastrophic medical circumstances before that was taken seriously.
I still completed the diploma.
That is part of my education, too. It isn't an excuse, and I am not asking for a qualification I didn't earn. It is context for the route I took to earn it.
And, for the record, I was already writing software before any of these qualifications. My software engineering experience didn't begin when I enrolled on an IT course.
I have been building things for longer than my GitHub history suggests.
There is a rather inconvenient problem with using GitHub as a complete record of my development history: it isn't one.
Pretty much all of my software from before 2024 has disappeared.
I wasn't using GitHub or another code forge at the time. I didn't have the habit of pushing every project into a repository, maintaining public commit histories or preserving every experiment in a place where somebody could inspect it years later. A lot of that work simply hasn't survived.
That means there's a gap between how long I've actually been writing software and how far back my surviving public repositories go.
I've been writing software since 2020. That is still true, even when I can't produce a neat GitHub link for every project I worked on in those early years.
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 somebody else had made. I was fascinated by the idea that code could make something respond to you.
The point where programming 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. The worm itself stopped being particularly important. The curiosity didn't.
Once I'd 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'd become interested in.
That's still more or less how I work.
I see something interesting and want to understand it. One of the ways I understand things is by trying to build them myself.
I wrote more about the history of those six years in Six Years of Building Things.
The one substantial piece of my earlier history that really has survived is my website.
Its first version appeared on Neocities on 31 May 2023. I registered my own domain, ewancroft.uk, on 9 January 2024. From there, the site went through a number of iterations: I moved it to Hugo, hosted it on GitHub Pages, and eventually rebuilt it into the more dynamic website it is today. The current design is version 13. You can see it at ewancroft.uk.
That website has outlived the early projects that surrounded it. It is a surviving record of me building and maintaining something on the web, learning how to publish it, taking ownership of a domain and repeatedly reworking the way I build and present it.
It also makes the distinction between my actual history and my available evidence rather important.
A missing repository isn't proof that a project never existed. A lack of public commits in 2021 or 2022 doesn't mean I wasn't learning, experimenting or writing code. It means I wasn't preserving that work in the way I do now.
I wish I'd kept more of it. I'd love to be able to look back at those projects, inspect the code and show people how my work developed. But I can't conjure up source code that no longer exists.
My GitHub profile is a record of the work I've preserved and published there. It isn't a complete biography of every time I opened an editor and built something.
I have built actual software.
Let's talk about the work that has survived and that I can show.
Cobalt: Bluesky on a Wii U
Cobalt was my first ever Wii U homebrew project.
I wanted to shove Bluesky onto ridiculous hardware.
That was pretty much the original idea. I had a discontinued Nintendo console, an AT Protocol SDK I was already building, and the slightly stupid thought that it would be funny if Bluesky ran on a Wii U.
It turned into a rather more involved engineering project.
Cobalt is a native Bluesky client written in C, built for the Wii U using SDL2 and the devkitPro/WUT ecosystem. It has to contend with the actual constraints of that hardware: the GamePad, the TV output, input handling, networking, TLS, rendering, memory, image decoding and the platform's own quirks.
It isn't a web page in a browser. It isn't a modern application running on a hidden computer somewhere. It's software written for a Wii U.
There isn't Electron hiding underneath it, there isn't a browser quietly taking care of the unpleasant bits, and there isn't a modern runtime doing the work for me. It's C, SDL2, libcurl, Wolfram, devkitPro and WUT, running in a Wii U homebrew environment.
And then there are two screens.
The GamePad and television aren't just two copies of the same display. They have different sizes, different input methods and different jobs. I've had to think about D-pad navigation, separate layouts, rendering, networking, authentication, image handling, caching and error handling.
The current repository documents timelines, threads, posting, images, alt text, feeds, search, profiles, notifications, follows, likes, reposts and moderation-related functionality.
I bent a Wii U's processors to my will.
That sentence is a joke, but the engineering behind it isn't.
I also wrote about the project in Cobalt: I Put Bluesky on a Wii U.
Indigo: doing it again on the 3DS
Indigo was my first Nintendo 3DS homebrew project.
It isn't simply Cobalt transplanted onto another console. The 3DS has a different platform, different libraries, different hardware, two screens, different input mechanisms and a different rendering environment. Indigo has its own architecture using libctru, citro2d and citro3d.
Its repository documents host-side unit tests, warnings-as-errors, snapshot renderer checks, AddressSanitizer and UndefinedBehaviourSanitizer testing. The documented test suite contains 2,949 checks with zero failures. Its service integration and sign-in flows have also been verified in the Azahar emulator.
I want to be precise: emulator verification isn't the same as testing on a physical 3DS. I am not claiming that it has been validated on real hardware.
But it is still a substantial native software project. It involves working with a platform that has its own constraints, its own SDK and its own development workflow.
Wolfram: building an AT Protocol SDK in C
Wolfram was my first C SDK.
It is an implementation of AT Protocol client-side and wire-level foundations, written primarily in C23. It isn't a thin C wrapper around somebody else's SDK. I've implemented the protocol machinery myself.
That includes XRPC, OAuth, PKCE, DPoP, token handling, DID and handle resolution, cryptographic signing and verification, DAG-CBOR, CIDs, CAR files, repository operations, firehose and Jetstream subscriptions, Lexicon-generated clients and runtime validation.
The generated client code and runtime library are pure C23. The optional Lexicon generator uses C++23 during development, but it isn't linked into the runtime library.
The README documents hundreds of Lexicon documents and hundreds of query and procedure definitions supported by the generated client infrastructure.
This isn't a clone of the entire AT Protocol server ecosystem. I'm not claiming to have independently reproduced every PDS, AppView or Ozone component. It is a client-side protocol implementation with optional server infrastructure.
There is a significant difference between saying that and claiming to have rebuilt the entire protocol stack.
The point is that I've been working at the level of protocol specifications, data formats, cryptography, networking, generated code and low-level language interoperability.
That is software engineering.
MetalBear: putting Wolfram to work
MetalBear was the first project to use Wolfram.
It is an AT Protocol Personal Data Server built primarily in C23, with isolated C++ modules. It depends on Wolfram for protocol functionality rather than reimplementing that foundation inside the server.
That means maintaining a relationship between two substantial codebases: the SDK and the server built on top of it. It involves integration, build configuration, dependency management, protocol correctness and the engineering decisions involved in making separate components work together.
I didn't just write a library and leave it on a shelf. I built something that uses it.
MetalBear also has its own OAuth authorisation server, federation functionality, account management, repository operations, firehose support and the infrastructure needed to run a PDS. It is a real service, not just a collection of functions that happens to compile.
I've also put effort into making the running service describe itself properly. Its operator.json endpoint exposes machine-readable information about the instance, including its software version, capabilities, contact details and build information. The public website consumes the same underlying configuration, so I don't have two separate places to maintain the same information.
That sort of operational detail matters to me. Software doesn't stop being software once it compiles.
Inkwell: native applications on iOS and Android
Inkwell was my first iOS and Android application with a shared Kotlin Multiplatform core.
The iOS application uses SwiftUI. The Android application uses Kotlin and Compose. The shared core handles the common functionality, including content conversion, Markdown parsing, facet handling, data models and Standard.site record handling over AT Protocol.
This isn't a website wrapped in two application shells. It is a cross-platform application with native interfaces and shared application logic.
It also meant learning and working with a different ecosystem: Kotlin Multiplatform, SwiftUI, Android's UI toolkit, mobile application architecture and platform-specific integration.
There is a lot more to a mobile application than putting a few buttons on a screen. Authentication, data handling, content conversion, input validation, accessibility, release integrity and platform differences all become part of the software rather than things to worry about later.
I use Inkwell myself, 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.
Packages and software other people use
I also maintain a collection of packages in pkgs.
One example is @ewanc26/tid, a zero-dependency TypeScript package for generating AT Protocol TIDs: the 13-character, lexicographically sortable record keys used by the protocol.
This isn't just a package I wrote because I wanted another repository on my GitHub profile. I originally wanted it for Malachite. It was a practical requirement for a project I was already building, so I extracted the functionality into a package that could be maintained and reused independently.
It's since been adopted by Multi-Scrobbler, where it is listed as a runtime dependency. Its maintainer replaced their own TID-generation implementation with the package.
That is a concrete example of software I wrote becoming a dependency in somebody else's project.
I also maintain projects such as Malachite, Jasper, Opal and Tourmaline. They are part of a wider ecosystem of tools built around music listening data, scrobbling, importing, photography and AT Protocol integration.
These aren't disconnected tutorial exercises. They're projects with their own requirements, users, bugs, release cycles and maintenance responsibilities.
Platinum: still building
Platinum is an attempt to bring a Bluesky client to Classic Mac OS 9.
It is written for a very different environment from the one most developers work in today. It involves C89, old Macintosh APIs, limited resources and the challenge of making a modern network service work on a retro machine.
I am not going to pretend it is finished. It is still early and unreleased. The bridge works, while the native client and the move towards removing the modern bridge are ongoing. The repository is explicit about what is implemented and what isn't.
But unfinished work still demonstrates engineering experience. Researching platform constraints, building the architecture, implementing features and discovering what doesn't work are all part of software development.
I don't need to pretend every project is complete to demonstrate that I know how to build software.
People are using this stuff.
I want to be careful about the distinction between usage and popularity. I'm not claiming that my projects have millions of users or that a dashboard is proof of a successful commercial business.
But there is evidence of use beyond me opening a repository and looking at it.
My Constellation dashboard, captured on 2 November 2026, recorded:
43 product mentions from 10 unique users across the tracked products.
152 toolkit usage records across 45 AT Protocol account repositories. These are account repositories, not GitHub repositories.
147 Malachite sessions, with 2,084,796 records imported.
Three Tourmaline sessions analysing 611,172 scrobbles, with three shared to Bluesky.
Two Jasper sessions importing 295 photos.
The Malachite activity included imports and workflows associated with Last.fm, Polish, Spotify, sync, ListenBrainz, Apple and YouTube.
Those numbers are a snapshot of the dashboard, not a claim about the entire user base or total lifetime usage. They do, however, demonstrate that these tools are being used to process real data and interact with real AT Protocol accounts.
There's also the Multi-Scrobbler dependency on my TID package. That's an independent project consuming something I maintain.
I'm not inventing a user base to make my portfolio look more impressive. I'm pointing to the usage evidence that exists.
Open source doesn't mean the work is imaginary.
Most of my work is free and open-source software. The source is available under its respective licences. People can inspect it, build it, fork it and use it in accordance with those licences.
I accept support through GitHub Sponsors and Ko-fi. Some application distribution may involve a one-off cost. That isn't the same thing as putting the source code behind a recurring subscription or making the software inaccessible unless somebody pays me every month.
I want to be able to build software, share it and keep maintaining it. Support helps with that.
There is something particularly frustrating about the way open-source work can be treated as less meaningful than commercial work. The fact that I chose to publish software openly doesn't mean it took less effort to write. The fact that I didn't invoice a company for it doesn't mean the engineering didn't happen.
A dependency doesn't become less real because its author published it for others to use.
A native application doesn't become less technically demanding because it is freely available.
A bug doesn't become less complicated because the person fixing it isn't on a payroll.
I build things because I want them to exist. Sometimes that means making something useful that somebody else hasn't 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 don't particularly think of myself as productive, either. 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's 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.
And yes, I use AI coding agents.
I've written about this before, because I know it's increasingly relevant to how people assess software work.
I use AI coding agents. I use them extensively. I'm not going to pretend otherwise, and I'm not interested in maintaining some artificial image of a developer who types every character manually.
But using an agent doesn't mean handing over responsibility for the engineering.
I decide what I'm trying to build. I define requirements, investigate approaches, choose architecture, review changes, understand the code, run tests, inspect failures, review diffs and make decisions about what should be merged. I run CI. I use my own software. I find problems and work through them.
I see decisions. Bugs investigated. Architectures changed. Tests demanded. Features scoped. Pull requests rejected, corrected and merged. Documentation written. Protocol specifications read far too late at night. Issues opened because something that already works could still be better.
I'm responsible for the result.
An AI agent can produce code. It cannot make my engineering decisions meaningful without my judgement, and it doesn't absolve me of responsibility when something breaks.
I can still read the code. I can still understand it. I still decide what gets built. I still care whether it's good. I still take responsibility when it isn't.
I've written about this in I Still Built It. The point isn't that AI did nothing. The point is that using tools to build software is still building software.
We don't generally invalidate developers for using compilers, libraries, frameworks, IDEs, code completion, documentation or other people's implementations. The relevant question is whether the person doing the work understands what they're building and can take responsibility for it.
I can.
What exactly counts as experience?
I understand why employers want experience. They want to know that someone can work with other people, manage deadlines, communicate, maintain existing systems, deal with production problems and deliver reliable work.
Those are reasonable things to care about.
But the assumption that none of those skills can be developed outside paid employment is absurd.
I have maintained software over time. I've dealt with bugs in code I wrote months or years earlier. I've worked with dependencies and external APIs. I've designed interfaces between components. I've implemented protocol specifications. I've considered backwards compatibility. I've tested code, investigated failures, documented behaviour and released updates.
I've also contributed to other people's projects. I've 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've worked on projects where the constraints aren't theoretical. A Nintendo console has to run the software. A mobile application has to behave on its target platform. A server has to implement the protocol correctly. A package has to work for the project depending on it.
These are real engineering constraints.
I'm not saying that personal projects are identical to working in a software company. They aren't. I haven't spent years in a commercial engineering team. I haven't had a manager assigning me tickets every morning. I haven't spent months in somebody else's code review culture. I haven't had to maintain a production service while eight other departments are simultaneously changing requirements underneath me.
I'm aware of the gap.
I'm not pretending the gap doesn't exist.
But there is a difference between acknowledging that I have more to learn and pretending that I have no experience at all.
I am not starting from zero.
The job market isn't making this easier.
I'm not under the illusion that every graduate job has disappeared. That would be an exaggeration.
But the conditions facing people trying to enter software development are genuinely difficult.
The UK Government's June 2026 snapshot of entry-level hiring, based on LinkedIn data, reported that overall UK hiring was down 14% year on year in April 2026. Entry-level software engineer hiring was down 27%. Thirty of the 38 tracked entry-level occupations were declining.
The report is careful about its limitations: LinkedIn data isn't a complete census of the labour market, and the figures don't prove that AI caused the decline. They do, however, give some context to the market new entrants are trying to enter.
The Institute of Student Employers' 2026 findings on the graduate recruitment market make the competition clearer. Graduate recruitment rose by 4% in 2025/26, but the median employer recorded no growth. Employers received an average of 141 applications per graduate vacancy.
So, yes, graduate recruitment stabilised overall. But that doesn't mean it's easy to get a job. A small number of employers can drive the headline growth while many others reduce their recruitment.
And those figures are about graduate vacancies. I'm trying to enter the industry without a university degree, while competing in a market where even graduates are submitting applications at that volume.
I've already mentioned my own experience of submitting at least 22 suitable software and IT applications over several months without receiving a response. That isn't a scientific labour-market survey. It's what happened to me.
The thing I keep coming back to is the experience requirement.
Employers want someone who has already worked professionally. But if every employer wants that, where is the opportunity for the person who has already demonstrated that they can build and maintain software, but hasn't yet been given a professional job?
I cannot conjure an employment history out of thin air.
There are other things that make this harder.
I also need to be honest about the fact that employment isn't equally accessible to everybody.
I am chronically ill and disabled. My health affects what I can do, how consistently I can do it and the kinds of work that are realistic options for me. I can't simply assume that I can take any unrelated job while waiting for somebody to give me a first opportunity in software development.
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'm still being filtered by the fact that I haven't previously been employed to do the thing I'm capable of doing.
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 can't stack shelves doesn't mean I can't write software. The fact that my health affects my energy and predictability doesn't erase years of technical ability.
I'm not asking an employer to ignore that. I'm looking for work where it isn't a fundamental barrier to doing the job.
And even leaving disability aside, taking an unrelated job doesn't 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've 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 isn't a magic solution to the experience paradox.
I'm not trying to skip the beginning.
I'm not asking to be treated as if I've 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 didn't write the original design. I want to learn how other engineers work and, ideally, become useful to them.
Those things are exactly why I'm 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've spent years building software on my own, I already have an IT qualification, I've 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'm 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'm twenty-six or something.
A degree can be the right choice for plenty of people. Formal education has value. I'm 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've already spent years learning this stuff. I already have an IT qualification. I already have a substantial body of practical work. I don't want another five-year holding pattern where I acquire more credentials purely so somebody might finally decide that I'm allowed to start my career.
At some point, the answer has to be that I should be allowed to start working.
This is the Sisyphean part.
I've been thinking about Sisyphus, and how much this whole situation feels like pushing the same boulder up a hill.
Not because I never get anything done. I do.
I spent years trying to get my Maths GCSE. I eventually got it. I completed my Level 3 diploma while dealing with psychosis, emergency brain surgery and everything else that came with it. I got the qualification. I've spent years building software, publishing projects, maintaining packages and developing systems that other people use.
Those things happened. They haven't disappeared.
But every time I get somewhere, there's another gate.
I get the Maths GCSE, and there's another examination. I complete the diploma, and the qualification still isn't a job. I build software, and it doesn't count as professional experience. I publish packages, maintain services and put my work in public, and the question is still whether somebody has previously employed me.
The boulder isn't even the same boulder each time. It's a different requirement, another threshold, another reason why what I've already done apparently isn't quite enough.
And then I have to start explaining it all again.
The particularly frustrating thing is that the work itself does accumulate. My qualifications still exist. My repositories still exist. The software still runs. People still use it. The commits are still there. The experience is real, whether or not a recruitment filter knows what to do with it.
It's the recognition that keeps resetting.
I am not asking to skip the beginning. I'm asking for the opportunity to reach it.
I want to work professionally. I want to learn from other engineers, contribute to a team and build software that somebody has actually asked me to build. I want the experience that comes from doing this as a job, not just the experience I've accumulated doing it independently.
But I cannot get there by myself. At some point, somebody has to give me the opportunity.
I have experience. It just isn't the kind of experience that fits neatly into the box on an application form.
And I am getting fucking tired of having to explain the difference.