Asking Good Questions — The Skill of Getting Fast Answers

There's a saying that "a good question is half the answer." Faced with the same blocker, one person gets an answer in 5 minutes while another wanders for days. The difference usually sits in two places. First, asking before sorting out what we're actually asking. Second, the missing information the answerer would need to help. This article covers the components of a good question, the meaning of a Minimum Reproducible Example (MRE), the XY problem, and posture in Korean-language communities.

1. About good questions

The most-cited piece is Eric S. Raymond's 2001 How To Ask Questions The Smart Way. Stack Overflow developed its own question guide when it launched in 2008, and GitHub issue templates carried that structure into code repositories.

Today's English-language standard is roughly the intersection of those two pieces. Korean communities (OKKY, Discord, GeekNews) follow the same broad conventions.

2. The 6 components of a good question

1. What we're trying to do (goal)
2. How we tried (attempts)
3. What happened (actual result)
4. What we expected to happen (expected)
5. Our hypothesis about where it broke (analysis)
6. Environment info (OS, versions, libraries, dependencies)

When all six fit in one message the answer comes fast; when they're missing it becomes a "send more info" loop.

3. A good title

The question title is the strongest signal for search:

Weak title	Better title
"Help!"	"'Cannot find module' error during Vite build"
"Doesn't work"	"Why NULL rows are missing in PostgreSQL JOIN"
"React question"	"Cause of React useEffect running twice (StrictMode)"

One or two core keywords plus the symptom on one line is enough.

4. Minimum Reproducible Example (MRE)

Called Minimum Reproducible Example in English, or MCVE (Minimal, Complete, Verifiable Example) on Stack Overflow. The smallest piece of code that lets someone else reproduce the same problem on their machine.

Three conditions:

• Minimum — remove all code unrelated to the problem.
• Complete — runnable as-is when copy-pasted.
• Verifiable — confirmed to produce the same result.

The act of building it is itself debugging. While isolating the problem, we often find the answer ourselves (the rubber duck effect):

Original code 800 lines
↓ remove unrelated parts
500 lines
↓ remove more, keep the flow
200 lines
↓ simplify data with hardcoded values
50 lines
↓ run it: same error
↓ attach those 50 lines to the question

5. Avoiding the XY problem

When trying to solve real problem X, we conceive of a workaround Y, then ask about Y — that's the trap:

Real problem X: how to keep per-user login state
Conceived solution Y: is it safe to store the password in localStorage
Question: "how to store passwords in localStorage"

The answer should have started from X. Answering only Y leads us deeper down the wrong path.

Adding one line — "what we're ultimately trying to do once this is solved" — lets the answerer consider X as well.

6. Attempts and environment

Things we already tried — answerers won't propose the same attempts again, the seriousness comes through, and the odds of getting an answer rise:

Tried:
1) Followed the docs Quickstart → same error
2) Bumped Node from 18 to 20 → same error
3) Searched "Cannot find module 'foo'" → tried 5 SO answers, no change

Environment info — write it from the start when possible:

• OS and version (Windows 11, macOS 15, Ubuntu 24.04)
• Language runtime version (Node 20.10, Python 3.12, JDK 21)
• Library and framework versions
• Package manager
• Relevant env vars (the fact that some var is set, not the value)

Pasting relevant parts of package.json, requirements.txt, or pom.xml directly is faster.

7. Other paths

Where to ask:

• Stack Overflow — strongest search exposure. English recommended.
• GitHub Issues / Discussions — answers from maintainers of the library or tool itself.
• Official Discord / Slack — React, Next, Tailwind and many others run official channels.
• OKKY, Discord Korean servers — Korean-language communities.
• Internal company channels — team Slack, Notion. Shared codebase context.
• LLMs (Claude, ChatGPT, Gemini) — 24/7 available, answer-quality distribution differs from humans.

Each spot has a different trade-off between response speed and accuracy. Deep design questions go to GitHub Discussions, fast unblocks to Discord, answers we want to leave for searchers go to Stack Overflow.

8. One good question

## Title
Vite 5 + React 19: dynamic import 404s only on prod build

## Environment
- Node 20.11
- Vite 5.4.10
- React 19.0.0
- vite-plugin-react 4.3.1
- Hosting: Vercel

## What I'm trying to do
Use React.lazy + dynamic import for per-route code splitting.

## Tried
- Works fine on dev server
- After prod build on static hosting, lazy-imported chunks 404
- Set vite.config.ts base option to "/" explicitly → no change
- The dist/assets/*.js files in build output do exist
- Network tab: import URL is /assets/Foo-xxx.js, returns 404

## Expected
chunks load in prod build the same as in dev

## Actual
404 only, other static assets are fine

## Hypothesis
Hosting-side rewrites may be sending /assets/* to index.html

## Attached
- vercel.json (rewrites section)
- vite.config.ts
- console error screenshot

9. Common pitfalls

Pasting the entire codebase — nobody reads 800 lines. Reduce it to an MRE.

Only attaching screenshots without text — search can't index it, and the answerer has to retype the code.

"Urgent!" "Please help T_T" — read as ignoring the answerer's time. A calm tone gets a faster reply.

Not reporting back after the answer — write down what worked. For the next person who hits the same problem.

Pasting an LLM answer back to ask again — hallucinations are common, forcing the answerer to verify once more. Include our own hypothesis about which part looks off.

Closing thoughts

A good question is the skill of reducing the answerer's time and getting our own answer fast. With the five together — six components, MRE, XY avoidance, environment info, organized attempts — answer speed and quality improve sharply. Building the MRE is itself debugging, so we often find the answer ourselves.

Next

• learning-roadmap
• debugging-mindset

How To Ask Questions The Smart Way (Eric S. Raymond, 2001) · Stack Overflow How to Ask · Stack Overflow Minimal Reproducible Example · XY Problem (Wikipedia) · No Hello · Don't ask to ask, just ask · OKKY · GeekNews for reference.