“It Doesn’t Work” Is Not a Question

Every student has sent this message: “my code doesn’t work, can you help?” And watched it sit unanswered while a better question gets three replies. The difference is rarely who is smarter. It is the question. “It doesn’t work” tells the helper nothing they can use: not what the code should do, not what it did, not what you already tried. With nothing to grab onto, the helper must ask three follow-ups before the real work starts — and most will not bother.

The questions that get answered are the ones a busy person can understand in thirty seconds — a classmate has their own assignment open, a teacher has thirty students. That is a skill you can learn: working developers ask for help constantly, and the ones who get good answers make their stuckness easy to help with.

The Three Parts of a Question That Gets Answered

A good question has three parts. First: what did you want the code to do? One sentence, in plain words — “this function should add up the prices in a shopping list.” Second: what did it actually do? Copy the exact error or the exact wrong output, not your summary of it. “KeyError: 'price'” says more than a paragraph of “it crashed on the third item.” Third: what did you try already? “I printed the list and the third item has no price” points at the line that matters.

Those three parts do the helper’s job for them. The first checks whether you are solving the right problem at all — half of all stuck moments turn out to be a misunderstood requirement, not a bug. The second gives them the exact failure to reproduce. The third tells them which ideas are already spent. A question with all three parts can be answered in one reply.

Shrink It Until It Fits on One Screen

The most powerful step is one students skip: before you ask, shrink the bug to the smallest program that still breaks. Delete half your code and run what is left. If the bug is still there, delete half again. Keep going until removing one more line makes the bug disappear. What is left is a minimal reproducible example — usually under twenty lines, with nothing in it except the bug.

Here is a real one. A shopping-list program crashes, and the full assignment is two hundred lines long. The shrunk version is six lines, and it still crashes. Paste it into the browser editor — Python is one of the 34+ executable languages on CoderFile (120+ syntax-highlighted) — and run it.

# repro.py — the smallest program that still crashes
items = [ {"name": "pen", "price": 2}, {"name": "notebook", "price": 5}, {"name": "mystery"},
] def total_price(shopping): total = 0 for item in shopping: total += item["price"] return total print(total_price(items)) # KeyError: 'price'

The error is KeyError: 'price', and the cause is visible once the program is this small: the third item has no price, so item["price"] has nothing to find. With two items it returns 7, and with an empty list it returns 0 — the bug only appears when an item has no price. The fix is one small change: item.get("price", 0) treats a missing price as zero, and the full list returns 7 again. A helper who sees these six lines can spot that in seconds.

Shrinking has a second benefit: about half the time, you find the bug yourself. Delete a block and the error disappears, and you know the bug lived there. Delete a line and the error stays, and you know it did not. Asking with a small example is not extra work on top of debugging — it is debugging, in a form somebody else can finish.

When the example is small, share it as code somebody can run — not as a photo of your screen. A screenshot cannot be run, edited, or searched; the helper must retype your code, and one mistyped character gives them a different bug. A runnable link is the opposite: the helper opens it, runs it, sees the same KeyError you saw, changes one line, and sends it back fixed. Save the trimmed example as a snippet and paste its link plus the exact error into your question.

Two habits make shared code easier to help with: strip anything private first — passwords, API keys, code that belongs to somebody else — and say which line the error points to and what you expected it to do. The goal is to make helping you the easiest thing your classmate does all day.

The 15-Minute Rule: Try First, Then Ask

Asking well starts before you ask. Give yourself fifteen minutes of real trying: read the error properly, explain the problem out loud, search for the exact error text, and change one thing to see what moves. Fifteen minutes is short enough not to waste an evening, and long enough that you either find it or arrive with something real to show.

The rule cuts both ways: do not ask after thirty seconds, and do not suffer for three hours either. Asking after thirty seconds teaches you nothing; suffering for three hours teaches you nothing either, because frustration stops being information and starts being noise. Fifteen minutes is the honest middle.

Where to Ask — and What to Do With the Answer

Start with the closest help: a classmate on the same assignment, with the same context and deadline. Then your teacher or teaching assistant, who can tell you whether the bug is the point of the exercise or a distraction from it. Class forums and study groups come next — a question asked where the whole class can see it helps the next student who hits the same error. Check the Lab lessons first, too: the small functions inside often cover the exact idea your bug is about.

When the answer arrives, close the loop: reply with what worked, so the next student with the same error finds the answer instead of asking again. Then save the question and its answer as a snippet — the broken code, the fixed code, and one sentence saying what was wrong. That snippet is a study note written by your own confusion, which is the kind you actually remember.

When Asking Outgrows Free, That Is the Upgrade Moment

Stay on Free ($0: 20 executions a day, 10 AI requests a day, 10 saved snippets, 3 private snippets, 3 collaborators per snippet) while it fits — one shrunk bug a day fits easily. But good questions accumulate, and each one becomes a saved snippet. That is when Pro earns its $9/month or $69/year — unlimited saved snippets and executions, 100 AI requests a day, 10 collaborators per snippet, and unlimited private snippets — and Team ($19/user/month, or $15/user/month billed annually) covers a class asking and answering together. See the pricing page for current terms.

Your next step is small. The next time you get stuck, shrink the bug until it fits on one screen, save it as a snippet, and write the three-part question: what you wanted, what actually happened, what you tried. Then share the link — the answer will come back faster than the vague message ever did.