Asking good questions: goal, code, error, attempts
On This Lesson 11 topics
Lesson Overview
An assistant can only work with the text you give it. It cannot see your screen, your IDE, or the file you forgot to paste. "My code doesn't work, help" gives it almost nothing, so it fills the gap with guesses. This is the same situation as asking a teammate for help: the better the question, the faster and more accurate the answer.
This lesson gives you a four-part recipe: goal, code, exact error, what you tried. It also shows how to shrink a problem to the smallest code that still fails. Writing the question often solves the bug before you press Send, and that is a good outcome too.
Why this matters: backend teams ask questions all day, in pull requests, issue trackers, and chats. Clear, reproducible questions are a visible professional skill.
This lesson builds on "Why assistants sound right and are sometimes wrong". It uses the debugging method from BEG-018 (reproduce, isolate, hypothesize) and your ability to read a stack trace.
Learning Objectives
By the end of this lesson you will be able to:
- Name the four parts of a good question: goal, code, exact error, what you tried.
- Explain why each part changes the quality of the answer.
- Reduce a failing program to the smallest code that still shows the problem.
- Copy an error or stack trace exactly, rather than describing it.
- Add useful context such as the Java version, without adding noise.
- Rewrite a weak question into a strong one.
Written Explanation
The four parts
Goal: what I want the code to do
Code: the smallest code that shows the problem
Error: the exact message or stack trace
Tried: what I did and what happened
Question: one specific thing I want to knowGoal. Say what the code should do, in a sentence. Without it the assistant may "fix" the code to do something else, or answer a different question. A goal also helps you notice when the program is not doing what you meant.
Code. Include the method (or class) where the problem shows up and the lines that call it, not the entire project. The smaller it is, the easier it is for you and for the assistant to reason about, and the fewer unrelated details can mislead. Make sure the code you paste is the code that actually produced the error.
Error. Paste the message and the stack trace exactly, including the exception name and the line numbers. Typing "it says something about an index" throws away the most useful information. In Java the first line names the exception type and message, and the at ... lines show where it happened (BEG-018 L04).
What you tried. List what you did and what you saw: "I printed words.length and got 0". This tells the assistant what is already ruled out, and it shows your hypothesis, which you should write before asking (next lesson).
One question. End with a specific question: "Why does it fail on empty input?" is better than "What's wrong?".
Shrinking the problem
A minimal example is the smallest program that still shows the problem. To build one:
- Copy the failing code to a scratch file.
- Remove everything unrelated (other methods, extra classes, input from files).
- Replace real data with a small hard-coded value.
- Run it after every removal. If the error disappears, put the last thing back; it matters.
This is the isolate step from your debugging method. It is also a strong hint at the cause. Often the removal that makes the bug vanish is the explanation.
Useful context, but not too much
Add facts that change the answer: the Java version (java -version), the build tool if it matters (for example Maven), and the operating system when the error is about files or commands. Skip your life story. And do not paste anything private: the next lesson covers what to remove or replace first.
What a good question buys you
- The assistant answers your problem, not a generic one.
- You can check its answer, because you know exactly what code and error it saw.
- You build the habit of reproducing before asking. That alone solves many bugs.
Examples
Example 1: a weak question and a strong one (simple)
Weak:
my code doesn't work, helpThe assistant does not know the language, the goal, the error, or the code. It will ask follow-up questions or guess.
Strong:
Goal: count the words that are longer than 4 letters.
Code: (the 10-line method below)
Error: ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
at Words.countLong(Words.java:4)
Tried: I printed words.length; it is 0 when the input is empty.
Question: why does it fail on empty input, and what is the usual way to handle it?Every line is something the assistant can use or you can check.
Example 2: reducing a failing program (practical)
Suppose your real program reads text from a file, splits it, filters it, and prints results, and it crashes. After removing the file reading and hard-coding the input, you end up with this:
public class Words {
static int countLong(String[] words) {
int count = 0;
String first = words[0];
for (String w : words) {
if (w.length() > 4) count++;
}
return count;
}
public static void main(String[] args) {
System.out.println(countLong("apple banana fig".split(" ")));
System.out.println(countLong(new String[0]));
}
}Run with JDK 21:
2
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
at Words.countLong(Words.java:4)
at Words.main(Words.java:12)The reduction taught you something before you asked anything: the first call works and prints 2, the empty array fails, and line 4 (words[0]) is the failing line. You can now ask a precise question, and you may not even need to.
Example 3: a full question with context and a hypothesis (realistic)
Another failure from the same family of bugs:
public class Div {
static int average(int[] grades) {
int sum = 0;
for (int g : grades) sum += g;
return sum / grades.length;
}
public static void main(String[] args) {
System.out.println(average(new int[] {80, 90}));
System.out.println(average(new int[] {}));
}
}85
Exception in thread "main" java.lang.ArithmeticException: / by zero
at Div.average(Div.java:5)
at Div.main(Div.java:9)A good question to an assistant:
Java 21, plain JDK (no framework).
Goal: return the integer average of an array of grades.
Code: the average method above (5 lines) and the two calls in main.
Error: ArithmeticException: / by zero at Div.average(Div.java:5)
Tried: the first call prints 85. I think grades.length is 0 for the
empty array, so the division fails. I have not checked in the debugger.
Question: is my guess right, and what should average return for an
empty array?Notice the question includes a hypothesis and asks a design question the assistant cannot answer alone: what the right result for an empty array is depends on your program's rules. Good questions leave the decision with you.
Backend Insight
Production bugs arrive as tickets: a log line, a request, an environment. Teams that fix bugs quickly insist on the same four things you just learned: what was expected, how to reproduce it, the exact error, and what has been checked. A minimal reproduction is often worth more than a long description, because anyone can run it.
The same habit applies to every channel: an issue report, a pull request description, a message to a senior colleague, or a search query. Practising it with an assistant is free training.
Common Mistakes
Mistake 1: Asking before trying
If you have not run the code, read the stack trace, or formed a guess, the question is not ready. Spend five minutes first (the next lesson shows the routine).
Mistake 2: Pasting the whole project
A long paste hides the problem, may contain private data, and may exceed what the tool reads. Paste the smallest failing code, not the whole project.
Mistake 3: Describing the error instead of pasting it
- Weak: "I get an index error."
- Better: the exact first line and the
atlines with line numbers.
Exact text lets you and the assistant search for the same message.
Mistake 4: Leaving out what you already tried
Without it, the assistant suggests things you have already done, and you cannot tell whether the answer really adds anything.
Exercises
Try each exercise yourself before opening the solutions.
Level A: Foundation
A1. List the four parts of a good question.
Show solution A1
A1. Goal, code, exact error, and what you tried (plus one specific question).
A2. Why should you paste the exact error rather than a description?
Show solution A2
A2. The exact exception name, message, and line numbers are the most useful clues, and a description loses them. Exact text can also be searched and compared.
A3. What is a minimal example?
Show solution A3
A3. The smallest program that still shows the problem: unrelated code removed, small hard-coded data, and it still fails the same way.
Level B: Application
B1. Rewrite this weak question as a strong one using the four parts: "my program crashes when I type a letter instead of a number". Invent small, realistic details, and make clear they are examples.
Show solution B1
B1. For example: "Java 21. Goal: read an integer grade from the user. Code: the 4-line method that calls Integer.parseInt. Error: NumberFormatException: For input string: "7O" and the at lines. Tried: it works with 80; it fails when the text has a letter, and I think parseInt does not accept letters. Question: how should I handle bad input so the program does not crash?" The input text and values are only illustrations.
B2. The stack trace says at Avg.parseGrade(Avg.java:3). Which of these belongs in the Code part: the whole 200-line project, or the method on line 3 plus its caller? Say why.
Show solution B2
B2. The method on line 3 and its caller. The trace points to that line, and a small piece of code is enough to reproduce the problem; a large paste adds noise and may include private data.
B3. You remove a line while shrinking a program and the error disappears. What did you learn, and what do you do with that line?
Show solution B3
B3. The removed line is involved in the bug, directly or indirectly. Put it back, then study what that line does (the state it changes, what it reads), and build your question around it.
Level C: Challenge
C1. Take the program in Example 3. Write the minimal version of the question in at most seven lines, but change the hypothesis so it states a design question about how the rest of the program should treat an empty array.
Show solution C1
C1. For example: "Java 21. Goal: average of grades. Code: the 5-line method. Error: ArithmeticException: / by zero at line 5 for an empty array. Tried: the first call prints 85. Question: my program may legitimately get no grades; should average return 0, throw a clearer exception, or should the caller check first? What are the trade-offs?"
C2. An assistant answers a vague question with a long, plausible explanation that does not match your error. Explain what went wrong on both sides and what you do next.
Show solution C2
C2. The question lacked the code and the exact error, so the assistant guessed. Its answer reads well but does not apply. You supply the missing parts (goal, code, error, attempts), and ask again; if the new answer still does not fit the evidence, reject it and check the documentation.
Mini Challenge
Pick a bug you have fixed recently (or use one from BEG-018). Before asking anything, write the full question using the template, and shrink the code to the smallest failing version. Run the shrunk version to confirm it fails with the same error.
Check your work: the question has all four parts and one specific question; the pasted error is exact; the shrunk code fails in the same way when run; and you can say in one sentence what the removal steps taught you.
Summary & Next Lesson
Key takeaways
- A good question has a goal, the smallest relevant code, the exact error, and what you tried, plus one specific question.
- Shrink the problem to a minimal example; the shrinking often reveals the cause.
- Paste errors exactly; add only context that matters, such as the Java version.
- Ask only after you have tried, and leave design decisions to yourself.
- A clear question also makes the answer easier to verify.
Next lesson
Next is "Learning with AI without skipping the learning". It adds the habits around the question: a hypothesis before you ask, explaining the answer back in your own words, confirming it with evidence, and the safe-use rules about what never to paste.
Self-check
- What are the four parts of a good question?
- Why is "paste the whole project" a poor strategy?
- What does "exact error" include?
- Why mention the Java version?
- What does it tell you when removing a line makes the bug disappear?
Show answers
- Goal, code, exact error, what you tried.
- It hides the problem in noise, may expose private data, and may exceed what the tool can read.
- The exception name and message and the stack trace lines with their line numbers, copied exactly.
- Behaviour and available methods can differ between versions, so it can change the correct answer.
- That line is involved in the bug; keep it and study it.
References
- Oracle, Java SE 21
IntegerJavadoc. Supports thatparseIntthrowsNumberFormatExceptionfor input that is not a valid number. - The question template, the minimal-example steps, and the two programs are this course's own teaching material; the exception messages and line numbers shown are real output from compiling and running the programs on JDK 21. I did not cite an external page for the question-writing advice.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.