Unlearning

I've played ping pong for many years. A thing you notice with anyone that's self-taught is that they tend to hit the ball flat. It works. If you work with a coach, they'll tell you the right way to hit the ball back is to loop. It takes longer for someone self-taught to learn to loop than for someone who picked up the paddle yesterday. Not because the beginner is better, but because they don't have many years of a very fast, very confident answer to "the ball is coming."

Muscle memory isn't only in your muscles. Everyone these days is measuring how fast they learn new things. Nobody's measuring how fast they let go. Learning velocity is not the constraint these days. Unlearning definitely is. And what's worse is that the cost scales with how good you were in the first place. A skill you've honed isn't knowledge you can go edit. It's compiled. It fires before you decide anything, and under pressure you revert. The moment you most need the new thing is the moment you're least likely to do it.

Take debugging and incidents as an example. Something breaks. You open the file and read. Stack trace, hypothesis, print statements, narrow it down. That was right for many years, because reading was the cheapest way to build the mental model. In an AI-first world, the right thing to do is describe the symptom, get some candidates, check them. Maybe build a system that does this automatically so you don't need to hold the whole thing in your head. Nobody defends reading-first on cost grounds. They defend it as rigor. Asking first feels like cheating. The reflex isn't wrong, sometimes the mental model is the deliverable. But it's unconditional. It fires when the model is worth building and when it isn't, and it can't tell the difference.

Sometimes the reflex is a much larger part of the whole job. Say you’re a PM. For years you wrote comprehensive docs and got people aligned on what to build, because building was expensive. You didn’t just write PRDs, you became someone known for writing them well. Now you’re expected to produce prototypes instead. The reflex to an idea has to change from doing research to building three versions and putting them in front of customers as early as possible. What you defended as craft matters a lot less than it used to.

The worst kind of unlearning is something you just spent time getting good at. When Cursor showed up, a lot of engineers spent months learning to use it well. When Claude Code appeared, the ones who wanted to stay at the frontier had to unlearn all of it. That happened in under six months. In the next six, the people who’ve honed their Claude Code setup will likely need to move to something else entirely. The half-life of the technique is shorter than the time it takes to get good at it.

You can’t (and shouldn’t) unlearn everything. Everyone has met the person who chases every shiny new release and has no depth. They’re not winning either. The hardest part isn’t learning how to unlearn — it’s knowing what to keep and what to give up.

One thing I’ve found helpful is asking what the underlying constraint was. Most techniques are a response to something being expensive. Reading code was “building context is expensive.” The PRD is “building products is expensive.” So ask whether the constraint still exists. If it’s gone, the technique goes with it. If there was never a constraint, just “otherwise it’s bad” — that’s taste. Keep it. Taste is what survives infinite compute.