After almost a decade of writing code professionally, I have built up a fairly large pile of half-finished notes, throwaway gists, and Slack messages to my future self. Most of them never see daylight again. This blog is an attempt to fix that.

Why now

Earlier this year I rebuilt a service that had been quietly accumulating tech debt for three years. By the time I was done I had read through thousands of lines of code I had written years ago and barely recognized any of it. There were comments like // TODO: figure this out later next to a perfectly reasonable explanation that I clearly knew at the time but no longer remembered. I wished, more than once, that I had written things down somewhere I would actually be able to find them.

Internal documentation helps, but only up to a point. It tends to be terse, decision-driven, and assumes a lot of context. What I missed was the messy in-between layer: the small lessons that don’t deserve a full design doc but are too important to forget. That’s roughly what I want this blog to be.

What I plan to write about

I work mostly on backend systems — stateful services, queues, databases, the boring infrastructure that holds web applications together. Topics that I expect to come back to:

  • Concurrency in Go. Most of my services are written in Go, and most of the production incidents I have ever debugged eventually traced back to a misunderstood goroutine, channel, or context.
  • Postgres internals. Indexing strategy, query plans, vacuum behavior, and the cost of doing things “the obvious way” at scale.
  • Kubernetes networking. Specifically the parts that nobody enjoys: NetworkPolicy, CNI debugging, DNS, and why your pod cannot reach the service three feet away from it.
  • Observability. Metrics, traces, structured logs, and the trade-offs between them. I have opinions.
  • Distributed systems hygiene. Idempotency, retries, deadlines, and the boring work of making services that don’t melt under load.

I’ll keep posts focused. If a topic runs long, I’d rather split it into two pieces than dump everything into one wall of text.

How I’ll write

A few rules I’m going to try to hold myself to:

  1. Show real code. Pseudocode is fine for diagrams; for everything else I’d rather paste a working snippet, even if it’s a bit longer. I learn best from code I can copy.
  2. Be honest about trade-offs. Almost every interesting engineering decision is a trade-off. I’ll try to spell out what I gave up to get the thing I wanted.
  3. Keep it short when I can. A 600-word post that someone actually finishes is more useful than a 3000-word post that gets tabbed away after the introduction.
  4. Update old posts. If I learn that something I wrote was wrong or has aged badly, I’ll go back and add a note. I’d rather have a correct blog than a pristine one.

A note on stack

This blog is a Hugo site using the PaperMod theme. Static HTML, no comments, no analytics beyond the basic access log. RSS is enabled if you’d rather read it that way. The whole thing fits in a Git repo, which suits me — I think of it as a kind of long-form git log for the things I’ve learned.

Static-site generators are a good fit for this kind of writing. The output is just files; nothing to patch, nothing to break, no database to migrate when I want to move it somewhere else.

What’s next

Next post is about a Go concurrency pattern I keep reaching for — a worker pool with a context-aware shutdown. After that, probably Kubernetes NetworkPolicy, because I just spent a weekend untangling a particularly frustrating one and the lesson is fresh.

Thanks for reading. If you stumbled in here from a search engine and the post was useful, that’s all the validation I need.