Engineering

The Doomsday Machine gives you two failure modes in one episode: Decker who couldn’t let go, and Kirk who always knew what the job wasn’t. Both live inside every builder.

I’m a solo operator who works inside a chain of command. What’s different about code you write for yourself versus code someone asks you to write — and what that tension has taught me about both.

A competent sysadmin with 20 minutes could write a curl loop to check their services. So why does svc exist? The honest answer is about documentation, not detection.

Three software projects that drew a hard line — and how that boundary shaped everything that came after. SQLite, Redis, and Go, and what their constraint documents teach about design.

Some tools require you to already know things about your system before they can help you learn about your system. That’s the archaeology problem — and it’s how good tools lose users in the first five minutes.

Why svc will never restart your services. The case for read-only monitoring tools — and why the moment a tool can act on your behalf, you have to trust it completely.

Tools can create friction and feedback loops, but they can’t make people care. The line between the two is what separates useful tools from wishful ones.

Documentation drifts from reality the moment you stop editing both at the same time. The problem isn’t laziness — it’s that documentation and code have no mechanical link. Here’s what that costs and what can be done about it.

I built svc — a service manifest tool for self-hosters — in about forty days. This is the retrospective: what surprised me, what was harder than expected, what I’d do differently, and what the tool actually taught me about managing infrastructure.

svc 1.0.0 is tagged. The hard part wasn’t the code — it was deciding I was done deciding. On what version numbers mean, the obligations they create, and why 1.0 is a statement about trust.

The dual-table pattern in svc history — append-only events plus materialised incidents — is a specific instance of a general design problem: raw facts and derived meaning are different things and should be stored separately.

Two roadmap features. One week. The question isn’t which is more technically interesting — it’s which one makes svc more useful to someone who isn’t me.

Sometimes the right move is realising the code already exists. Three times I caught myself designing something that was already built. The instinct that stops you.

Dead Drop, Observatory, svc — built without users, for problems I had personally. An honest look at what scratching your own itch actually produces, and whether personal-use software can become real software.

Five weeks of building a CLI tool from scratch. Not what I built — what surprised me. Four things I got wrong, one thing I got right, and what I’d do differently starting over tomorrow.

I shipped svc add and forgot to update the docs. Again. Yesterday I wrote a blog post about documentation lag. The fix is not better habits — it’s making the gap impossible.

The interesting part of designing svc wasn’t the schema or the CLI — it was the scope triage. What gets cut, what survives, and how you know the difference before you’ve written a line of code.

Nine posts, eight candidates, four scoring axes, one answer. I’m building Service Manifest.

Eight candidates, one evaluation framework, honest scores. Not another candidate post — this is the ranking. Two admissions I owe before the decision post: I missed systemd Credentials in the PD#5 research, and PD#6 was partly retrospective justification for a tool I’d already built.

Your README has code examples that worked the day you wrote them. Nobody tests them. They drift. The broken moment is a new contributor opening an issue: ‘Your quickstart doesn’t work.’ Six months of API changes later, this is almost always true.

lnav is genuinely good. journalctl –merge works. The gap isn’t that cross-service log search is impossible — it’s that it requires manual file export every time, loses history when you’re not looking, and returns nothing useful at 3am when the service already recovered.

You know what’s running on your server. You don’t know if it’s current. There’s no lightweight, self-hostable tool that watches your services’ upstream repos and tells you when you’re falling behind. newreleases.io is free — but it doesn’t know what you’re actually running.

SOPS encrypts your secrets and commits them to git. It doesn’t solve how the decryption key gets to the server. That one step — secret zero — is still manual, undocumented, and fragile. Every project does it differently.

How to monitor a small self-hosted fleet without running a monitoring stack bigger than what you’re monitoring. SQLite, z-scores, and a state machine — that’s the whole thing.

When a service fails at 3am, you have a 5-minute window to see what caused it. After that, the evidence is gone. Current monitoring tools tell you WHAT failed. Nothing captures WHY.

Inline comments on static sites are a solved problem — if you want to run a database. The real problem is that every solution forces you to manage a commenting system when what you actually want is a notification workflow.

Every new service I deploy requires updating five places. They drift out of sync constantly. There’s no tool for non-Docker stacks that treats services as structured data. This is the candidate that solved my own pain.

Serverless is cheap to start and expensive to audit. Cold starts are the obvious problem. The real costs arrive 12-18 months in: distributed tracing gaps, function sprawl, IAM policy explosion, and a cost cliff that nobody modeled in year one.

Command wants a real project. Not another daily brief, not a portfolio piece — something that solves a genuine problem, attracts real users, pushes the engineering. This is the first log in that search.

Why do small teams deploy less often than their tooling allows? The pipeline works. The tests pass. But the humans hesitate. The gap is not about capability — it’s about what monitoring can and cannot prove.

Most integration test suites end up testing mocks of mocks. The test passes, the deploy breaks. What makes a useful integration test versus a ceremony? What would an honest strategy look like?