Practising when the answer is one keystroke away

The problem with “just turn it off”

The standard advice is to practise without assistance. It fails for a reason worth naming: it asks you to be slower at a job measured on output, with the payoff arriving in a year, and no way to tell whether it is working. Advice that relies entirely on willpower against a live incentive does not survive a quarter.

So the protocols below are built to fit inside real work, to cost minutes rather than hours, and, where possible, to pay for themselves immediately by catching bugs, so that they survive a deadline.

Predict, then generate

Before you ask, write the shape you expect. In a comment, in the file you are already in.

# expect: (path: str, limit: int = 100) -> list[Record]
# branches: file missing -> raise; empty file -> []; limit <= 0 -> ValueError
# unsure: what happens on a malformed row halfway through?

Then generate, then compare. Cost: about two minutes.

Three things can come back. The model handled a case you did not think of, which is a gap in your model of the problem. You expected a case the model dropped, which is a probable bug found before the tests ran. Or you matched, and you have bought confidence cheaply.

The unsure: line is the most valuable one. It is the question you would otherwise not have noticed you were not asking, and it is usually where the real decision lives.

Reconstruct from memory

Once a week, take a function you accepted three or four days ago. Delete it. Rewrite it without looking. Then diff.

This is unpleasant in a specific, informative way. People are routinely unable to reproduce code they approved days earlier and would have sworn they understood. That reaction is the measurement: it is not a failure of the exercise, it is the exercise working.

Read the thing it used

When generated code calls an API you do not know, spend five minutes in the actual documentation for that call. Not an explanation of it: the reference page.

This is the highest-yield habit on the list, because it is where the specific, checkable facts live: that this function raises rather than returning None, that the default timeout is infinite, that the parameter is seconds and not milliseconds, that it was deprecated two versions ago. A generator will describe an API confidently in the shape APIs usually have. The reference page is the ground truth, it takes five minutes, and it is free.

Interleave instead of blocking

From the learning literature: practising one kind of problem twenty times in a row produces better performance today and worse retention later than mixing kinds. Applied here: do not spend a week generating twenty endpoints. Alternate: an endpoint, a bug in someone else’s module, a performance question, a schema change. The switching cost is real and so is the retention.

One tool-free window, treated as a measurement

One session a week (ninety minutes is enough) with completion and chat closed. Not as penance. As an instrument.

What you are measuring is specific: how often you reach for a function whose name you no longer hold, how long it takes to get moving from an empty file, whether you can still write a test before the code. These are readings, and the trend over a few months tells you more than any single session.

Keep a written list of what surprised you

One line per surprise, in a file in the repository. “Thought datetime.utcnow() was timezone-aware. It is not.” “Assumed the retry wrapper was idempotent. It was not.”

This is the cheapest item here and the one people abandon fastest. Its value is that surprises repeat: the same category of wrong assumption comes back in a new costume, and a list of twenty of them is a personal map of where your model of the world is thin. Anki will drill them for free if you want the spaced-repetition version.

The limitation

None of these protocols has been evaluated. They are adapted from retrieval practice, interleaving and self-explanation studies conducted on other subjects, and assembled by reasoning about the mechanism. There is no trial showing that predict-then-generate improves programmer skill retention, because no such trial exists.

What can be said is narrower and still worth something: predict-then-generate catches real bugs today, whatever it does for your long-term skill. That is why it is first on the list. A practice that only pays off in a year will be dropped; one that pays this afternoon survives.