Hints, Not Answers
Stryg for at vise menuen
The trap that feels like productivity
You hit a bug. You paste the code and the error. Claude returns a corrected version. It works. You move on.
You have solved the bug and learned nothing. Worse — you've learned that bugs are solved by pasting, which is a habit that stops working the moment the problem is genuinely novel.
The uncomfortable finding from learning research: the difficulty is the mechanism. Effort spent retrieving and reasoning is what forms durable memory. Remove the effort and you remove the learning. An instant fix is a deleted lesson.
A difficulty that slows performance in the moment but improves long-term retention called desirable. Struggling to recall something, working out a solution yourself, or being tested rather than shown all feel worse and produce better results. The corollary matters: if a study method feels effortless, it is probably not working.
Socratic method stands on teaching by asking questions rather than supplying answers, so the learner reaches the conclusion themselves. Applied to debugging: instead of being told the fix, you're asked the question that makes the fix obvious.
The escalating-hint prompt
Save this one. It is the single most valuable prompt in the course.
I have a bug. Do NOT give me the fix, and do not show corrected code.
Instead help me in escalating steps, and STOP after each one until I say "next":
Step 1 — Ask me one diagnostic question that will move me toward the cause.
Step 2 — Name the concept I've probably misunderstood, without applying it to my code.
Step 3 — Tell me which line or region to look at, but not what's wrong with it.
Step 4 — Only if I explicitly say "give me the fix": explain the fix and why.
My code:
[paste]
The error:
[paste]
Most of the time you never reach Step 3. You'll solve it at Step 1 — and that solve is yours, so it sticks.
Why "ask me a question" works
When Claude asks "what do you expect the type of that variable to be at line 12, and what does it actually print?", three things happen:
- You form a prediction (retrieval practice).
- You test it (evidence).
- The gap between them is the bug (and now you know the class of bug).
You've learned a debugging move you can reuse. A corrected code block teaches you nothing reusable.
Rubber-duck mode
Sometimes you don't want hints — you want to hear yourself think:
Be a rubber duck. I'm going to explain my bug out loud.
Only respond with short clarifying questions. Never propose a solution
unless I ask directly.
When to just take the answer
This isn't dogma. Take the fix immediately when:
- The bug is environmental — a missing dependency, a path, a version conflict.
- It's a typo or syntax slip you've already found.
- You're on a deadline and this isn't the thing you're trying to learn.
- You've been stuck over ~30 minutes with zero movement.
Tak for dine kommentarer!
Spørg AI
Spørg AI
Spørg om hvad som helst eller prøv et af de foreslåede spørgsmål for at starte vores chat
Hints, Not Answers
The trap that feels like productivity
You hit a bug. You paste the code and the error. Claude returns a corrected version. It works. You move on.
You have solved the bug and learned nothing. Worse — you've learned that bugs are solved by pasting, which is a habit that stops working the moment the problem is genuinely novel.
The uncomfortable finding from learning research: the difficulty is the mechanism. Effort spent retrieving and reasoning is what forms durable memory. Remove the effort and you remove the learning. An instant fix is a deleted lesson.
A difficulty that slows performance in the moment but improves long-term retention called desirable. Struggling to recall something, working out a solution yourself, or being tested rather than shown all feel worse and produce better results. The corollary matters: if a study method feels effortless, it is probably not working.
Socratic method stands on teaching by asking questions rather than supplying answers, so the learner reaches the conclusion themselves. Applied to debugging: instead of being told the fix, you're asked the question that makes the fix obvious.
The escalating-hint prompt
Save this one. It is the single most valuable prompt in the course.
I have a bug. Do NOT give me the fix, and do not show corrected code.
Instead help me in escalating steps, and STOP after each one until I say "next":
Step 1 — Ask me one diagnostic question that will move me toward the cause.
Step 2 — Name the concept I've probably misunderstood, without applying it to my code.
Step 3 — Tell me which line or region to look at, but not what's wrong with it.
Step 4 — Only if I explicitly say "give me the fix": explain the fix and why.
My code:
[paste]
The error:
[paste]
Most of the time you never reach Step 3. You'll solve it at Step 1 — and that solve is yours, so it sticks.
Why "ask me a question" works
When Claude asks "what do you expect the type of that variable to be at line 12, and what does it actually print?", three things happen:
- You form a prediction (retrieval practice).
- You test it (evidence).
- The gap between them is the bug (and now you know the class of bug).
You've learned a debugging move you can reuse. A corrected code block teaches you nothing reusable.
Rubber-duck mode
Sometimes you don't want hints — you want to hear yourself think:
Be a rubber duck. I'm going to explain my bug out loud.
Only respond with short clarifying questions. Never propose a solution
unless I ask directly.
When to just take the answer
This isn't dogma. Take the fix immediately when:
- The bug is environmental — a missing dependency, a path, a version conflict.
- It's a typo or syntax slip you've already found.
- You're on a deadline and this isn't the thing you're trying to learn.
- You've been stuck over ~30 minutes with zero movement.
Tak for dine kommentarer!
