{"course":{"slug":"how-software-changed","title":"How Software Development Changed","url":"https://addaly.com/learn/how-software-changed","level":"intermediate","track":"work"},"lesson":{"slug":"the-competence-illusion","title":"A five-minute test for whether you understood it","url":"https://addaly.com/learn/how-software-changed/the-competence-illusion","position":62,"of":87,"minutes":9,"answer":"Confidence tracks how fluently something reads rather than whether you could reproduce it, so the only reliable check is to close the file and attempt the explanation.","keyIdea":"Confidence tracks how fluently something reads rather than whether you could reproduce it, so the only reliable check is to close the file and attempt the explanation, and the cheapest version of that is predicting the branches before you generate."},"body":{"format":"markdown","text":"## The illusion has a name and a measurement\n\nRozenblit and Keil, 2002. Ask people to rate, on a seven-point scale, how well they understand how a zip fastener works. Then ask them to write a step-by-step causal explanation. Then ask them to re-rate. The ratings drop, reliably, across zips, flush toilets, bicycles, helicopters and government policies. They called it the **illusion of explanatory depth**: familiarity with a thing gets mistaken for a model of it.\n\nThe drop happens at the moment of attempted explanation, not at the moment of being told the answer. That detail is what makes it useful to you. You do not need anyone to grade you. Producing the explanation is itself the test.\n\n## Why polished code triggers it harder\n\nProcessing fluency, how easily something goes down, is a cue people use for confidence, and it is a bad cue. Text in a clear font is judged more truthful than the same text in a degraded one. Consistent naming, tidy structure and no dead ends all raise fluency.\n\nGenerated code is uniformly fluent. It does not have the hesitations of human code: the variable renamed halfway through, the comment that contradicts the line below it, the leftover branch from an earlier approach. Those artefacts are friction, and friction is what used to make you stop and think. Their absence is not a sign of correctness. It is a sign that the text was produced in one pass by something with no doubts.\n\nSo you get high fluency with no relationship to your own understanding, and your confidence reads the fluency.\n\n## The test, concretely\n\nFive minutes, no tooling. Run it on a change you are about to approve or submit.\n\n1. **Close the file.** Not minimise: close.\n2. **Write the signature from memory.** Name, parameters, return type, and what it does when it fails.\n3. **Name the branches.** How many paths through this function, and what distinguishes them?\n4. **Answer three input questions without looking.** Empty input. Input at the boundary: zero, one, the maximum. Input that is valid but adversarial: the duplicate, the negative, the unicode name, the clock going backwards.\n5. **Open the file and diff your answers against it.**\n\nIf you cannot do step 2, you have read the code, not understood it. That is a fine place to be: it just means you are not yet in a position to approve it or to rely on it.\n\n> Figure: Five minutes, before you approve it. Steps: 1. Close the file (Not minimise. Close.); 2. Write the signature from memory (Name, parameters, return type, and what it does when it fails.); 3. Name the branches (How many paths are there through this function, and what distinguishes them?); 4. Answer three input questions (Empty. At the boundary: zero, one, the maximum. Valid but adversarial: the duplicate, the negative, the clock going backwards.); 5. Open the file and diff your answers (Failing at step two means you have read the code rather than understood it, which is a fine place to be and not a place to approve from.). The confidence drop happens at the moment of attempted explanation, not at the moment of being told the answer. So producing the explanation is itself the test, and nobody has to grade it.\n\n## The prediction variant, which costs less\n\nThe test above is retrospective. The cheaper version runs before you generate.\n\nWrite the function signature and a comment naming the branches you expect. Then generate. Then diff your comment against the output. Two minutes.\n\nThe diff has three interesting shapes. The model handled a case you missed: that is a gap in your model of the problem, and worth thirty seconds of thought about why you missed it. You expected a case the model did not handle: that is a probable bug, and you found it before the tests ran. Or the two match, in which case you have confirmed your understanding cheaply and can move on quickly with good reason.\n\n## Signals you can check in the moment\n\nA few questions that surface the illusion without a formal drill:\n\n- Can you say why **this** approach and not the obvious alternative? If the only answer is \"it works\", you have an outcome, not a reason.\n- Can you predict the failure? \"If the network is slow here, the user sees...\": if you cannot finish that sentence, you do not know what you are shipping.\n- Could you make a deliberate one-line change that breaks it in a specific, predicted way? This is the sharpest test of all, and it is exactly what mutation testing automates.\n\n## The honest limitations\n\nThe explanatory-depth work was done on household objects and policy questions, not on code. Nobody has demonstrated the effect in a programming context with a controlled study. The transfer is an argument, not a finding.\n\nAnd the drills have a real cost. Five minutes a change, on twenty changes a week, is a working hour and a half. Under a deadline this is the first thing dropped, every time, in every team. Pretending otherwise is how good practices get written down and never done. If you can only afford one, take the two-minute prediction variant, because it pays for itself by catching bugs as well as calibrating you.\n\n> You do not need to feel confused to be confused. That was always true. What changed is that the code in front of you no longer contains any of the evidence."},"check":{"question":"Why does the illusion of explanatory depth bite harder on generated code than on a colleague's hand-written code of similar quality?","options":[{"text":"Generated code is longer on average, so there is more surface for a reader to skim without noticing.","correct":false,"tempting":"Attributes it to volume, but the effect appears on a fifteen-line generated function too."},{"text":"Hand-written code carries friction (renamings, stale comments, dead branches) and friction made readers stop.","correct":true},{"text":"Readers trust human authors less, so they scrutinise human code more carefully out of suspicion.","correct":false,"tempting":"Inverts the usual finding: readers typically extend more trust to a known colleague, not less."},{"text":"Generated code uses APIs the reader has not seen before, which creates an unfamiliarity the reader mistakes for depth.","correct":false,"tempting":"Unfamiliar APIs reduce fluency and therefore reduce the illusion rather than causing it."}]},"prev":{"slug":"how-skill-forms","title":"Why the hard part was the part that taught you","url":"https://addaly.com/learn/how-software-changed/how-skill-forms"},"next":{"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"},"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) 'A five-minute test for whether you understood it', in How Software Development Changed. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/how-software-changed/the-competence-illusion (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":"A five-minute test for whether you understood it","courseTitle":"How Software Development Changed","module":{"index":7,"slug":"skill-and-the-missing-rung","title":"Skill, hiring and the missing rung"},"answer":null,"keyIdea":"Confidence tracks how fluently something reads rather than whether you could reproduce it, so the only reliable check is to close the file and attempt the explanation, and the cheapest version of that is predicting the branches before you generate.","hero":{"kind":"figure","figure":{"t":"figure","label":"Figure","figure":{"type":"flow","steps":[{"label":"Close the file","detail":"Not minimise. Close."},{"label":"Write the signature from memory","detail":"Name, parameters, return type, and what it does when it fails."},{"label":"Name the branches","detail":"How many paths are there through this function, and what distinguishes them?"},{"label":"Answer three input questions","detail":"Empty. At the boundary: zero, one, the maximum. Valid but adversarial: the duplicate, the negative, the clock going backwards."},{"label":"Open the file and diff your answers","detail":"Failing at step two means you have read the code rather than understood it, which is a fine place to be and not a place to approve from."}],"title":"Five minutes, before you approve it","caption":"The confidence drop happens at the moment of attempted explanation, not at the moment of being told the answer. So producing the explanation is itself the test, and nobody has to grade it."},"alt":"Figure: Five minutes, before you approve it. Steps: 1. Close the file (Not minimise. Close.); 2. Write the signature from memory (Name, parameters, return type, and what it does when it fails.); 3. Name the branches (How many paths are there through this function, and what distinguishes them?); 4. Answer three input questions (Empty. At the boundary: zero, one, the maximum. Valid but adversarial: the duplicate, the negative, the clock going backwards.); 5. Open the file and diff your answers (Failing at step two means you have read the code rather than understood it, which is a fine place to be and not a place to approve from.). The confidence drop happens at the moment of attempted explanation, not at the moment of being told the answer. So producing the explanation is itself the test, and nobody has to grade it."}},"blocks":[{"t":"h2","id":"the-illusion-has-a-name-and-a-measurement","runs":[{"text":"The illusion has a name and a measurement"}]},{"t":"p","runs":[{"text":"Rozenblit and Keil, 2002. Ask people to rate, on a seven-point scale, how well they understand how a zip fastener works. Then ask them to write a step-by-step causal explanation. Then ask them to re-rate. The ratings drop, reliably, across zips, flush toilets, bicycles, helicopters and government policies. They called it the "},{"text":"illusion of explanatory depth","b":true},{"text":": familiarity with a thing gets mistaken for a model of it."}]},{"t":"p","runs":[{"text":"The drop happens at the moment of attempted explanation, not at the moment of being told the answer. That detail is what makes it useful to you. You do not need anyone to grade you. Producing the explanation is itself the test."}]},{"t":"h2","id":"why-polished-code-triggers-it-harder","runs":[{"text":"Why polished code triggers it harder"}]},{"t":"p","runs":[{"text":"Processing fluency, how easily something goes down, is a cue people use for confidence, and it is a bad cue. Text in a clear font is judged more truthful than the same text in a degraded one. Consistent naming, tidy structure and no dead ends all raise fluency."}]},{"t":"p","runs":[{"text":"Generated code is uniformly fluent. It does not have the hesitations of human code: the variable renamed halfway through, the comment that contradicts the line below it, the leftover branch from an earlier approach. Those artefacts are friction, and friction is what used to make you stop and think. Their absence is not a sign of correctness. It is a sign that the text was produced in one pass by something with no doubts."}]},{"t":"p","runs":[{"text":"So you get high fluency with no relationship to your own understanding, and your confidence reads the fluency."}]},{"t":"h2","id":"the-test-concretely","runs":[{"text":"The test, concretely"}]},{"t":"p","runs":[{"text":"Five minutes, no tooling. Run it on a change you are about to approve or submit."}]},{"t":"ol","start":1,"items":[[{"text":"Close the file.","b":true},{"text":" Not minimise: close."}],[{"text":"Write the signature from memory.","b":true},{"text":" Name, parameters, return type, and what it does when it fails."}],[{"text":"Name the branches.","b":true},{"text":" How many paths through this function, and what distinguishes them?"}],[{"text":"Answer three input questions without looking.","b":true},{"text":" Empty input. Input at the boundary: zero, one, the maximum. Input that is valid but adversarial: the duplicate, the negative, the unicode name, the clock going backwards."}],[{"text":"Open the file and diff your answers against it.","b":true}]]},{"t":"p","runs":[{"text":"If you cannot do step 2, you have read the code, not understood it. That is a fine place to be: it just means you are not yet in a position to approve it or to rely on it."}]},{"t":"h2","id":"the-prediction-variant-which-costs-less","runs":[{"text":"The prediction variant, which costs less"}]},{"t":"p","runs":[{"text":"The test above is retrospective. The cheaper version runs before you generate."}]},{"t":"p","runs":[{"text":"Write the function signature and a comment naming the branches you expect. Then generate. Then diff your comment against the output. Two minutes."}]},{"t":"p","runs":[{"text":"The diff has three interesting shapes. The model handled a case you missed: that is a gap in your model of the problem, and worth thirty seconds of thought about why you missed it. You expected a case the model did not handle: that is a probable bug, and you found it before the tests ran. Or the two match, in which case you have confirmed your understanding cheaply and can move on quickly with good reason."}]},{"t":"h2","id":"signals-you-can-check-in-the-moment","runs":[{"text":"Signals you can check in the moment"}]},{"t":"p","runs":[{"text":"A few questions that surface the illusion without a formal drill:"}]},{"t":"ul","items":[[{"text":"Can you say why "},{"text":"this","b":true},{"text":" approach and not the obvious alternative? If the only answer is “it works”, you have an outcome, not a reason."}],[{"text":"Can you predict the failure? “If the network is slow here, the user sees...”: if you cannot finish that sentence, you do not know what you are shipping."}],[{"text":"Could you make a deliberate one-line change that breaks it in a specific, predicted way? This is the sharpest test of all, and it is exactly what mutation testing automates."}]]},{"t":"h2","id":"the-honest-limitations","runs":[{"text":"The honest limitations"}],"role":"limit"},{"t":"p","runs":[{"text":"The explanatory-depth work was done on household objects and policy questions, not on code. Nobody has demonstrated the effect in a programming context with a controlled study. The transfer is an argument, not a finding."}]},{"t":"p","runs":[{"text":"And the drills have a real cost. Five minutes a change, on twenty changes a week, is a working hour and a half. Under a deadline this is the first thing dropped, every time, in every team. Pretending otherwise is how good practices get written down and never done. If you can only afford one, take the two-minute prediction variant, because it pays for itself by catching bugs as well as calibrating you."}]},{"t":"quote","runs":[{"text":"You do not need to feel confused to be confused. That was always true. What changed is that the code in front of you no longer contains any of the evidence."}]}],"check":{"question":[{"text":"Why does the illusion of explanatory depth bite harder on generated code than on a colleague’s hand-written code of similar quality?"}],"options":[{"text":[{"text":"Generated code is longer on average, so there is more surface for a reader to skim without noticing."}],"correct":false,"tempting":[{"text":"Attributes it to volume, but the effect appears on a fifteen-line generated function too."}]},{"text":[{"text":"Hand-written code carries friction (renamings, stale comments, dead branches) and friction made readers stop."}],"correct":true,"tempting":null},{"text":[{"text":"Readers trust human authors less, so they scrutinise human code more carefully out of suspicion."}],"correct":false,"tempting":[{"text":"Inverts the usual finding: readers typically extend more trust to a known colleague, not less."}]},{"text":[{"text":"Generated code uses APIs the reader has not seen before, which creates an unfamiliarity the reader mistakes for depth."}],"correct":false,"tempting":[{"text":"Unfamiliar APIs reduce fluency and therefore reduce the illusion rather than causing it."}]}],"order":[2,0,3,1],"why":null},"prev":{"slug":"how-skill-forms","title":"Why the hard part was the part that taught you","minutes":9},"next":{"slug":"what-stays-worth-learning","title":"The layer that does not get cheaper","minutes":10}}}