
I’m someone who needs to build. I like experimenting, getting my hands on things I don’t know, learning something new and seeing how far I can take it — and that’s as true of my work as it is of what I do when nobody asks me to.
What’s been missing is keeping any record of it. The experience stays in my head, or I tell someone about it once, out loud, and that’s where it stops. From here on I’m going to write it down.
Not out of nostalgia. Writing it is useful: to me, because it puts what I’ve done in order and makes it something I can show; to whoever is up against the same problem and is looking for someone who has already been through it; and to anyone following along who wants to know what I’m working on.
How I got here
I taught myself to program long before anyone taught me: taking things apart to see how they were made inside, and putting them back together different. When it came time to choose a school I chose it for that, against the advice of almost everyone around me, and I arrived at university already knowing what I wanted to do with it.
Then it became the job: real clients, other people’s projects, companies, products that keep going for years. Every stage taught me something the one before it couldn’t. Working for someone who pays you isn’t working for yourself, and maintaining something for years isn’t building it.
What never changed is the other half: what I build when nobody asks me to.
What I build when nobody asks me to
There are always two or three things open, outside working hours. Sometimes they come from a problem of my own that nobody has solved the way I’d want; more often from a technology I want to genuinely understand, and the only way I know to understand one is to build something with it that has to work.
That’s where you actually learn, because that’s where choices have a price. Documentation tells you what a tool does; building something real on top of it tells you what it doesn’t do, and what it costs you to find that out late.
Not everything gets anywhere. Some things end up in people’s hands and get used, some stop before that, and some I drop because I’ve learned what I wanted to learn and the thing itself is no longer any use to me. I don’t call those failures: I got what I came for anyway.
What you’ll find here
Accounts of things I actually built, with the technical detail that matters and the results as they went, including the ones that don’t flatter me. A project that didn’t work, explained well, is worth more than a successful one told halfway.
These aren’t tutorials: I’m not trying to teach anyone how to use a tool, and there are better places for that. There’s no thesis to prove either. The subjects will change, because what I work on changes; what stays the same is the angle — a thing that got built, why I built it that way, and what I got out of it.
This is the space to put them in. Starting here.