1.5 Asking Questions

1. Search First, Then Ask

1.1 Why Search First

Before we run into a problem, chances are someone else has already run into the same problem and gotten an answer. Searching directly is often faster than asking, and the process of "finding the answer yourself" is itself learning.

1.2 The Order of Searching

When you run into a problem, you can look it up level by level along the following ladder:

Each step takes no more than 10 minutes; only move to the next step when no answer is found. Most problems can be solved within the first three steps.

1.3 Search Tips

The full explanation of search techniques is in the "search operators" part of 1.3 Browser; here we emphasize a few points:

2. The Structure of a Question

You've searched, you've tried, and it's still not solved — only then do you need to ask a person. But "how to ask" also matters.

2.1 Good Questions vs. Bad Questions

First, look at two comparisons to feel the gap directly:

What's wrong:

• "Are you there" is useless filler that wastes people's time
• Doesn't say what language, environment, or error it is
• The screenshot hides the key information (full code, full error)
• "Urgent" is not a reason for people to prioritize us

void remove(Node* head, int val) {
    while（head != val） {  // error here
        head = head->next;
    }
}

What makes it good: the goal, environment, and problem are stated in one sentence; the full error is given; relevant code is pasted; and it explains the asker's understanding and what they've tried, so the answerer can see where the problem is at a glance.

2.2 The Standard Template for Asking

Distill the good question above into a template and fill it in the next time you ask:

【Background】What I'm doing, what tech stack / version I'm using
【Goal】What effect I expect to achieve
【Current state】What actually happened, what the full error is
【Reproduction】How to retrigger the problem (minimal steps)
【Code】Minimal reproducible code (in a code block, not a screenshot)
【What I've tried】What I searched, what I tried, why it doesn't work
【My understanding】My current guess about the problem

3. Minimal Reproducible Example

The "minimal reproducible code" in the template is not a random snippet cut from your project; it is a verified example that lets others independently reproduce the problem. Stack Overflow currently uses Minimal, Reproducible Example (MRE); in older material you may also see names like MCVE or MWE.

3.1 The Three Requirements of an MRE

3.2 How to Build One

1. Copy the problem code into a new minimal directory; don't break the original project.
2. Record the runtime environment, dependency versions, and full commands.
3. Progressively remove irrelevant features, re-confirming each time after removal that the problem still exists.
4. Replace databases, network services, and personal files with fixed, non-sensitive inputs.
5. Run it again from a fresh directory or another device to confirm the steps don't depend on hidden state.

3.3 Use Code Blocks, Not Screenshots

Code screenshots can't be copied, searched, or run directly, and they are also unfriendly to screen readers. Code, configuration, and logs should use code blocks with a language identifier; only problems that can't be expressed in text, such as UI layout or graphics rendering, need screenshots.

```cpp
#include <iostream>

int main() {
    std::cout << "hello";
    return 0;
}
```

3.4 Rubber Duck Debugging

Before building an MRE, there is an even lighter trick worth trying first: get a "rubber duck" and explain the problem to it.

Its origin can be traced back to The Pragmatic Programmer; the authors mocked how a programmer's confusion about a bug often disappears while they are "explaining it out loud":

Why does this work? "Saying it out loud" and "thinking it in your head" are two different things: the brain easily "fills in" the parts it is unsure about, but when speaking, every line must be explicitly said, and any careless assumption gets exposed.

4. The Etiquette of Asking

The structure is right and the code is minimal enough — one last step remains: ask in the right place, with the right attitude.

4.1 Choose the Right Place

4.2 Make the Title Specific

When asking on a forum or by email, the title is the first door that decides whether others click in.

A good title includes: tech stack + problem symptom + key error, so people can tell at a glance whether they can help.

4.3 Don't Be a "Hand-Out Seeker"

"Hand-out seekers" refers to those who only want to take without being willing to work themselves. Typical behavior:

• Posting assignments directly and demanding others give the answer
• Asking outright for source code, notes, or cracked software
• Asking "is there a tutorial for xxx" (a search engine would find one immediately)
• Never giving feedback or saying thanks after receiving answers

4.4 Respond to Answers

After getting an answer:

5. Common Misconceptions in Asking

With the right method in hand, you also need to know which pitfalls to avoid. The three below are the most common misconceptions in asking — they look like small issues, but in practice they will sink our question without a trace.

5.1 The XY Problem

The "XY problem" means: we want to solve X, we think method Y can solve it, so we ask "how do I do Y" — but Y is actually the wrong approach, and what we really should ask about is X.

For example: we ask "how do I extract all <div> elements from HTML using regex", but the real goal is "parse the HTML and get the content of all divs". The former is highly error-prone with regex; the latter can be done in one line with an HTML parsing library.

The way to avoid the XY problem: when asking, state both "what I want to do (X)" and "how I plan to do it (Y)", so the answerer has a chance to point out a better solution.

5.2 "It Doesn't Work" Questions

"It doesn't work" questions only report the symptom "doesn't work" with no context — that is equivalent to dumping all the debugging responsibility on the answerer, as if they owe us an explanation. A better way to phrase it is "I expect A, but actually got B; where could the gap be", describing the problem clearly instead of asking others to debug for us.

5.3 Multiple Questions at Once

Asking five or six unrelated questions at once makes answerers balk. Ask one core question at a time, and move on to the next after it's solved.

6. Asking AI

Everything so far has been about "asking people", but today we also have an "answerer" who is available 24/7 — the AI assistant. The good news is that almost all of the principles above apply; the bad news is that AI has its own pitfalls — though many of them have already been filled in by stronger new models.

6.1 AI Is Also an "Answerer"

AI assistants (ChatGPT, Claude, etc.) are also "answerers", and the principles above apply to them as well. When asking AI:

6.2 The Boundaries of Capability and Attention

AI assistants' capabilities are updated quickly. The old common shortcomings — knowledge cutoff, no internet access by default, error-prone arithmetic, short context windows — have mostly been resolved in today's mainstream models: built-in web search, larger context windows, and stronger reasoning have become or are becoming the standard. Let's see how those former shortcomings stand today:

The shortcomings are being filled in, but there are two boundaries we always need to watch ourselves: hallucination (see 6.3) and attention dilution. About attention first: even if all the information is inside the context window, the longer the conversation and the more content there is, the less attention the model pays to each detail — especially the early content sandwiched in the middle, which is most easily "overlooked".

Chat with AI long enough and you'll meet the "customer-service tone" meme: it always opens with a soothing paragraph, giving the position of highest attention to promises —

"I will reliably hold you, and analyze your problem for you in detail, seriously, item by item, and give you the most suitable solution!"

"I will analyze this problem for you seriously and carefully."

"My view is that it is completely feasible; let's solve it step by step."

"Please rest assured and leave it to me; I will give you a step-by-step solution."

Not a single bit of information, yet every time we see it we can't help but smile — skip it and go straight to the real content after.

6.3 Hallucinations: Confidently Talking Nonsense

"Hallucination" refers to the model generating content that seems plausible but is actually nonexistent. Stronger models have reduced how often hallucination occurs, but have not eradicated it — because the model's job is to "continue writing the most plausible text", not to verify facts: when the information is not in the training data, it may not say "I don't know", but instead make up an answer that sounds professional.

Typical forms:

6.4 A Good Prompt Example for AI

I'm learning C++ data structures and just started with linked lists.
Environment: g++ 15.2, Windows 11.
I wrote a function to reverse a singly linked list, but the output is wrong (it outputs the list unchanged).
Here is the code:
[paste code]

Please help me:
1. Point out where the bug is
2. Explain why it outputs the list unchanged
3. Give the corrected code

7. TODO Checklist

• When you run into a problem, work through it in the order "error message → search engine → AI assistant → official docs → community → a person"
• Take a recent problem you met and rewrite it into a complete question with the standard template
• Build an independently reproducible MRE and verify it in a fresh directory
• In a course group chat or community, help a friend answer a question we can answer
• Explain this section to a friend and check each other for the common misconceptions in asking 😉

8. Questions Worth Thinking About