Across four decades of computing-education research, the question of whether debugging can be taught as an explicit, transferable cognitive skill — or whether it can only be acquired implicitly through practice — has produced an asymmetric literature. On one side, Carver and Klahr's 1986 LOGO debugging-curriculum study 1 established that an explicitly taught debugging procedure produced measurable transfer to non-LOGO troubleshooting tasks; on the other, Spohrer and Soloway 1986 2, Murphy et al. 2008 3, Fitzgerald et al. 2008 4, and the broader Bracelet / Whalley-Lister tracingbug-finding line 5, 6, 7 have documented that even after one or two semesters of programming, the majority of novices employ ineffective debugging strategies — print-blame, guessand-replace, code-shuffle, and abandonment. The downstream literature 8, 9, 10, 11 has converged on the position that explicit debugging instruction is necessary, but has not converged on when in the curriculum to start. The two competing positions are: (a) start at the first-constructs stage (sequences, conditionals, loops — typically Volume 1 Chapters 2–5 of a Python-first curriculum), on the argument that debugging habits set early are durable; (b) defer until learners have a stable program-construction model (typically post-functions, Volume 1 Chapter 6 onward), on the argument that one cannot debug what one cannot yet write. This paper adjudicates the intervention question by decomposing "debugging skill" into four sub-skills — symptom-reading, hypothesis-formation, hypothesis-testing, fix — and aligning each against the cognitive prerequisites available at the first-constructs stage. The paper delivers two contributions. First, a literature verdict: explicit debugging instruction is feasible at the first-constructs stage if and only if it is scoped to symptom-reading and hypothesis-testing; the other two sub-skills require a stable program-construction model and should be scaffolded but not measured at this stage. Second, a four-mechanism instructional bundle — PRIMM modify-step as structural container, scaffolded error-message reading, peerdebugging dyads with prediction-then-verification, and rubberduck protocols as a metacognitive pre-habit — grounded in Loksa-Ko 2016 metacognitive instruction evidence 8, 12 and Klahr-Carver 1988 transfer evidence 13. Per the elix-researches no-cohort scope, no learner data is collected; deployment is identified as a downstream cohort responsibility (B1.4 Pythonfirst cohort, C2.1 PRIMM cohort, A3.4 tooling timing) and is out of scope here.
That Le (Tue,) studied this question.