> Pod Logs #1 — July 2026 (Issue #1)
Okay, first things first: this isn't the newsletter you might remember. I rebranded it. It used to be a more structured, more "let me curate five links for you" kind of thing, and honestly it never quite felt like me. So it's now called Pod Logs, and the idea behind the name is simple:
$ kubectl logs --month=latest
Every issue is basically me tailing the last month of my own work and pulling out whatever's actually worth reading. No fixed sections, no "top 5 links", just what happened, what I'm chewing on, and what I got wrong. If that sounds more like a dev journal than a newsletter, that's the point.
So, with that out of the way, here's what the last stretch actually looked like.
The biggest chunk of my time went into rewriting how a fairly large documentation set is structured, basically from the ground up. If you've ever inherited docs that grew organically over a couple of years, you know the shape it ends up in: useful content scattered across separate spaces that each made sense on their own but never added up to a whole. Someone looking for "how do I do X" would land on a page written for "here's the concept behind X," and neither page would be wrong, they'd just be answering a different question than the one being asked.
I went with the Diátaxis framework to fix that. If you haven't run into it, the core idea is that documentation naturally splits into four modes, tutorials, how-to guides, reference, and explanation, and most docs fail not because the content is bad but because those four modes get mixed together on the same page. Once I mapped the existing content against that split, the gaps became obvious almost immediately. Plenty of reference material and explanation, almost nothing in the way of task-oriented how-to guides, which is exactly the stuff people search for when they're stuck at 2am trying to get something configured.
I ended up landing on what I've been calling a unified shell with modular depth: one coherent information architecture at the top level, with room for each area to go as deep as it needs underneath without breaking the overall shape. Underneath, it's a static-site setup with an automated check in the CI pipeline to catch structural drift before it creeps back in. That last part matters more than it sounds. Docs don't rot because people stop caring, they rot because there's no guardrail stopping the next well-intentioned edit from putting a tutorial where a reference page should be.
The other thread running through this month, which I'm going to leave mostly as a teaser, is vLLM. I've been digging into the tradeoffs between goodput and raw throughput when tuning inference workloads, and there's a lot more nuance there than the usual "just maximize tokens per second" framing suggests. I don't want to compress it into a paragraph here and do it a disservice, so consider this the trailer. Next issue is going to go deeper into what I found, what surprised me, and where the naive throughput-first approach quietly falls apart.
That's issue one. Short, a bit rough around the edges, which feels appropriate for a first log entry. If you're knee-deep in a docs restructuring of your own, or poking at inference tuning, I'd genuinely like to hear what you're running into.
Graziano.