I recently asked Claude to look back over how I work and tell me what, if anything, was worth keeping. It returned a tidy list of habits. Most of them were tangled up with specific projects I cannot write about here, but one stood out because it had nothing to do with any particular job. It is the only one I would defend as genuinely portable, and it is boring in the best way: I write down what I learn, and then I maintain it.
Capture the lesson
Every engineer solves the same class of problem more than once. The only question that matters is whether the second time is cheaper than the first. Most of us fix a bug, feel the small relief, and move on, only to meet its cousin six months later and solve it from scratch.
What I try to do instead is spend the extra two minutes to record not the fix but the lesson. A good note captures three things:
- the shape of the mistake, not just this one instance
- the date it cost me something, so I know when it might be going stale
- the rule that would have prevented it
A fix solves one case. A rule closes a category. Over a few years the notes stop being a list of solved problems and become a compressed version of my own judgement, one I can reread, hand to a colleague or point an agent at.
From notes to instructions
This habit used to be mostly for me. Lately it has quietly changed shape. When you work with coding agents, a well written rule is no longer just a private reminder. It becomes an instruction you can delegate against. “Never do X without first checking Y” stops being a note to self and turns into a guardrail the machine will actually respect. The clearer the rule, the more autonomy you can safely hand over. I did not expect my scruffy pile of lessons to become the interface for delegation, but that is more or less what happened.
The trap
There is a catch, and it took me a while to see it. A system built entirely from “this burned me, never again” is optimised against your past, and two things follow. Rules quietly go stale, so the real work is not writing them but retiring the ones that no longer hold. And a growing collection of “never again” slowly makes you conservative. Guardrails are very good at preventing disasters and no good at all at finding the next opportunity. So I now try to spend as much effort pruning old rules as adding new ones, and to remember that not every lesson deserves to become a law.
What actually compounds
The thing I would carry into any project is not the notes themselves. It is the discipline behind them. Treat what you learn as an asset worth maintaining, write it in a form someone else could use, and stay as willing to delete a rule as to write one. The notes are only where that discipline leaves a mark.