Why You Should Hire Me

What I can do

I build backend systems from the ground up — job queues, auth libraries, rate limiters, a scripting language with its own interpreter, a Git implementation, an HTTP server built straight off TCP sockets. Not tutorials, not wrappers around someone else's library — the actual thing, understood well enough that I can walk you through why every piece is built the way it is, not just that it works. When I build something, I benchmark it, I know its failure modes, and I know what I'd change if the requirements shifted.

I don't trust code just because it runs, including my own — I write unit tests for everything, and I don't consider something done until it's tested, not just working. For systems that need to hold up under load, I simulate high request volume against them to find where they actually break, not where I assume they might — I want to know the failure point before a user finds it for me.

I know how to actually use AI — not just prompt it, but plan work with it, build with agents, break a task down into something an agent can execute well, and know when to trust the output versus when to throw it out and do it myself. I've gotten good results out of weak models by supplying the judgment the model doesn't have. That skill — knowing where the model ends and I begin — is the actual differentiator right now, more than raw output speed.

I show up, I finish what I start, and I'll code from a phone in a pinch if that's what I've got — I already have, for years, before I owned a laptop.

What I can't do

I haven't worked on a large engineering team yet, and I haven't shipped anything at scale under real production traffic — my load simulations are me finding my own systems' limits, not the same thing as production traffic finding them for me, with real users, real edge cases, and real cost pressure attached. There are gaps that only real team experience fills — code review from senior engineers, working inside someone else's architecture instead of one I designed myself, coordinating with people instead of just AI agents — and I haven't had that yet. I'm not going to pretend otherwise, and I'd rather you know that going in than find out later.

Three reasons anyway

1. 1. I don't trust code until it's tested — including mine.

   I write unit tests as a default, not an afterthought, and I stress-test systems under simulated load before I call them done. I've built things complex enough — a tree-walking interpreter, a distributed job queue with a stale-job reaper, an auth library that detects refresh-token theft — that untested code would've broken immediately and silently. It didn't, because I tested it before I trusted it, not after something broke.

2. 2. I know how to work with AI, not just talk to it.

   Planning a build with an agent, deciding what it should own versus what I should own, catching when it's confidently wrong before that mistake ships — that's the actual skill now, and it's separate from knowing how to code. Most people either refuse to use AI on principle or use it uncritically. I do neither. I use it deliberately, and I stay the one who's responsible for the result either way.

3. 3. Circumstances don't stop me.

   I wrote my first code on a phone, before I owned a laptop. I've built a working DSL and set up dev tooling with nothing but a touchscreen — no proper keyboard, no multiple monitors, none of the setup people assume you need to be productive. If the setup's not ideal, I adapt. I don't wait for ideal conditions to start doing good work, and I won't wait for them on your team either.