I have written a lot of code. Hundreds of thousands of lines across dozens of projects over twenty years. Some of it was clever. Some of it was elegant. Some of it solved hard problems in interesting ways.
The best code I ever wrote was none of that. The best code I ever wrote was the code I deleted.
A function that turned out to be unnecessary. A feature that nobody used. An abstraction that added complexity without adding value. A clever solution to a problem we did not actually have. Each deletion made the codebase better in a way that no addition could match.
The most successful software I have ever built ran on technology that was embarrassing to admit at the time. PHP when everyone was doing Node. PostgreSQL when everyone was doing MongoDB. Server-rendered HTML when everyone was doing SPAs. Cron jobs when everyone was doing event-driven architecture.
I was embarrassed about these choices at meetups. I felt like I had to apologise for not using the cool stuff. The other developers talked about their microservices and their Kubernetes clusters and I smiled and nodded and went home to my monolith that actually worked.
I am going to say something that will upset a lot of people who have invested significant portions of their careers into container orchestration: Docker Compose is probably all you need.
Not Kubernetes. Not ECS. Not Nomad. Not whatever managed container platform your cloud provider is pushing this quarter. Docker Compose. The thing you used in tutorials before graduating to real infrastructure. That thing. It is enough.
Kubernetes is incredible technology you do not need Kubernetes can do amazing things. It can manage thousands of containers across hundreds of nodes. It can self-heal, auto-scale, handle rolling deployments, manage secrets, configure networking, and orchestrate workloads across multiple data centres. It is genuinely impressive engineering.
GraphQL is dying and I could not be happier. The hype has faded. The conference talks have dried up. The true believers have gone quiet. Teams are quietly migrating back to REST and pretending they never suggested GraphQL in the first place. The fever has broken.
Good. It was a fucking mistake.
The problem it solved did not exist GraphQL was supposed to solve over-fetching. Your REST API returns too much data, they said. You are wasting bandwidth, they said. The mobile clients only need three fields but you are sending back fifty.
Microservices were a mistake. Not the concept itself, which has legitimate uses at genuine scale. The mistake was convincing an entire generation of developers that their CRUD app needed to be split into 47 independently deployable services communicating over a message bus designed by someone who watched one too many conference talks.
I said what I said. Come at me.
Netflix ruined everything This is Netflix’s fault. Not intentionally. They shared how they solved their genuinely massive scale problems, and the rest of the industry collectively lost its mind.
I should not need to read a novel to call your endpoint.
If your API documentation spans forty pages, multiple guides, a getting started tutorial, a concepts section, a best practices section, and a troubleshooting FAQ, your API is not well documented. Your API is badly designed. The documentation is compensating for failures that should have been fixed in the API itself.
Good APIs are self-evident. You look at the endpoint, you understand what it does. You look at the request, you understand what to send. You look at the response, you understand what you got back. The documentation exists to confirm what you already intuited, not to explain an incomprehensible system.
I have spent more time than I care to admit writing technical documentation for Aurelia 2. The docs at docs.aurelia.io have been through countless revisions, rewrites, restructures, and moments where I stared at the screen wondering if I had forgotten how to form sentences.
Writing code is hard. Writing about code in a way that helps other people write code is harder. Nobody prepares you for this.
The first thing you learn is that you do not actually understand the thing you are documenting. You think you do. You have used it, you have built things with it, you can explain it to a colleague at your desk.
You are a startup. You have twelve users, three of whom are your mum, your co-founder, and your co-founder’s mum. You have six months of runway. You have not found product-market fit. You are still pivoting weekly based on whatever feedback you got from the last person who agreed to a demo.
And you want to build a mobile app.
No. Stop. Put the Xcode down and step away from the keyboard.
I am a front-end developer. That is my main thing. JavaScript, TypeScript, component frameworks, state management, the DOM and all its quirks. I have spent years in this world and it is where I am most comfortable. If you need someone to build a reactive UI or argue about whether signals are better than virtual DOM diffing, I am your guy.
I am also a PHP developer. Have been for a long time. Back-end work, WordPress, Laravel, the lot. That is another core part of my toolkit that has served me well for years.
It is not a secret anymore. Most developers use AI tools now. If you are not using something like GitHub Copilot, Claude Code, OpenAI Codex, or even just pasting problems into ChatGPT, you are probably in the minority. The stigma has evaporated. Nobody is pretending they wrote every line by hand anymore.
Using AI to write code is just what we do now, like using Stack Overflow was ten years ago except the answers are usually better and you do not have to scroll past three people arguing about whether the question is a duplicate.