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.
I have had more ideas than I can count. A notes folder full of app concepts, half-baked prototypes in forgotten repos, domain names I bought in a fit of optimism at 2am. Over a decade of this. Life gets in the way. Work gets in the way. Kids, mortgages, health, relationships, fatigue. The ideas pile up and the backlog grows.
If you look at my GitHub, you might think I ship a lot. Nearly 200 repositories. Aurelia plugins, blockchain games, CLI tools, a regex battle game, apps for finance tracking and tattoo previews and bedtime stories. From the outside it probably looks prolific. But I know what is missing. The projects that never left my head. The code that never got written. The things I talked about for years and never touched.
I have never been a TDD purist. The whole write-tests-first-no-exceptions religion always felt a bit much. Sometimes you are exploring. Sometimes you do not know what the code should do until you have written it. Sometimes you just need to ship the thing and circle back to tests later. I get it. I have lived it.
But AI assisted coding has changed my relationship with TDD. Not because I suddenly found religion, but because tests solve a very specific problem that AI introduces: you cannot trust the output.
I write software for a living, often as a freelancer/consultant. My faith doesn’t make me louder; it makes me clearer. It’s the thing that nudges me toward honesty, courage, and high‑quality work when nobody is watching.
I built a small app called Regex Battle. It lives at https://regexbattle.com and it turns regular expressions into a head to head game. You get a prompt, a timer starts, and your goal is to write a regex that meets the challenge before the clock hits zero. You can play against another person or against a bot if you want to practice solo.
Regex Battle is a PvP regular expression battle game with a bot and PvP mode. Each round gives you an objective and a set of example strings. Your job is to write a pattern that matches what it should and rejects what it should not. When you submit, the app checks your regex against the round tests and shows the result. Fast and correct beats slow and almost. Simple as that.
I learned early that a day job will keep you busy, but it will not always stretch you. If you want to move forward, you have to put in reps outside the clock. Not forever, not at the cost of your life, but long enough and often enough to build range.
I started in an agency. Fast pace, many clients, constant context switching. I worked late nights and some weekends because I wanted to get better. That is not a long term lifestyle and I do not recommend burning yourself out, but those seasons taught me how to ship, how to debug under pressure, and how to own the result. They also taught me to set better boundaries later. You can hold both truths: growth often requires extra effort, and health requires rest.