posts

“Businessmen are only amateurs at failure, just getting used to the notion. Writers are the real professionals.”

“Learn your instrument. Practice, practice, practice. Then forget all that and just wail.”

A small gh one-liner that turns on private vulnerability reporting for every public, non-archived, non-fork repo you own — or every repo in an org you administer — so security researchers have a sanctioned channel to report issues before they go public.

A second year of CLI picks from the Perl Toolchain Summit — terminals, JSON tools, version control, agent sandboxes, and a shell trick worth knowing. Each pick comes with a short description and a link.

A friendly group of developers, no recording, no posturing — just shared screens and honest notes from the second AI Shoulder Surf session. The recurring theme: people are tightening up where their agents can reach, and getting choosier about which models they trust with the work.

Dependabot’s defaults can make it look like an agent of chaos. Here’s how cooldowns, dependency groups, and a Claude skill turn down the churn — fewer rebases, boring CI, and a few extra days for the world to flag the bad actors.

Notes from an informal Zoom session where developers shared AI tools, automation techniques, and projects. Topics included using Claude in headless mode to manage version bumps across 20+ packages, an overnight bot that processes GitHub issues and responds to PR comments, the “Talk About Us” copy-auditing skill, and a lively debate about whether the future of development is writing specs rather than code.

It’s easy to fall into a trap of using jargon when discussing what you’re working on. Sometimes we need help expressing our thoughts in interesting and meaningful ways—using our own voices, in a way that’s memorable and repeatable. A blog post by Anil Dash helped me rethink my writing. I’ve turned those principles into an AI skill, so you can try it too.

I rarely use git-bisect, but thinking about it has changed how I structure my commits. The principle is simple: don’t break git-bisect. If a change breaks something, the fix should belong in that same change. This mental model helps avoid common anti-patterns like splitting a bug fix into two commits—one with a failing test, one with the fix. Even if you never run bisect, thinking “would this commit work in isolation?” creates a provably linear set of working changes rather than an aspirational attempt at correctness.