{"course":{"slug":"how-software-changed","title":"How Software Development Changed","url":"https://addaly.com/learn/how-software-changed","level":"intermediate","track":"work"},"lesson":{"slug":"practising-with-the-answer-available","title":"Practising when the answer is one keystroke away","url":"https://addaly.com/learn/how-software-changed/practising-with-the-answer-available","position":64,"of":87,"minutes":9,"answer":"Design practice that pays off immediately as well as eventually: predicting the branches before generating catches bugs today and forces retrieval at the same time.","keyIdea":"Design practice that pays off immediately as well as eventually: predicting the branches before generating catches bugs today and forces retrieval at the same time, which is why it survives a deadline when abstinence does not."},"body":{"format":"markdown","text":"## The problem with \"just turn it off\"\n\nThe 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.\n\nSo 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.\n\n## Predict, then generate\n\nBefore you ask, write the shape you expect. In a comment, in the file you are already in.\n\n```python\n# expect: (path: str, limit: int = 100) -> list[Record]\n# branches: file missing -> raise; empty file -> []; limit <= 0 -> ValueError\n# unsure: what happens on a malformed row halfway through?\n```\n\nThen generate, then compare. Cost: about two minutes.\n\nThree 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.\n\nThe `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.\n\n## Reconstruct from memory\n\nOnce a week, take a function you accepted three or four days ago. Delete it. Rewrite it without looking. Then diff.\n\nThis 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.\n\n## Read the thing it used\n\nWhen 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.\n\nThis 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.\n\n## Interleave instead of blocking\n\nFrom 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.\n\n## One tool-free window, treated as a measurement\n\nOne session a week (ninety minutes is enough) with completion and chat closed. Not as penance. As an instrument.\n\nWhat 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.\n\n## Keep a written list of what surprised you\n\nOne 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.\"\n\nThis 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.\n\n## The limitation\n\nNone 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.\n\nWhat 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."},"check":{"question":"Why is predict-then-generate recommended above a weekly tool-free session for most people?","options":[{"text":"It exercises recall more thoroughly, because writing a comment demands more precision than writing working code.","correct":false,"tempting":"Writing working code demands more retrieval than a comment; the comment's advantage is not depth."},{"text":"It avoids the productivity loss of working unassisted, so managers are more likely to permit it.","correct":false,"tempting":"Frames it as a political compromise; the reason is about which habits persist, not who approves them."},{"text":"It produces an immediate benefit (bugs caught before the tests run) so it survives deadline pressure.","correct":true},{"text":"Tool-free sessions build habits that break down as soon as the tools are switched back on, making them worthless.","correct":false,"tempting":"Overstates it: the tool-free session is recommended too, as a measurement rather than as training."}]},"prev":{"slug":"what-stays-worth-learning","title":"The layer that does not get cheaper","url":"https://addaly.com/learn/how-software-changed/what-stays-worth-learning"},"next":{"slug":"rebuilding-the-apprenticeship","title":"Tasks that are still expensive to generate","url":"https://addaly.com/learn/how-software-changed/rebuilding-the-apprenticeship"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Practising when the answer is one keystroke away', in How Software Development Changed. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/how-software-changed/practising-with-the-answer-available (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Practising when the answer is one keystroke away","courseTitle":"How Software Development Changed","module":{"index":7,"slug":"skill-and-the-missing-rung","title":"Skill, hiring and the missing rung"},"answer":null,"keyIdea":"Design practice that pays off immediately as well as eventually: predicting the branches before generating catches bugs today and forces retrieval at the same time, which is why it survives a deadline when abstinence does not.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"the-problem-with-just-turn-it-off","runs":[{"text":"The problem with “just turn it off”"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"predict-then-generate","runs":[{"text":"Predict, then generate"}]},{"t":"p","runs":[{"text":"Before you ask, write the shape you expect. In a comment, in the file you are already in."}]},{"t":"code","lang":"python","label":"Python","text":"# expect: (path: str, limit: int = 100) -> list[Record]\n# branches: file missing -> raise; empty file -> []; limit <= 0 -> ValueError\n# unsure: what happens on a malformed row halfway through?"},{"t":"p","runs":[{"text":"Then generate, then compare. Cost: about two minutes."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"The "},{"text":"unsure:","code":true},{"text":" 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."}]},{"t":"h2","id":"reconstruct-from-memory","runs":[{"text":"Reconstruct from memory"}]},{"t":"p","runs":[{"text":"Once a week, take a function you accepted three or four days ago. Delete it. Rewrite it without looking. Then diff."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"read-the-thing-it-used","runs":[{"text":"Read the thing it used"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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 "},{"text":"None","code":true},{"text":", 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."}]},{"t":"h2","id":"interleave-instead-of-blocking","runs":[{"text":"Interleave instead of blocking"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"one-tool-free-window-treated-as-a-measurement","runs":[{"text":"One tool-free window, treated as a measurement"}]},{"t":"p","runs":[{"text":"One session a week (ninety minutes is enough) with completion and chat closed. Not as penance. As an instrument."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"keep-a-written-list-of-what-surprised-you","runs":[{"text":"Keep a written list of what surprised you"}]},{"t":"p","runs":[{"text":"One line per surprise, in a file in the repository. “Thought "},{"text":"datetime.utcnow()","code":true},{"text":" was timezone-aware. It is not.” “Assumed the retry wrapper was idempotent. It was not.”"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"the-limitation","runs":[{"text":"The limitation"}],"role":"limit"},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]}],"check":{"question":[{"text":"Why is predict-then-generate recommended above a weekly tool-free session for most people?"}],"options":[{"text":[{"text":"It exercises recall more thoroughly, because writing a comment demands more precision than writing working code."}],"correct":false,"tempting":[{"text":"Writing working code demands more retrieval than a comment; the comment’s advantage is not depth."}]},{"text":[{"text":"It avoids the productivity loss of working unassisted, so managers are more likely to permit it."}],"correct":false,"tempting":[{"text":"Frames it as a political compromise; the reason is about which habits persist, not who approves them."}]},{"text":[{"text":"It produces an immediate benefit (bugs caught before the tests run) so it survives deadline pressure."}],"correct":true,"tempting":null},{"text":[{"text":"Tool-free sessions build habits that break down as soon as the tools are switched back on, making them worthless."}],"correct":false,"tempting":[{"text":"Overstates it: the tool-free session is recommended too, as a measurement rather than as training."}]}],"order":[3,1,2,0],"why":null},"prev":{"slug":"what-stays-worth-learning","title":"The layer that does not get cheaper","minutes":10},"next":{"slug":"rebuilding-the-apprenticeship","title":"Tasks that are still expensive to generate","minutes":10}}}