Dev Notes
Dev Notes: May 18, 2026
My manager has changed more times in the last 18 months than my domain has. Leadership turnover, org restructures, team rebrands. The operating environment moves faster than any single performance cycle. The work I shipped a year ago has lived under three different reporting lines.
The thing nobody warns you about: the new manager isn't going to read your old reviews. They don't have the cycles to. They'll form an opinion of you based on what they observe in the first 60 days plus whatever you hand them.
What survives the change is the brag doc.
Not the polished version with bullet points and metrics that you assemble two weeks before review season. The running one. A line a day, or three lines a week. What shipped. Who you influenced. What you decided not to do and why. Specific enough that future-you can rebuild the story and hand it to a manager who wasn't in the room.
This looks like ego work. It's continuity work. Performance reviews and promotions depend on someone remembering, and after enough manager changes, the only person guaranteed to be there is you.
The version I run is two lines in my daily work log under a "Brag Doc Candidates" heading. Maybe a minute of writing. Three years of running it has paid for itself ten times over, and the spread across managers and orgs has only made it more load-bearing.
If you're not running one, start tomorrow. The version that exists is better than the version you'd write perfectly.
This Week on Slightly Caffeinated
E59: Rig, Iris Journaling, and 3D Printing with Claude
TJ and I cover my hackathon project that just became my next month of DevEx work (a CLI called rig that merges microservice infra into one Docker Compose and ships Claude skills for schema-aware seeding), TJ's Iris journal feature that watches Iris journal about its own response patterns, the $300 Anthropic bill that paused his roadmap, and the work-side conversation we're now having about backing out of Claude Code lock-in via Bedrock plus alternative harnesses.
Out now wherever you get your podcasts.
What I'm Learning
We needed to lock in which infrastructure types and migration tools an internal CLI should support on day one. I had a working list from memory and recent project work. The plan was to validate it with seven team interviews.
I ran a Claude-driven scan over 97 repos first. Counted imports, flagged framework usage, ranked everything by actual adoption frequency.
The scan didn't overturn the list. It tightened it. A few candidates I had ranked high turned out to be one-or-two-repo cases that didn't justify Phase 1 support. A couple of supporting tools I had weighted lower showed up frequently enough to belong on the list. The whole thing ran in an afternoon and gave me a frequency-ranked picture I'd never have gotten from interviews.
The interviews are still happening. The questions are sharper now. Instead of "what do you use," I'm asking "what hurts about the thing you use." The codebase already answered the first question.
Dev Tool of the Week
The /simplify skill
Built-in Claude Code skill, easy to overlook. Run it on a branch before opening a PR and it reviews your changes for reuse, code quality, and dead weight, then offers to fix what it finds.
The pattern that's been working: write the feature, run /simplify, accept the obvious wins, push back on the ones I disagree with, then push. It catches the kind of stuff that a careful reviewer would flag (duplicate helpers, an early return that simplifies a nested condition, a function that's used in one place and should be inlined) before anyone else has to spend their attention on it.
Pairs well with the bigger habit: stop accepting Claude's first answer. Run it through one more pass before you ship.
That's it for this week. Hit reply if you're running a brag doc and have a format that works, or if /simplify lands differently for you than I described.
– Chris