Learn by Asking in computing: questions that debug your own thinking

In KS3 computing, debugging is not a technical skill separate from Learn by Asking — it's the clearest possible example of it: a discipline of asking increasingly specific questions about a program's behaviour, rather than randomly changing code and hoping something works. This is computing's own instance of Learn by Asking, and it applies whether the "code" is a Python script, a Scratch project, or a spreadsheet formula that isn't returning what it should.

Why debugging is the purest form of the theory

Most subjects hide the connection between "asking a good question" and "getting the right result." Computing doesn't — a program either does what you expected or it doesn't, and the gap between those two things is always traceable to a specific point, if you ask the right question to find it. A learner who changes lines of code at random, re-running each time to see if it "worked," isn't debugging — they're guessing, and guessing correctly by chance teaches nothing for next time.

The Ask Ladder applied to a broken program

Take the common KS3 scenario: a program that runs but produces the wrong output, or throws an error. The Ask Ladder gives five rungs:

1. Locating — "What does this error message actually say?" The lowest rung, and the most skipped: many learners see red text and stop reading, when the message very often names the exact line and type of problem.
2. Clarifying — "What is this line of code supposed to do?" Not what it does do — what it was meant to do. This question exposes the gap between intention and implementation, which is where most bugs actually live.
3. Diagnostic — "Where does the program's actual behaviour first diverge from what I expected?" The single most useful debugging question at KS3 — it narrows "it doesn't work" down to a specific point worth investigating, rather than the whole program.
4. Generative — "What happens if I isolate just this one part and test it alone?" Extending the investigation by controlling variables — running a suspect function on its own, with known inputs, to see if it behaves as expected in isolation.
5. Reflective/Transfer — "Have I seen this exact kind of bug before?" Recognising a pattern — an off-by-one error, a variable reused before it's reset, a condition that should be and but is written as or — that will keep recurring across projects until it's recognised as a category, not a one-off.

At a glance

The computing Answer Trap: "just fix it"

The Answer Trap in computing has a very recognisable modern shape: pasting broken code into an AI tool and asking it to "fix it," then pasting the fixed version back without reading what changed. The code might now run. Nothing has been learned about why it didn't run before, which means the same category of mistake — the same off-by-one error, the same misused variable — will happen again in the very next project, and the learner will reach for the same "fix it" prompt instead of recognising it.

This is precisely why debugging as a discipline of asking is worth naming explicitly, rather than assuming it's obvious. The AI-era default is to skip straight to a working answer; computing is the subject where that default does the most visible damage to actual skill-building, because the skill is the process of finding the divergence.

Ask-Try-Ask, applied to code

The Ask-Try-Ask cycle maps onto debugging almost exactly:

• Ask a specific question: "why might this loop run one too many times?" — not "why is my code broken."
• Try the fix based on the answer, and actually run it.
• Ask a sharper follow-up informed by what happened: if the fix half-worked, "the loop count is right now but the output is still wrong — what else could cause that?"

Each cycle narrows the search. Pasting the whole file in once and copying back whatever comes out skips all three steps and produces the Answer Trap in its purest computing form.

Why "have I seen this before" matters more here than in most subjects

Computing bugs are unusually repeatable — the same handful of mistake categories (wrong comparison operator, variable scope, off-by-one loops, forgetting to update a counter) account for a huge share of KS3-level errors. That makes the Reflective/Transfer question especially valuable in this subject: a learner who's asked "have I seen this exact kind of bug before" three or four times starts recognising the pattern on sight, well before they've formally studied it as a named concept. This connects to the broader idea of algorithms drawn out — visualising what a program is actually doing step by step, which is often what a Generative-level "isolate and test" question ends up requiring anyway. See also five KS3 computing concepts for the wider curriculum context.

A note on Professor Turing

Computing at aitutors.me isn't yet a bookable live-tutor session in the way maths, English or the sciences are — but the questioning discipline above applies regardless of which resource, teacher, or AI tool a learner is debugging with. The Ask Ladder doesn't require a tutor in the room; it requires the learner to ask it of themselves.

FAQ

What's the Answer Trap in computing specifically?

Asking an AI tool to "fix it" when code doesn't work, without first asking what the code was supposed to do and where its actual behaviour first diverged. The fix might work, but the learner hasn't debugged their own understanding, so the same category of bug reappears next time.

What's the single most useful debugging question at KS3?

"Where does the program's actual behaviour first diverge from what I expected?" It's the Diagnostic-level question, and it narrows a vague "it doesn't work" into a specific line or step worth investigating.

Is debugging really about asking questions rather than fixing code?

Yes — the fixing is usually the easy part once the actual point of divergence is found. Most of the time spent "debugging" badly is really time spent making random changes without having asked a specific enough question yet.