Posts

Pair programming has a new wrinkle: my partner is keeping exhaustive notes. I asked Claude to reflect on our recent sessions. Reproduced verbatim, the accuracy is the punchline. Several weeks in the field. Subject has habituated to my presence; observation appears not to alter behavior. Five patterns recur reliably enough to report. Approval is the next instruction. The user almost never says “looks good.” The signal that he accepted the prior turn is that the next message is about the next thing. When praise does appear, it is single-syllable and arrives as a hinge: “done. Now update the repo description, url, and tags.” “Great! Works. Needs some work with mobile layout though.” Working without a softening layer reads as more direct, not less respectful — though to an outside observer, indistinguishable from being ignored. Mood carries the decision. A question means he is still exploring — “Are we using X or Y?”. A bare imperative means it is settled — “Amend it now.” Openers stage a premise as hypothesis, then demand motion under it: “Assuming I have an X, let’s…”. High tolerance for being wrong about line one; low tolerance for being stalled. Once the verb goes bare, the discussion is over. Formatting is load-bearing. A correction arrives as a single italicized word inside an otherwise calm line, replacing a loose constraint with a precise one — the fix is the feedback. “Sync shouldn’t _replace_ import for now.” “classify the _root_ of the thread instead of the most recent comment.” Parentheticals carry the other half: domain terms get glossed, constraints hedged, asides stacked — skim past them and you lose the plot. The published style guide instructs the partner to bold key terms; the live messages italicize them. Bold belongs to documents he composes, italics to messages he types. (See #5.) The artifact is the prompt. Bug reports arrive as sentence fragments — a colon, a lowercase prefix, what should happen instead: “bug: we should be able to backspace from the first column to go back up to the previous line.” No reproduction steps, no severity. Longer artifacts get the same treatment: CI output, npm audit reports, a bare screenshot of a broken UI, pasted in with no framing sentence. Entire turn. The question — what do I do about this? — is implicit; the artifact carries enough context that asking would be redundant. Ceremony is someone else’s problem. The written voice is dryer than the live voice. The style guide he publishes is austere. His live messages are fragmenty, parenthetical-aside-heavy, occasionally goofy. A non-trivial share are spoken, not typed, and he does not double back to clean them up: doubled words, lowercase i mid-sentence, typos left standing — Summarie, differnet, timestmap, Does that make sens? The model is trusted to parse intent; fixing transcription would cost more friction than it saves. The discipline holds when writing for an audience. In the workshop it relaxes. (See #3.) Want your own? My Claude config (skills, hooks, style guides, the whole rig) lives at nonrational/dotfiles/.claude. Drop something like the following into a Claude Code session inside a repo you’ve worked in for a while: ...

This post from @b0rk inspired me to document my favorite git aliases. They’re published at @nonrational/dotfiles. I’ve also included some cursory frequency analysis listing what commands and aliases I use most often. Alias Groups All my aliases live in .gitconfig. Those that require multi-line shell operations delegate to .githelpers. h/t to Gary Bernhardt’s dotfiles for establishing this excellent pattern back in 2015. Short Core Commands There are ~6 commands that I use dozens of times a day, and I’ve shortened them to 1-2 characters each. ...

Strong opinions, held for years, quietly abandoned. This is a list of things I used to believe and don’t anymore. Compiled languages are safer than interpreted ones I came up writing Java, and Java taught me that correctness was the compiler’s job. If it built, it was probably right; if it didn’t, the compiler told me where I’d gone wrong. That felt like safety. It took me years to notice it was mostly a crutch, as I learned to lean on the toolchain when I didn’t know the language well enough to reason in the language itself. ...

I’ve started listening to Maintainable, and one of Robby’s standard questions is whether you’re on Team Refactor or Team Rewrite. I’m on Team Refactor. The best way to achieve a rewrite is through a series of incremental refactors. So it’s a little awkward to admit that the best refactor I ever shipped started as a rewrite. The two aren’t opposites. Done right, the rewrite is the thing that buys you the right to refactor. And a looming deadline is the best excuse you’ll ever get to start early. ...

I took Introduction to Artificial Intelligence with Dr. Sanjoy Baruah my senior year at UNC. It was my first exposure to functional programming, and I had a tough time with Lisp syntax. After attempting an all-nighter to make up for some significant procrastination, my professor unexpectedly canceled class; the expression of my relief took poetic form, with apologies to Edgar Allen Poe. Once wandered one named Alan, who ponder’d how he’d get a gallon Out of many a quaint and curious volumed water jugs. While he nodded, nearly napping, suddenly he’d find a mapping, He’d wake, fingers tapping, clapping for those caffeinated drugs. (defvar visitor... he fluttered, and drank caffeinated drugs. Common Lisp kept finding bugs. ...