I’ve built developer tools for most of my career—CLIs, internal SDKs, deployment scripts, local simulators—and I keep running into the same pattern. The teams building these things get treated like a service desk, not an engineering discipline. The tools themselves get cobbled together in a rush, handed off with zero documentation, and abandoned the moment …
Month: June 2026
Most documentation is just theater. It’s there because a manager decided it should be, not because it solves a real problem. I’ve lost count of the READMEs that are nothing but a brick of setup commands, API references structured like a phonebook, and internal wikis nobody visits twice. The issue isn’t that engineers can’t write—it’s …
Most documentation is just digital landfill. I’ve watched teams burn weeks building sprawling wiki pages nobody ever opens. It’s not a tool problem—it’s a headspace problem. We write docs to feel busy, not to rescue the poor soul debugging at 2 AM. If you want your words to land, cut the fluff and zero in …
I’ve watched this scene play out for over a decade. Sprint planning kicks off. The PM rattles off features. Designers have their Figma files polished. Backend leads sketch out API contracts. Then someone asks, “So, how’s the local dev setup looking for this?” Silence. Eyes dart around. Somebody mumbles, “Works on my machine.” Nervous laughter …
I’ve watched too many engineers use “script” and “tool” like they’re the same thing. They’re not. A script solves a one-off problem. A tool solves a class of problems. Miss that distinction, and you wind up with a heap of brittle automation that shatters the moment requirements drift even a little. This isn’t some abstract …
Ten years ago, handing a new developer a “getting started” guide was a coin toss. Half the time, they’d spend three days fighting library versions, system paths, and that one package that compiled fine on Ubuntu but choked on macOS. The other half, they’d get something running by day two, then break it on day …