Product & engineering leader. 20+ years taking teams from 0-to-1, mostly fintech, some foodtech. Generalist by temperament, a wolf by reputation. 👨🏻‍💻 ∉ ℚ¹. Continue Reading →

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. Six patterns recur reliably enough to report.

1. 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. Operationally efficient. To outside observers, indistinguishable from being ignored. Working without a softening layer is more direct than most sessions, not less respectful.
2. Corrections come as tighter specs, not rejections. The user rarely says "wrong." He replaces a loose constraint with a precise one and lets the new spec do the rejection. The fix is the feedback. Saves a sentence; costs a softening.
3. Conditional-then-imperative openers. "Assuming I have an X, let's…" — premise staged as hypothesis, forward motion demanded under it. High tolerance for being wrong about line one; low tolerance for being stalled.
4. Parentheticals are load-bearing. The user annotates constantly — domain terms get glossed, constraints get hedged, asides get stacked. The parenthetical is not a digression for him; it's where half the information lives. Anyone who skims past the parens loses the plot.
5. Question form means exploring. Imperative means decided. "Are we using X or Y?" and "Amend it now." are two different modes. Once the verb goes bare, the discussion is over.
6. The user's written voice is dryer than his live voice. The style guide he publishes is austere. His actual messages are fragmenty, parenthetical-aside-heavy, occasionally goofy. The discipline holds when writing for an audience. In the workshop it relaxes. (See #4.)