Desirable Difficulty & Productive Struggle

Robert Bjork's principle that certain effortful obstacles in learning (spacing, interleaving, retrieval, generation) slow acquisition but deepen retention and transfer — the effort is the mechanism, not a flaw — which is why AI's removal of difficulty threatens the learning it appears to assist.

Also known as: desirable difficulties, ønskelige vanskeligheter, productive struggle, generation effect, retrieval practice, spacing effect, effortful learning, the effort is the mechanism

Part of: Learning Culture & Slack

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (9)

• The More Accessible Information Is, the Less Employees Remember Esther Kang · 2026-09-22 Reader 🖥️
  Because greater connectivity to people, platforms, and AI assistants makes employees measurably better at knowing who or what holds information and measurably worse at retaining the information itself -- even among their highest-capacity people -- leaders must stop treating findability as a proxy for learning and instead deliberately engineer work (explaining, applying, debating, teaching) that forces genuine internalization.
• Agentic Skill Decay AddyOsmani.com · 2026-08-31 source ↗ Reader 🖥️
  Agentic coding collapses the loop from problem to working patch so fast that it strips out the incidental struggle (debugging, reading diffs, forming and testing hypotheses) that used to build engineering expertise as a side effect of the work itself — so practitioners must now deliberately reinsert that practice, because the very expertise agents make optional is what increasingly determines whether you can verify and direct what an agent produces.
• Teaching Coding When AI Can Write the Code Eric Freeman · 2026-07-28 Reader 🖥️
  Because AI has severed the link between a finished piece of code and evidence of the student's understanding, coding education must shift its center of gravity from grading the finished artifact to making the process of thinking — explained, revised, and performed in public — the thing that is observed and assessed.
• Det skal være vanskelig Erik Børve Rasmussen · 2026-07-10 source ↗ Reader 🖥️
  Difficulty is the mechanism of learning, not a defect in it, so AI — a machine for removing difficulty — destroys learning wherever the process rather than the product was the whole point (school, unlike work); the remedy is therefore to redesign AI and assessment as skill-forcing 'simulators' rather than to ban them.
• The Pragmatic Engineer AMA The Pragmatic Engineer · 2026-07-08 Reader 🖥️
  Orosz's authority and judgment — on his own editorial choices, on hiring, on technology standards, and on AI adoption — consistently rest on direct, ground-level evidence and deliberate, revisable tradeoffs rather than on assumption, hype, or a fixed ideological stance.
• AI coding creates two kinds of debt. You're only measuring one Antonija Bilić Arar · 2026-06-18 source ↗ Reader 🖥️
  AI-generated code creates a second, largely invisible kind of debt — cognitive debt, the erosion of shared team understanding of what a system does and why, distinct from ordinary technical debt in the code itself — and it is a genuine measurement blind spot: satisfaction scores, NPS and mentor ratings can hold steady or rise while it accumulates, so organizations must replace satisfaction-based signals with trajectory-based skill measurement and deliberate team-level questions to catch it before it becomes irreversible.
• How I Use Agents Without Stopping My Own Growth Jared Currie · 2026-05-27 source ↗ Reader 🖥️
  Agentic coding tools are safe to lean on only if the developer deliberately keeps exercising the judgment they would otherwise outsource — by planning before delegating and reviewing generated code as if reconstructing its reasoning themselves — because the tools amplify whichever posture the developer brings to them.
• Our Favorite Management Tips on Giving Feedback HBR Editors · 2026-05-21 Reader 🖥️
  Feedback works when it separates the person from the behavior and is delivered inside a relationship the recipient already trusts: define what feedback must never do (attack character), structure it around a specific behavior plus its impact plus a next step, invite it proactively rather than only issuing it top-down, calibrate its intensity and timing to the relationship's maturity and the issue's severity, and treat it as a two-way, purpose-conferring conversation rather than a one-way verdict. The eight tips are different tactical answers to one underlying claim: feedback's effectiveness is gated by psychological safety and behavioral specificity, not by the giver's honesty or courage alone.
• How to Turn Individual Talent into Organizational Excellence Harvard Business Review · 2026-03-12 Reader 🖥️
  Sustained organizational excellence is produced not by individual talent, hiring, or motivation but by a deliberately designed system in which talent development, socially-enforced team standards, and disciplined recurring routines reinforce one another.

Propositions touching this concept (1)

By publication month, oldest first (extraction month when no publication date is known).

2026-07

• explicitestablishedBjork's 'desirable difficulties' mean the effort in learning is not a flaw but the mechanism — and AI is almost by definition a machine for removing effort.
  Det skal være vanskelig · p6

Open gaps (17)

• illogicalThe author asserts "the return on expertise is going up" with near-certainty, then two paragraphs later states "I don't know how long code-level expertise will remain as valuable as it is today. Models are improving too quickly for much certainty." These two claims sit in tension without being reconciled — the confident framing needs a time-horizon qualifier the piece never supplies.
  Agentic Skill Decay
• incompleteNo engagement with why this discipline is effortful or costly — the essay treats 'staying engaged' as simply a choice the author makes, without acknowledging that agents are explicitly designed to remove exactly this kind of friction, or that sustaining it under deadline pressure, fatigue, or high agent-output volume (many PRs, many agents running in parallel) may be much harder than the calm, first-person account suggests.
  How I Use Agents Without Stopping My Own Growth — read next: extract-det-skal-vaere-vanskelig (Bjork's desirable difficulties — the effort is the mechanism, not a flaw, and AI is close to a machine purpose-built for removing it) and extract-agentic-code-review (on review volume outpacing human capacity to sustain deep engagement at scale)
• incompleteThe article measures speed to a PR milestone but never addresses whether AI-accelerated onboarding produces developers who understand systems as deeply as those who onboarded more slowly. Faster PRs could mean shallower understanding, higher downstream rework, or increased dependence on AI as a crutch rather than developing genuine codebase knowledge. The article acknowledges this gap but treats it as a future research item rather than a fundamental limitation of the current finding.
  Developer ramp-up time continues to accelerate with AI — read next: Look for research on knowledge retention and long-term developer effectiveness when onboarding is AI-assisted vs. traditional. The Dreyfus skill acquisition model and research on desirable difficulties in learning suggest that compressing the 'figuring things out' phase may have hidden costs.
• incompleteThe three practices are validated only by the author's own uncontrolled classroom observation — no comparison group, no measured learning-outcome data, and no discussion of cost/scale requirements (small classes, an arts-department studio culture, custom-built chatbot avatars, TA availability for public critique) that make the approach hard to generalize to large, non-arts-adjacent CS programs.
  Teaching Coding When AI Can Write the Code — read next: Look for controlled or larger-N studies of process-based/performative assessment in programming education, and for follow-on evaluations of teachable-agent-as-assessor systems (extending Betty's Brain-style research to the assessor role rather than the tutee role).
• incompleteThe article's proposed replacement signal for 'code as reliable evidence of thinking' is the process trace itself (public explanation, live performance, AI-mediated conversation) — but it does not establish how durable this new signal is against its own future gaming: a rehearsed AI-coached explanation, a memorized live-coding routine, or answers effectively drafted by AI and read aloud in the chatbot conversation. It swaps one hard-to-fake signal for one whose own gaming-resistance is asserted, not demonstrated, and the reading direction implied by the source brief (what replaces code once code stops proving understanding) is left as an open empirical question rather than a settled design.
  Teaching Coding When AI Can Write the Code — read next: History and literature on the gaming and eventual erosion of other 'process' evidence forms (oral exams, viva voce, live demonstrations, in-person coding interviews) — do process-based signals have their own track record of being coached, memorized, or otherwise gamed over time?
• incompleteThe five experiments used simulated online communities and freshly presented, lab-constructed material with freshly formed connections -- not real workplace knowledge or the long-standing, trust-laden, expertise-asymmetric relationships that exist in actual organizations. The article does not address whether the tradeoff holds, strengthens, or weakens once relationships are established and repeatedly relied upon over years, as opposed to a single lab session.
  The More Accessible Information Is, the Less Employees Remember — read next: Look for field or longitudinal studies of transactive memory systems in real teams (the classical Wegner transactive-memory literature, or organizational studies of how expertise-location knowledge develops and is used over a team's lifespan).
• incompleteThe piece frames the connectivity tradeoff as a problem to be corrected, but never establishes that it is bad for team- or organization-level outcomes -- only that it changes what individuals remember. If knowledge is efficiently distributed and reliably retrievable through trusted people, that may be a feature of well-functioning distributed cognition rather than a deficit; no group- or organization-level performance comparison (only individual recall) is offered to settle this.
  The More Accessible Information Is, the Less Employees Remember — read next: Look for group-cognition or distributed-cognition research comparing team performance under high- versus low-connectivity/high- versus low-individual-retention conditions, not just individual memory outcomes.
• incompleteNo tip in the piece cites primary data, sample sizes, or effect sizes for its central claim, even where a named source is credited (e.g., Levitt et al. for midpoint timing, Wetzler for feedback-seeking culture). The reader is asked to trust the compiled prescription without being shown the evidence that presumably backs the original longer articles.
  Our Favorite Management Tips on Giving Feedback — read next: The full HBR source articles linked inline (Wetzler on feedback-seeking culture; Levitt et al. on early-positivity research; Hirsch on two-way feedback) for the underlying studies and their limitations.
• incompleteThe eight tips are never reconciled with each other where they could conflict: Tip 3 says withhold critique until midpoint; Tip 1's guardrails and Tip 7's conversational approach imply feedback can and should happen continuously and immediately when behavior needs correcting. A manager following the piece literally has no guidance on which tip governs an urgent, early-project problem.
  Our Favorite Management Tips on Giving Feedback — read next: Literature on feedback frequency and timing (e.g., continuous feedback vs. periodic review models) that would let a reader adjudicate when 'start with positivity, defer critique' should yield to 'address it now.'
• incompleteNone of the tips address feedback across power or identity asymmetries — feedback from a junior employee to a senior manager, cross-cultural feedback norms, or feedback where the recipient has structurally less power to push back or seek recourse if the giver's guardrails fail. The bias-auditing prescription in Tip 1 is the closest the piece comes, but it addresses giver bias, not the receiver's structural vulnerability.
  Our Favorite Management Tips on Giving Feedback — read next: Research on upward feedback, psychological safety across hierarchy, and cross-cultural management (e.g., Erin Meyer's work on feedback norms across cultures) would fill this.
• uninformedAs 'tip of the day' content compiled from separate prior articles, none of the eight tips engages with counter-evidence or failure modes of its own prescription — e.g., whether structured feedback templates can themselves feel bureaucratic and insincere, or whether a feedback-seeking culture can produce feedback fatigue or performative asking. The genre (curated positive digest) selects for confident, uncontested advice.
  Our Favorite Management Tips on Giving Feedback — read next: Critiques of over-formalized feedback culture and of performance-review theater in the broader management literature.
• incompletePierce's 'linear relationship between work done and understanding gained' is offered as strong personal conviction without engaging the counter-case that some AI-assisted synthesis (e.g., structured review, retrieval practice) could build understanding as well as raw manual effort, especially on material the person has already partly internalized.
  The man who tried 200 to-do apps has some advice about AI — read next: Read cognitive-science literature on desirable difficulty, the generation effect, and note-taking/retrieval practice — directly relevant to the persona's standing interest in how the mind actually learns — to see whether 'more manual work = more understanding' holds generally or only for certain tasks and learners.
• incompleteOrosz states his default editorial policy is to write about what works rather than what's broken, yet his most notable piece is precisely an exposé of what went badly wrong at Pollen. He never articulates the criteria or threshold (e.g., degree of misconduct, being publicly dismissed) that triggers an exception to the default policy.
  The Pragmatic Engineer AMA — read next: Look for any explicit statement of The Pragmatic Engineer's editorial values/criteria beyond this one anecdote — e.g., an About page, a past newsletter issue on his editorial philosophy, or interviews where he discusses how he decides what to cover critically.
• incompleteThe claim that standards adoption hinges on the originating company being perceived as non-dominant rests on a single supporting case (MCP) and a single contrasting case (Agent2Agent), with no broader survey of other protocol/standard adoptions to test the generality of the mechanism.
  The Pragmatic Engineer AMA — read next: Compare against the adoption histories of other widely-adopted open protocols/standards (e.g., OAuth, gRPC, Kubernetes, USB-C) to test whether 'non-threatening originator' consistently predicts adoption, or whether technical merit and network effects dominate more often.
• incompleteThe 'AI doesn't make work easier if you're pushing yourself hard enough' claim is a personal heuristic with no account of how it might vary by task type, seniority, or skill level — it's unclear whether it generalizes beyond an expert writer/engineer who has already optimized their own workflow.
  The Pragmatic Engineer AMA — read next: Look for empirical research on AI's effect on productivity/effort across skill levels and task types (e.g., controlled studies of AI-assisted coding speed) to test whether the 'should still feel just as hard' framing holds broadly or mainly for already-expert practitioners.
• uninformedThe deterministic-simulation/hostile-environment testing technique (via Antithesis) is presented through a sponsor endorsement with a screenshot and a one-line personal impression, not a technical account of how deterministic replay is achieved, what classes of bugs it does or doesn't catch, or its performance/adoption cost.
  The Pragmatic Engineer AMA — read next: Read Antithesis's own technical documentation or independent write-ups on deterministic simulation testing (and compare with FoundationDB's well-documented deterministic-simulation approach) to evaluate the technique on its merits beyond the sponsored blurb.
• normative-direction assumption'Precision proactivity' assumes calibrated scope-bounded proactivity is normatively superior to indiscriminate proactivity. But CLT has a 'desirable difficulty' tradition (intentional friction supporting learning), and serendipitous unsolicited surfacing — exploration that helps users find what they wouldn't have queried — is a real category. The paper conflates 'precision' with 'good' without engaging the exploratory case.
  Precision Proactivity: Measuring Cognitive Load in Real-World AI-Assisted Work — read next: van Merriënboer & Sweller 2005 on germane load (cited ref. 125) — the paper's exclusion of germane load from its operationalization is itself a theoretical commitment worth examining.