There’s no real starting point for something like this. I’ve been keeping decision logs and work logs alongside my code for a while now: private repos, half-finished notes, things only I was ever going to read. So “ground zero” isn’t really accurate. This is just the first time any of it is public.
I called it that anyway, because it’s close enough. Everything before this was scattered, a markdown file in one repo, a comment thread in another, a note to myself I’d never look at again. This is the version where it all lives in one place, on purpose, where someone other than me might read it.
The process is less romantic than “writing as it happens.” Mostly I jot things down while I’m in the middle of a problem, what broke, what I tried, what I changed my mind about, and the actual post comes later, once there’s enough distance to see the shape of the decision instead of just the panic of making it. What goes here is closer to that raw material than a polished retrospective. If I spend a week comparing two architectures and pick the wrong one, that’s a post. If something breaks and the fix is mundane, that’s a post too.
Some of what shows up here will come out of the work that pays the bills, a corner of the internet most people never think about: the layer underneath the layer, where domains get issued, DNS gets resolved, certificates get signed, and the whole thing quietly has to keep working for everyone else’s websites to exist at all. It is unglamorous until it breaks, and then it is the only thing that matters.
But that is just one source, not the whole story. Just as often it will be something I chose to go deep on for no reason other than wanting to understand it, an experiment that turned into a real project, or a problem I picked up because I couldn’t leave it alone. I came to engineering self-taught, by reading and rebuilding things until I understood them, and that habit has taken me through a fraud and security research project, an anti-malware engine built from scratch, and whatever side project happens to have my attention that month. I also write outside of code, technical pieces as well as poetry, and paint when I’m not at a keyboard. None of that will be the main subject here, but it shapes how I think about the main subject, so it will show up at the edges.
I’ll admit this much upfront: nobody teaches you to be an engineer in the abstract. You become one the same way you become anything, by doing the work, getting it wrong, and doing it again until the wrongness teaches you something. You only become an engineer by becoming one. That’s most of what this log will be a record of.
I’m not going to pretend the throughline is always clean. It rarely is while you’re in it.
If you’re an engineer working through similar problems, distributed systems, infra trade-offs, the distance between a clean spec and what actually ships, I hope some of this is useful. That’s the only real goal here.
Everything else starts now.