{"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-perception-gap","title":"Why it feels faster than it measures","url":"https://addaly.com/learn/how-software-changed/the-perception-gap","position":5,"of":87,"minutes":8,"answer":"Felt speed and measured speed diverge because waiting is not remembered as effort and debugging is charged to a different account.","keyIdea":"Felt speed and measured speed diverge because waiting is not remembered as effort and debugging is charged to a different account, so decisions about how a team works need a clock and a defect count rather than an impression."},"body":{"format":"markdown","text":"## The finding worth sitting with\n\nIn the METR trial, the participants were slower by about 19% and believed afterwards that they had been faster by about 20%. These were experienced engineers, working on their own repositories, who had just lived through every minute of it. The gap is roughly forty percentage points, in the direction of flattering the tool, in people with every reason and every opportunity to notice.\n\nIf they could not tell, your impression is not evidence either. That is uncomfortable and it is the point of this lesson. What follows is the mechanism, because knowing why the illusion happens is the only way to work around it.\n\n## Five mechanisms, all of them ordinary\n\n**Waiting is not remembered as work.** Forty minutes of typing registers as forty minutes of effort. Forty minutes of prompt, wait, skim, reject, re-prompt registers as much less, because effort is intermittent and each cycle is short. Elapsed time is identical. Remembered exertion is not, and people estimate duration from remembered exertion.\n\n**Struggle is the thing that gets filed as cost.** The memory of the afternoon lost to a stack trace is vivid and expensive. Its absence reads directly as speed. But not being stuck is not the same as being finished, and the tasks where you were never stuck may still have taken longer end to end.\n\n**Debug time is charged to the wrong account.** The two hours spent on Thursday tracing a double charge does not get filed under Tuesday's generated retry decorator. It gets filed under *billing bug*. Every accounting system, formal or mental, that separates production from consequences will overstate production.\n\n**The wins are memorable and the losses are boring.** When it works, it works spectacularly: a 200-line module in ninety seconds. When it fails, it fails as a slow drip: a wrong assumption you argue with for twenty minutes, a subtly wrong import, an approach you abandon. Availability bias does the rest. Ask anyone for an example and you will get the spectacular win, because that is what is retrievable.\n\n**The demo is not the feature.** The first 80% arrives immediately and looks like the whole thing. Completion is estimated from what is visible, and what is visible is disproportionately the easy part. This one distorts estimates as well as impressions, and it gets its own treatment later in the course.\n\n## What actually to do about it\n\nStop trying to feel more accurately. It does not work; that is what the trial shows.\n\n**Measure elapsed clock time on real tasks, to the right end point.** Not \"until the code was written\": until it was merged, green in CI, and deployed. Most of the divergence between feeling and reality lives after the code was written, so a measurement that stops there is measuring the wrong segment on purpose.\n\n**Randomise per task, not per week.** If you do assisted work on Mondays and unassisted work on Fridays, you have measured Mondays. Flip a coin per task. It feels absurd and it is the whole of the method.\n\n**Follow the change for thirty days.** Count anything that came back: a follow-up commit, a reverted deploy, a bug report, an incident. Speed without this is not a result.\n\n**Write your prediction down first.** Before the fortnight, write what you expect and what result would change your behaviour. Comparing the prediction with the outcome is the cheapest calibration exercise available, and it is the exact thing the METR participants could not do retrospectively.\n\n## The counterpoint, stated properly\n\nHere is where a lot of writing on this subject goes wrong. It treats the perception gap as proof that the felt benefit is fake. It is not.\n\nLower cognitive load has real value that a stopwatch does not capture. Fatigue is a genuine constraint on a working day, and a tool that leaves you with more attention at 4pm has produced something, even if the morning's tasks took the same time. So has a tool that makes you willing to write the boring migration script on Friday afternoon rather than postponing it to a Monday that never comes. Work you would not otherwise have done at all does not show up as a speed-up on any task, and it can be the largest effect in practice.\n\nThe honest position is two-sided. Your impression of speed is unreliable and should not be the basis of a decision about how a team works. Your impression of strain is much more reliable, because you are the only instrument for it, and it measures something that matters.\n\nKeep both. Distrust the first, record the second, and let the clock settle the argument about time."},"check":{"question":"A developer logs task times for two weeks: assisted work on Mondays and Tuesdays, unassisted on Thursdays and Fridays. Assisted tasks come out 20% faster. Why is this a weak result even though the times were genuinely measured?","options":[{"text":"Two weeks is too short a window; the same design run over three months would give a trustworthy answer.","correct":false,"tempting":"Treats a design flaw as a sample-size problem, so more data collected the same way just gives a tighter estimate of the same confounded quantity."},{"text":"Self-reported timing is unreliable, and the developer will have unconsciously rounded assisted tasks downward.","correct":false,"tempting":"Reaches for a measurement-honesty explanation when the times were recorded from a clock; the problem is what was allocated to which condition."},{"text":"Allocating by day means the comparison is between Mondays and Fridays as much as between tools.","correct":true},{"text":"Measuring to code-complete rather than to merged means the review time is missing from both arms of the comparison.","correct":false,"tempting":"Names a real flaw that would appear in this design, but it applies equally to both conditions, so it is not what makes the comparison uninterpretable."}]},"prev":{"slug":"reading-a-productivity-study","title":"How to read a claim about developer productivity","url":"https://addaly.com/learn/how-software-changed/reading-a-productivity-study"},"next":{"slug":"queues-not-speeds","title":"Queues, not speeds","url":"https://addaly.com/learn/how-software-changed/queues-not-speeds"},"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) 'Why it feels faster than it measures', in How Software Development Changed. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/how-software-changed/the-perception-gap (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":"Why it feels faster than it measures","courseTitle":"How Software Development Changed","module":{"index":1,"slug":"where-the-cost-went","title":"Where the cost actually went"},"answer":null,"keyIdea":"Felt speed and measured speed diverge because waiting is not remembered as effort and debugging is charged to a different account, so decisions about how a team works need a clock and a defect count rather than an impression.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"the-finding-worth-sitting-with","runs":[{"text":"The finding worth sitting with"}]},{"t":"p","runs":[{"text":"In the METR trial, the participants were slower by about 19% and believed afterwards that they had been faster by about 20%. These were experienced engineers, working on their own repositories, who had just lived through every minute of it. The gap is roughly forty percentage points, in the direction of flattering the tool, in people with every reason and every opportunity to notice."}]},{"t":"p","runs":[{"text":"If they could not tell, your impression is not evidence either. That is uncomfortable and it is the point of this lesson. What follows is the mechanism, because knowing why the illusion happens is the only way to work around it."}]},{"t":"h2","id":"five-mechanisms-all-of-them-ordinary","runs":[{"text":"Five mechanisms, all of them ordinary"}]},{"t":"p","runs":[{"text":"Waiting is not remembered as work.","b":true},{"text":" Forty minutes of typing registers as forty minutes of effort. Forty minutes of prompt, wait, skim, reject, re-prompt registers as much less, because effort is intermittent and each cycle is short. Elapsed time is identical. Remembered exertion is not, and people estimate duration from remembered exertion."}]},{"t":"p","runs":[{"text":"Struggle is the thing that gets filed as cost.","b":true},{"text":" The memory of the afternoon lost to a stack trace is vivid and expensive. Its absence reads directly as speed. But not being stuck is not the same as being finished, and the tasks where you were never stuck may still have taken longer end to end."}]},{"t":"p","runs":[{"text":"Debug time is charged to the wrong account.","b":true},{"text":" The two hours spent on Thursday tracing a double charge does not get filed under Tuesday’s generated retry decorator. It gets filed under "},{"text":"billing bug","i":true},{"text":". Every accounting system, formal or mental, that separates production from consequences will overstate production."}]},{"t":"p","runs":[{"text":"The wins are memorable and the losses are boring.","b":true},{"text":" When it works, it works spectacularly: a 200-line module in ninety seconds. When it fails, it fails as a slow drip: a wrong assumption you argue with for twenty minutes, a subtly wrong import, an approach you abandon. Availability bias does the rest. Ask anyone for an example and you will get the spectacular win, because that is what is retrievable."}]},{"t":"p","runs":[{"text":"The demo is not the feature.","b":true},{"text":" The first 80% arrives immediately and looks like the whole thing. Completion is estimated from what is visible, and what is visible is disproportionately the easy part. This one distorts estimates as well as impressions, and it gets its own treatment later in the course."}]},{"t":"h2","id":"what-actually-to-do-about-it","runs":[{"text":"What actually to do about it"}]},{"t":"p","runs":[{"text":"Stop trying to feel more accurately. It does not work; that is what the trial shows."}]},{"t":"p","runs":[{"text":"Measure elapsed clock time on real tasks, to the right end point.","b":true},{"text":" Not “until the code was written”: until it was merged, green in CI, and deployed. Most of the divergence between feeling and reality lives after the code was written, so a measurement that stops there is measuring the wrong segment on purpose."}]},{"t":"p","runs":[{"text":"Randomise per task, not per week.","b":true},{"text":" If you do assisted work on Mondays and unassisted work on Fridays, you have measured Mondays. Flip a coin per task. It feels absurd and it is the whole of the method."}]},{"t":"p","runs":[{"text":"Follow the change for thirty days.","b":true},{"text":" Count anything that came back: a follow-up commit, a reverted deploy, a bug report, an incident. Speed without this is not a result."}]},{"t":"p","runs":[{"text":"Write your prediction down first.","b":true},{"text":" Before the fortnight, write what you expect and what result would change your behaviour. Comparing the prediction with the outcome is the cheapest calibration exercise available, and it is the exact thing the METR participants could not do retrospectively."}]},{"t":"h2","id":"the-counterpoint-stated-properly","runs":[{"text":"The counterpoint, stated properly"}]},{"t":"p","runs":[{"text":"Here is where a lot of writing on this subject goes wrong. It treats the perception gap as proof that the felt benefit is fake. It is not."}]},{"t":"p","runs":[{"text":"Lower cognitive load has real value that a stopwatch does not capture. Fatigue is a genuine constraint on a working day, and a tool that leaves you with more attention at 4pm has produced something, even if the morning’s tasks took the same time. So has a tool that makes you willing to write the boring migration script on Friday afternoon rather than postponing it to a Monday that never comes. Work you would not otherwise have done at all does not show up as a speed-up on any task, and it can be the largest effect in practice."}]},{"t":"p","runs":[{"text":"The honest position is two-sided. Your impression of speed is unreliable and should not be the basis of a decision about how a team works. Your impression of strain is much more reliable, because you are the only instrument for it, and it measures something that matters."}]},{"t":"p","runs":[{"text":"Keep both. Distrust the first, record the second, and let the clock settle the argument about time."}]}],"check":{"question":[{"text":"A developer logs task times for two weeks: assisted work on Mondays and Tuesdays, unassisted on Thursdays and Fridays. Assisted tasks come out 20% faster. Why is this a weak result even though the times were genuinely measured?"}],"options":[{"text":[{"text":"Two weeks is too short a window; the same design run over three months would give a trustworthy answer."}],"correct":false,"tempting":[{"text":"Treats a design flaw as a sample-size problem, so more data collected the same way just gives a tighter estimate of the same confounded quantity."}]},{"text":[{"text":"Self-reported timing is unreliable, and the developer will have unconsciously rounded assisted tasks downward."}],"correct":false,"tempting":[{"text":"Reaches for a measurement-honesty explanation when the times were recorded from a clock; the problem is what was allocated to which condition."}]},{"text":[{"text":"Allocating by day means the comparison is between Mondays and Fridays as much as between tools."}],"correct":true,"tempting":null},{"text":[{"text":"Measuring to code-complete rather than to merged means the review time is missing from both arms of the comparison."}],"correct":false,"tempting":[{"text":"Names a real flaw that would appear in this design, but it applies equally to both conditions, so it is not what makes the comparison uninterpretable."}]}],"order":[0,2,3,1],"why":null},"prev":{"slug":"reading-a-productivity-study","title":"How to read a claim about developer productivity","minutes":10},"next":{"slug":"queues-not-speeds","title":"Queues, not speeds","minutes":10}}}