About
I'm Ben Blaker, a technologist. That's the only word broad enough to cover it. I've been an SRE, an engineer, an architect, and an executive, and the thread running through all of it is that I've never wanted to stop being hands-on. DevOps, platform, cloud: I like being in it rather than adjacent to it.
Mostly that means writing software. Go and TypeScript are where I spend my time now, but I've shipped Python, PHP, C++, C#, Java and a long tail of others, and I treat them as more or less interchangeable: pick the one that fits the problem, learn what's idiomatic, get on with it. The syntax was never the interesting part. What I'm consistently drawn to is tooling: the unglamorous things that make other engineers faster, which almost nobody is assigned to build and everybody benefits from.
That's nearly two decades now across software engineering, architecture, IT and SRE, some of it in leadership and some as an individual contributor. That work teaches you a particular kind of humility. The interesting failures are almost never the ones you designed for, and the graph you didn't think to draw is the one you'll want at 3am.
How I work
I like understanding things all the way down. It's the same instinct whether it's reading kernel networking code, tearing a printer apart to find why the first layer drifts, or working out which node is lying about its state. I'm suspicious of abstractions I can't see through, which is less a principle than a compulsion.
I'd rather run something myself once than read three blog posts about it. The homelab exists specifically so that I have something I'm allowed to break. A cluster you can take down at 11pm on a Tuesday teaches you things a managed one never will. The printers, the home automation and the electronics are the same impulse pointed at physical things, with the additional virtue of failing in ways you can hold.
And I stay in the code, including when the job is helping someone else do the work. I've never been able to give useful support from a summary. If I can't see what you're actually looking at, I'm guessing, and confident guessing is worse than saying nothing. Reading the diff properly is worth more than any amount of advice about it.
What's here
Projects are long-lived things with a status and a spec sheet. The log is dated entries: build notes attached to a project, longer essays, and short notes. The backlog is public, which I find more honest than pretending the list is finished.
I try to write things down before I know how they turn out. A build log written on day one is more useful than a polished retrospective written three weeks later, because the uncertainty is the interesting part and it doesn't survive being remembered. Some of these entries will age badly. That's the point of dating them.