Posts on the tooling that catches problems before they reach production — static analysis, testing frameworks, code-metric analyzers, and the release plumbing that gates all of it. Some of it is Go-specific (Ginkgo, golangci-lint, kyber, TDD-shape). Some of it isn’t (nasm-lint for NASM assembly, semantic-release as a language-agnostic contract). The common thread is: the quality gate should live in the loop where the code is written, not in a review that happens after the fact.
Four voices argue about unit tests. The debate dissolves once you separate coverage-as-target from coverage-as-detector, with testability as the real prize.
Years ago, on my first day at a new company, I sat down for what I thought was going to be a normal pair-programming session. There was a story on the board — I no longer remember what it was, exactly. Some feature, a handful of requirements, the usual shape of a first ticket at a new job. I read the requirements, my mind raced ahead to how I’d build it, and I started talking through my approach.
...
A previous post argued that Dev, QA, and Product read the same requirement differently not because anyone is careless, but because prose leaves three things implicit — the precondition, the action, and the outcome — and that a structured format forces those three things into the open. It also argued that the specific tool doesn’t matter much: Gherkin’s Given/When/Then is one well-known way to get the structure, not the only one, and a team is free to define its own.
...
I wanted the music player on my /music/ page to keep playing when a visitor clicks around the rest of the site. No stop, no restart, no auto-mute — just seamless continuous playback while the DOM around it swaps. The obvious approach — the one every blog post about Turbo tells you to use — didn’t work. The one that actually worked took me through three false starts.
If you’re building a Hugo (or Jekyll, or Rails) site and you want an audio or video iframe that survives site-wide navigation, this post is what I wish I’d found on day one.
...
Code review catches the bugs a human happens to notice. Static analysis catches the bugs a specific, well-defined check is built to notice — every time, on every line, before anyone opens the diff. Those are different guarantees, and the difference matters most for the bug classes reviewers are worst at: an HTTP response body that never gets closed three call sites deep, an error return silently discarded in a one-line change, a security-sensitive value generated with the wrong random source. None of these look wrong at a glance. All of them are mechanically detectable.
...