Explicit Debugging Instruction at the First-Constructs Stage: A Literature Synthesis

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.