Debug with questions — not pasted solutions

Use this before-and-after pattern.

Before (outsourcing):

Here’s all my code. Make it work.

After (learning):

I’m debugging. Do not paste a full solution. Ask me up to five yes/no or short-answer questions that help me find the bug. Wait for each of my answers. If I’m stuck after five, give one hint about where to look, not the fixed code.

Now the model becomes a rubber duck with a checklist — and you stay the programmer.

Include:

• the symptom (“sprite ignores the second broadcast”)
• the small snippet around the failure (10–20 lines, not the whole repo)
• what you already tried

Skip:

• classmates’ full projects
• API keys or login secrets
• huge unrelated files

Smaller context makes better questions and fewer accidental leaks.

Good questions sound like:

1. Does the freeze happen on the first click or only after the second message?
2. Which script is listening for that broadcast name — exact spelling?
3. What is the value of your counter right before the loop?
4. Did you change costumes and scripts in the same event?

Answering those often reveals the bug without a gift-wrapped fix.

Reply immediately:

Delete the full code from your approach. Convert that fix into two questions I should ask myself instead.

Then answer those questions in your editor. Change one thing. Retest. That is real debugging practice for CS class, Scratch clubs, or Python homework.

Before you turn work in, close the chat and explain the bug and fix in two sentences. If you can’t, you don’t understand the “solution” yet — keep questioning, don’t keep pasting.