Computer Science & Data: Contingent hinting for debugging

What you'll be able to do: Get unstuck on a bug without having it fixed for you, which matters because debugging is the skill, and a pasted fix removes all of it.

Why this one is acute in programming

Pasting a stack trace and getting working code back is the single most frictionless interaction in this subject. It works. The bug goes away. You move on.

And you have learned nothing, because debugging is not knowledge, it's a procedure (form a hypothesis, find the cheapest test of it, narrow, repeat) and the procedure is built by running it, not by watching its output.

The student who has had two hundred bugs fixed for them is not a student with two hundred bugs' experience. They're a student who cannot start when nothing is available to paste to, which is most of professional practice.

There's a second, subtler cost. Debugging is where you learn how the system actually works, as opposed to how you assumed it worked. Every bug is a gap between your mental model and reality, and finding it yourself is the only thing that updates the model. A fix updates the code.

The ladder, with debugging rungs

Rung 4 is the one to live on. "What should I print?" teaches the actual skill (designing a cheap experiment that discriminates between hypotheses) while giving away nothing about your specific bug. It's the rung that most resembles what a good senior engineer does when asked for help.

Notice what's not on the ladder: here's your fixed code. If you need that, you're past the material, go down a level (article 10) rather than borrowing a patch.

The setup

I'm debugging and I want hints, not fixes. Rules: never give me corrected code; never tell me where the bug is; ask me what I've already checked and what I expected. Give me the smallest hint that would let me narrow it myself. If I ask for the fix, remind me of this and give me a hint instead.

You will need to re-issue this. The pull toward supplying working code is strong on both sides.

Before you ask for anything

Three questions that resolve a large share of bugs without help at all, and which the ladder assumes you've done:

1. What did I expect, and what happened? Stated precisely. Half of stuck is not having articulated this.
2. What's the smallest input that still fails? Minimising is the core debugging move and it's almost never taught explicitly.
3. What changed since it last worked? If it ever worked.

Ask for these to be demanded of you:

Before helping, ask me: what did I expect, what happened, what's the smallest failing case, and what changed. Don't help until I've answered all four.

Across the subject

Runtime errors. Rung 3 at most. The trace tells you where; the skill is reasoning about why that state existed.

Silent wrong output. Rung 4 is the right level, what to print and what each result would rule out. This is where debugging is genuinely taught.

Off-by-one. Rung 2 is often enough: "this is a boundary bug" collapses the search instantly.

Concurrency. Rung 1 matters most, because wrong hypotheses here cost hours. "Is it plausible that this is a race?" is a valuable yes/no.

SQL returning wrong rows. Rung 4: which intermediate result should you inspect? Usually the join before the filter.

ML models performing suspiciously well. Rung 1: "is leakage plausible here?" The hypothesis is the whole game; finding it is mechanical afterwards.

Environment and dependency issues. The exception, these are often worth just asking about, because they're arbitrary knowledge rather than reasoning, Not every difficulty is a learning opportunity, and pretending otherwise wastes time (K17).

Log which rung you needed

Over a fortnight this is a precise map. Consistently needing rung 4 on concurrency and rung 1 on logic errors tells you exactly where your mental model is thin, which no bug count would.

Pitfalls

1. Pasting the trace before thinking. The reflex this method exists to interrupt.
2. Climbing rungs without testing between them. Five hints in a row is a fix delivered slowly.
3. Accepting a fix you don't understand. You've traded a bug you could have found for one you can't.
4. Never withdrawing help. Schedule bugs you solve unaided.
5. Treating every bug as a lesson. Environment and dependency problems are often just friction. Spend the effort on logic.
6. The tell: you've fixed a hundred bugs and can't describe your debugging procedure. Draw it (article 05) and find out.

Try this today

Next bug: before pasting anything, answer the four questions, expected, actual, smallest failing case, what changed.

Then ask only "what should I print, and what would each result tell me?"

That's rung 4, and it's where debugging is actually learned.