Cách Hỏi Để Người Khác Muốn Giúp

[00] Tóm tắt 30 giây

1. Tự tìm trước: đọc docs, tìm issue cũ, Google thông báo lỗi, hỏi AI. (chi tiết)
2. Hỏi đúng chỗ, hỏi công khai. (chi tiết)
3. Tiêu đề = tool + version + triệu chứng cụ thể. (chi tiết)
4. Nêu mục tiêu, môi trường, kỳ vọng và thực tế, những gì đã thử. (chi tiết)
5. Kèm MRE và đúng phần log liên quan, đặt trong code block. (chi tiết)
6. Lịch sự ngắn gọn, không gắn “URGENT”, giải xong thì quay lại báo lời giải. (chi tiết)

Muốn dùng ngay: copy mẫu câu hỏi ở mục [11].

[01] Nếu ai đó gửi bạn link này

$ Nhiều dự án mã nguồn mở link đến bài của ESR ở mục “Hướng dẫn đặt câu hỏi cho cộng đồng”. Đó là chuyện tốt — nhưng nếu bạn được dẫn tới đây vì vừa mới hỏi một câu dở, đừng nghĩ rằng cả cộng đồng đang chĩa mũi dùi vào mình.

Bài này không nhằm tát vào mặt bạn. Nó chỉ muốn nói rằng: muốn nhận được giúp đỡ chất lượng từ những người bận và không quen biết, bạn cần biết cách hỏi. Đọc xong, bạn sẽ giúp được chính mình và giúp được người trả lời.

[02] Mở đầu

Trong thế giới hacker — hiểu theo nghĩa người làm chủ kỹ thuật, viết phần mềm và yêu tự do thông tin, không phải “kẻ phá hoại máy tính người khác” — câu trả lời bạn nhận được phụ thuộc trực tiếp vào cách bạn đặt câu hỏi.

Hacker thường có những đặc điểm sau:

• Coi trọng vấn đề thú vị và giải pháp hay.
• Ghét lãng phí thời gian — đặc biệt là thời gian của mình bị lãng phí vì sự lười biếng của người khác.
• Tôn vinh năng lực tự tìm hiểu. Bạn càng cho thấy mình đã cố, càng dễ được giúp.

Văn hóa này có thể trông khắc nghiệt với người mới. Nhưng nó được tạo ra không phải để loại trừ ai. Nó tồn tại để bảo vệ một thứ rất quý: nguồn lực thời gian của những người sẵn lòng giúp người lạ miễn phí.

“Câu hỏi khôn mời gọi câu trả lời sâu. Câu hỏi lười mời gọi sự im lặng — hoặc tệ hơn.” — Diễn giải lại tinh thần bài viết của ESR

[03] AI giúp gì, khi nào vẫn nên hỏi người khác

Ở thời điểm hiện tại, dev mới có lợi thế rất lớn: bạn có thể hỏi ChatGPT, Claude, Cursor, Gemini... để tự debug, đọc lỗi, giải thích khái niệm, viết test nhỏ, hoặc tạo một checklist kiểm tra trước khi làm phiền người khác.

Nhưng AI không thay thế hoàn toàn cộng đồng hay người có kinh nghiệm. Sẽ có lúc bạn vẫn nên hỏi người khác, đặc biệt khi:

• Bug quá nhiều ngữ cảnh. Lỗi phụ thuộc vào repo, dữ liệu, hạ tầng, lịch sử thay đổi, hoặc quyết định kỹ thuật nội bộ.
• Cần review hướng làm. Bạn không chỉ cần câu lệnh fix, mà cần biết cách tiếp cận có đúng, có maintainable, có ảnh hưởng lâu dài không.
• Đụng production. Khi có rủi ro mất dữ liệu, downtime, bảo mật, tiền bạc, hoặc ảnh hưởng người dùng thật, cần thêm mắt người kiểm tra.
• Framework/tool lạ hoặc edge case mới. AI có thể tự tin trả lời sai, nhất là với API mới, version mới, hoặc hành vi ít người gặp.
• Business logic riêng. Chỉ team hoặc cộng đồng dự án mới hiểu tại sao hệ thống được thiết kế như vậy.
• Cần góc nhìn thực tế. Có những câu trả lời đúng về mặt kỹ thuật nhưng không hợp với deadline, team size, vận hành, hoặc văn hóa dự án.

[04] Trước khi hỏi

Trước khi bạn đặt một câu hỏi kỹ thuật trên Discord, Stack Overflow, GitHub Issues hay bất kỳ nơi nào, hãy lần lượt làm những việc sau:

1. Đọc tài liệu. Đọc README, docs/, FAQ, manual của tool.
2. Tìm trong archive. Tìm trong issue cũ (đóng & mở), Stack Overflow, mailing list archive.
3. Google nó. Copy nguyên thông báo lỗi vào ô search. Rất có thể đã có người gặp trước bạn.
4. Hỏi AI / LLM. ChatGPT, Claude, Cursor, Gemini... giải được khá nhiều bug phổ thông. AI trả lời riêng cho bạn, hỏi lại bao nhiêu lần cũng được mà không tốn thời gian của ai.
5. Tự thử nghiệm. Đọc code nguồn nếu có. In log. Tạo một ví dụ tối giản tái hiện lỗi (MRE).
6. Hỏi một người bạn thạo việc. Trước khi hỏi cả thế giới, hỏi một người cụ thể nếu có.

Khi đã làm hết những bước trên mà vẫn bí — lúc đó hãy mang câu hỏi đến cộng đồng. Hãy nói luôn rằng bạn đã thử những gì. Câu mở đầu kiểu “I read X, tried Y and Z, and got…” khiến bạn ngay lập tức được xếp vào nhóm người đáng giúp.

[05] Chọn nơi hỏi

Chọn forum cẩn thận

Đăng câu hỏi sai chỗ là cách nhanh nhất để không nhận được trả lời. Một số nguyên tắc:

• Đừng đăng câu hỏi người dùng vào kênh developer của dự án.
• Đừng đăng câu hỏi C++ vào forum Python chỉ vì bạn quen ở đó.
• Đừng spam cùng câu hỏi ra 5 nơi (cross-posting trắng trợn). Nếu phải post nhiều nơi, nói rõ và link chéo.
• Đừng nhắn DM riêng một maintainer chỉ để hỏi điều mà cộng đồng có thể giúp. Họ không phải nhân viên hỗ trợ riêng của bạn.

Stack Overflow / Stack Exchange

Với phần lớn câu hỏi lập trình thuần kỹ thuật, khi cần hỏi công khai thì Stack Overflow thường là nơi phù hợp nhất. Hãy tìm trước: rất nhiều câu hỏi mới thật ra đã có người hỏi rồi.

Khi đăng câu hỏi mới: dùng tag chính xác, viết tiêu đề như một câu hỏi cụ thể, kèm MRE chạy được, kèm thông báo lỗi đầy đủ, và nêu rõ bạn kỳ vọng gì & nhận được gì.

Web forum / Discord / Slack / IRC

Các kênh chat real-time (Discord, Slack, IRC, Telegram…) phù hợp với thảo luận nhanh, không phù hợp với câu hỏi phức tạp cần lưu trữ. Lưu ý:

• Đừng “xin phép để hỏi” rồi biến mất. Cứ hỏi thẳng. Nguyên tắc: “Don't ask to ask, just ask.”
• Đừng paste 200 dòng log vào kênh chat. Dùng pastebin / gist / code block.
• Câu hỏi cần đào sâu > 30 phút thì chuyển sang GitHub Issues hoặc forum có archive.
• Đừng kỳ vọng câu trả lời ngay. Người trả lời ở khắp múi giờ.

Mailing list & GitHub Issues

Khi câu hỏi liên quan đến dự án cụ thể: vào trang dự án, đọc CONTRIBUTING.md, và dùng đúng kênh họ chỉ định. Hai lựa chọn phổ biến hiện nay:

• GitHub Issues / Discussions: cho bug và câu hỏi về dự án.
• Mailing list dev/user: vẫn tồn tại trong nhiều dự án lâu năm (Linux kernel, Postgres, Debian…).

Đừng nhầm user list với dev list. Hỏi “Why does the app crash when I click Save?” trên dev list là đang lấy thời gian của chính những người viết ra tool đó.

[06] Viết câu hỏi

Phần này đi theo đúng thứ tự bạn viết một câu hỏi: tiêu đề, mục tiêu, thông tin, code, rồi soát lại cách trình bày.

Tiêu đề rõ ràng, cụ thể

HELP!!!
not working
Question
Bug??
pls help urgent

X11 mouse cursor distorted on Nvidia RTX 4090 with kernel 6.7

Postgres 16: pg_dump fails with "SSL SYSCALL error: EOF detected" on tables > 2GB

Next.js 14 (App Router): hydration mismatch only on iOS Safari

Công thức: [tool + version]: [triệu chứng cụ thể] [khi nào / điều kiện gì]. Tiêu đề dở không cho người đọc biết gì. Tiêu đề tốt cho biết ngay đây là tool nào, lỗi gì, xảy ra khi nào — nên đúng người biết sẽ bấm vào.

Mẹo: viết tiêu đề như một dòng commit message — ngắn, cụ thể, đúng trọng tâm.

Mô tả mục tiêu, không phải các bước của bạn (XY Problem)

Luôn nêu mục tiêu cuối cùng trước khi nêu các bước. Người trả lời có thể chỉ cho bạn cách làm X tốt hơn nhiều so với Y.

Chính xác và đủ thông tin về vấn đề

Trình bày tối thiểu các thông tin sau:

• Triệu chứng: bạn thấy gì? (kèm log/screenshot nếu cần)
• Môi trường: OS, version, phần cứng liên quan, version của tool.
• Bạn đã làm gì để xảy ra điều đó? (các bước reproduce)
• Bạn đã thử gì để fix?
• Bạn kỳ vọng gì, và thực tế nhận được gì?

Muốn khỏi sót, dùng mẫu câu hỏi ở mục [11].

Mô tả triệu chứng, không phải phỏng đoán

Đừng nói: “I think Node's GC is leaking memory.” Trừ khi bạn đã profile và có bằng chứng. Hãy nói: “RSS grows steadily by ~5MB/min over 2 hours. Heap snapshot attached.”

Chuyên gia có thể đọc triệu chứng và đoán đúng nguyên nhân. Họ không thể đọc phỏng đoán của bạn và đoán ra triệu chứng.

Mô tả theo trình tự thời gian

“I installed A, then B, then upgraded C. After that, X started failing.” có giá trị hơn nhiều so với “X is failing and I don't know why.” Nguyên nhân thường nằm ở thay đổi gần nhất.

Khi hỏi về code

MRE (Minimal Reproducible Example) là đoạn code nhỏ nhất chạy được mà vẫn tái hiện đúng lỗi — thường khoảng 20 dòng, bỏ hết phần không liên quan. Đây là thứ giá trị nhất bạn có thể kèm theo câu hỏi. Nhiều khi, ngay trong lúc rút gọn, bạn đã tự tìm ra lỗi.

• Kèm MRE: dán thẳng vào code block, hoặc link tới repo / StackBlitz / gist.
• Nói rõ bạn kỳ vọng output gì, thực tế output gì.
• Đính kèm phiên bản ngôn ngữ, OS, build tool.
• Đừng paste cả project. Rút gọn trước, đăng sau.
• Nói rõ lỗi xảy ra lúc build hay lúc chạy.

Nhiều thông tin chưa chắc đã đúng trọng tâm

Đừng dump cả 5000 dòng log vào tin nhắn. Hãy đọc qua, chọn đúng phần liên quan, kèm context tối thiểu. Một MRE 20 dòng có giá trị hơn một repo 200 file.

Định dạng chuẩn, dễ đọc

• Code & log dùng code block, không paste như văn bản thường.
• Đừng gửi câu hỏi dưới dạng ảnh chụp màn hình của một đoạn text. Người ta không grep được ảnh.
• Đừng gửi file .docx, .pdf chỉ để chứa 5 dòng code.
• Code/log dài thì đưa lên gist / pastebin / repo tái hiện lỗi rồi gửi link.

Viết rõ ràng, đúng chính tả & ngữ pháp

Người viết cẩu thả thường suy nghĩ cẩu thả. Nếu bạn không buồn kiểm tra chính tả, người trả lời sẽ đoán rằng bạn cũng không buồn debug.

Không cần văn vẻ hoa mỹ. Chỉ cần câu hoàn chỉnh, dấu câu đúng, viết hoa đầu câu. Nếu không thạo tiếng Anh, nói rõ ngay từ đầu — cộng đồng sẽ rộng lượng. Có thể nhờ AI hoặc công cụ dịch sửa câu cho rõ, nhưng giữ nguyên code, log và thông báo lỗi. Đừng tỏ ra lười.

Đặt câu hỏi rõ ràng & có giới hạn

“Can someone explain microservices to me?” là câu hỏi mở vô tận. Không ai có thời gian. Thu hẹp lại: “I'm splitting a Django monolith into services. How do I handle a transaction that spans two services without using two-phase commit (2PC)?”

Bỏ những câu hỏi thừa ở cuối

Đừng kết bài bằng những câu không có nội dung như “Can anyone help me?” hay “Is there an answer?”. Nếu phần mô tả đã ổn thì mấy câu này thừa. Tệ hơn, chúng dễ nhận lại câu trả lời đúng về logic nhưng vô ích: “Yes, you can be helped.”

Thay vào đó, kết bằng đúng câu bạn muốn được trả lời: “What's the right way to configure X so that Y?”

[07] Thái độ khi hỏi

Đừng vội kêu “đây là bug”

Trừ khi bạn rất chắc, đừng mở đầu bằng “Tool này có bug khi…”. Đa số trường hợp là người dùng dùng sai hoặc hiểu sai. Cách diễn đạt khôn ngoan hơn:

“I'm seeing the following behavior and I'm not sure whether I'm using it wrong or it's a bug. I expected X, but got Y. Version: …”

Nếu hóa ra bạn dùng sai, cách nói này giúp bạn không bị mất mặt.

Nịnh không thay được tự học

“I'm a beginner, please help me experts!” không phải tấm vé miễn phí. Người trả lời quan tâm bạn đã cố gắng gì, không phải bạn khiêm tốn tới đâu. Khiêm tốn thì tốt, nhưng nó không thay được việc cho thấy bạn đã thử những gì.

Đừng gắn nhãn “KHẨN” / “URGENT”

Việc của bạn khẩn — không phải việc của người trả lời. Gắn “urgent” thường có tác dụng ngược: câu hỏi của bạn sẽ bị bỏ qua, vì bạn đang yêu cầu ưu tiên mà không có quyền.

Ngoại lệ: lỗ hổng bảo mật có nguy cơ bị khai thác. Khi đó đừng đăng công khai — làm theo hướng dẫn trong SECURITY.md của dự án để báo riêng cho maintainer.

Lịch sự vừa đủ

“Please”, “Thanks in advance”, “Thanks for your time either way” đều miễn phí và giúp câu hỏi dễ được đón nhận hơn. Một câu cảm ơn ngắn ở cuối là đủ.

Cái cần bỏ là chuỗi lời chào và kính ngữ kéo dài kiểu “Please please help me, I really need this, thank you so much in advance, I will be very grateful!!!” Nó không làm câu hỏi tốt hơn, chỉ bắt người đọc lướt qua thêm một đoạn. Nhớ: lịch sự là cộng thêm, không phải thay thế cho nội dung tốt.

Hỏi công khai, đừng đòi trả lời riêng

Đừng kết câu hỏi bằng “Please email me directly, I don't check this forum.” Câu đó ngầm nói: tôi quan trọng hơn cộng đồng của bạn. Người ta sẽ bỏ qua.

Hỏi công khai thì nhận trả lời công khai. Đó là cách kiến thức được lưu lại và giúp được người tiếp theo gặp vấn đề tương tự. Đòi trả lời riêng cũng giống như coi cộng đồng là tổng đài hỗ trợ của riêng mình.

Đừng post bài tập về nhà

Người trả lời nhận ra bài tập trên lớp rất nhanh. Việc làm bài hộ không giúp bạn học. Nếu bạn thực sự kẹt, hãy nói rõ bạn đang học, đã thử cách nào, bí ở bước nào — chứ không phải đăng nguyên đề bài rồi chờ ai đó submit hộ.

Báo lại lời giải

Khi bạn đã giải quyết được vấn đề, quay lại post một note ngắn mô tả lời giải. Việc này:

• Cảm ơn cộng đồng đúng cách.
• Giúp người tiếp theo google ra câu trả lời.
• Tăng uy tín của bạn trong cộng đồng.

Một câu hỏi tốt kèm lời giải là tài sản của cộng đồng. Còn nếu bạn bỏ đi sau khi đã giải xong, người sau sẽ tìm thấy đúng câu hỏi của bạn nhưng không có lời giải.

[08] Cách đọc câu trả lời

RTFM và STFW — Khi bạn nhận được hai chữ này

RTFM = “Read The F***ing Manual.” STFW = “Search The F***ing Web.” Nhận được hai cụm này nghĩa là người trả lời cho rằng:

• Bạn nên tự tìm được câu trả lời trong vài phút.
• Bạn đã không buồn tìm trước khi hỏi.

Phản ứng đúng không phải tự ái. Phản ứng đúng là: cảm ơn, đi đọc manual, đi search web. Sau đó nếu vẫn không hiểu, quay lại với câu hỏi tinh hơn nhiều.

Nếu bạn không hiểu câu trả lời

Đừng vội đáp “Tôi không hiểu, giải thích lại được không?” Hãy chứng tỏ bạn đã cố hiểu:

“Thanks. I tried X as you suggested, but got Y. I think I'm misunderstanding Z. Did you mean…?”

Đối phó với “thô lỗ”

Phần lớn cái trông như thô lỗ trong cộng đồng kỹ thuật không phải là sự xúc phạm cá nhân. Đó là văn hóa truyền đạt thẳng, không vòng vo. Khi một người có kinh nghiệm bảo bạn “điều bạn vừa nói là sai”, đó không phải tấn công — đó là dữ liệu.

Tách câu chữ ra khỏi giọng điệu. Lấy phần kỹ thuật, bỏ qua phần thô. Đáp trả gay gắt chỉ làm cuộc trao đổi tệ thêm, và người khác sẽ ngại giúp bạn.

Tuy nhiên, có ranh giới: tấn công cá nhân, kỳ thị, hoặc chế giễu chủng tộc/giới tính KHÔNG phải “văn hóa hacker”. Đó là độc hại. Báo cáo cho moderator của diễn đàn đó.

Đừng phản ứng như “kẻ thua cuộc”

Sai một câu hỏi không phải tận thế. Đừng:

• Xóa post của mình rồi giả vờ chưa từng xảy ra.
• Chửi lại cả thread.
• Spam câu hỏi mới y hệt sang chỗ khác.
• Bỏ chạy khỏi cộng đồng vĩnh viễn.

Cách thắng: cảm ơn người chỉ cho mình điều mình làm sai, sửa, hỏi lại tốt hơn lần sau. Cộng đồng nhớ người học nhanh hơn là người không bao giờ sai.

[09] Những câu hỏi không nên hỏi

Dưới đây là một số dạng câu hỏi kinh điển khiến người trả lời quay lưng — kèm cái họ đang nghĩ nhưng có thể không nói ra, và cách hỏi lại cho tốt:

[10] Câu hỏi tốt và câu hỏi dở — ví dụ thực tế

Title: HELP!!!

my react app not working. when i click the button nothing happen and everything disappear. pls help, thank you so much in advance!!!

Title: React 18 + Vite: clicking a <button> inside a <form> reloads the page and resets state

Environment: React 18.2, Vite 5.1, Chrome 121, macOS 14

Goal: an "Add item" button that appends a row to a list kept in useState.

Expected: clicking the button adds one row.
Actual: the page reloads and the list goes back to empty. No error in the console.

What I've tried:
- console.log inside onClick: the log shows up, then the page reloads (seen with "Preserve log" enabled in DevTools).
- Moving the button outside the <form>: works as expected.

MRE (15 lines): https://stackblitz.com/edit/xxx

Question: why does a button inside a form reload the page, and what's the right way to keep it inside the form?

Người trả lời đọc xong là thấy ngay nguyên nhân: <button> nằm trong <form> mặc định là type="submit", nên bấm vào sẽ submit form và reload trang. Sửa bằng type="button". Câu hỏi đủ dữ kiện thì câu trả lời đến rất nhanh.

Title: Database very slow

my database is very slow, anyone know why?

Title: Postgres 16: 3-table JOIN went from 2.5s to 18s after data doubled (~50M rows)

Query:
  SELECT o.id, o.created_at, u.email, SUM(i.price * i.qty) AS total
  FROM orders o
  JOIN users u ON u.id = o.user_id
  JOIN items i ON i.order_id = o.id
  WHERE o.status = 'paid'
    AND o.created_at >= now() - interval '30 days'
  GROUP BY o.id, u.email;

- EXPLAIN (ANALYZE, BUFFERS): https://explain.dalibo.com/plan/xyz
- Existing indexes: idx_users_email, idx_orders_user_id, idx_items_order_id
- shared_buffers=4GB, work_mem=64MB, effective_cache_size=12GB (16GB RAM)
- All three tables were ANALYZEd 2 hours ago

Question: the plan does a seq scan on orders, although the WHERE clause matches only ~2% of rows. Is a composite index on orders(status, created_at) the right fix, or am I missing something?

Sự khác biệt không nằm ở số lượng chữ. Nó nằm ở chất lượng dữ kiện bạn cung cấp. Câu hỏi tốt đã làm sẵn phần lớn việc cho người trả lời — họ chỉ cần đưa ra mảnh ghép cuối.

[11] Mẫu câu hỏi

Copy mẫu dưới đây, điền vào, xóa mục nào không liên quan. Không cần đủ hết, nhưng Goal, Expected, Actual và What I've tried gần như lúc nào cũng cần.

Title: <Tool + version>: <specific symptom> <when / under what condition>

Goal
<What you are ultimately trying to do, in one or two sentences.>

Environment
- OS:
- Language / runtime + version:
- Library / framework + version:

Steps to reproduce
1.
2.
3.

Expected
<What you expected to happen.>

Actual
<What actually happened. Paste the full error message in a code block.>

What I've tried
- <Attempt 1> → <result>
- <Attempt 2> → <result>

Minimal reproducible example
<Link to a repo / StackBlitz / gist, or ~20 lines of code in a code block.>

Question
<The one specific question you want answered.>

[12] Nếu không có ai trả lời

Đừng coi đó là chuyện cá nhân. Có nhiều lý do hợp lý:

• Câu hỏi của bạn quá đặc thù, không ai từng gặp.
• Câu hỏi quá rộng, không ai đủ rảnh để trả lời tử tế.
• Bạn đang hỏi sai nơi.
• Không ai biết câu trả lời. (Có thật.)

Hành động tiếp:

1. Đợi đủ thời gian (24-72h tùy kênh). Đừng bump (đẩy bài lên lại) sau 10 phút.
2. Xem lại câu hỏi. Có thể viết lại cô đọng & rõ hơn?
3. Thử kênh khác phù hợp hơn (đề cập chéo nhưng đừng spam).
4. Nếu là dự án thương mại: có thể bạn cần support trả phí. Cộng đồng mã nguồn mở không phải hỗ trợ kỹ thuật 24/7.
5. Tiếp tục tự debug. Đôi khi quá trình viết câu hỏi đã giúp bạn nhận ra lời giải (rubber duck debugging).

[13] Mặt còn lại: cách trả lời câu hỏi cho tử tế

Nếu bạn là người trả lời, cộng đồng cũng cần bạn theo những nguyên tắc này:

• Nhẹ nhàng. Người hỏi đang căng thẳng. Khắt khe với người mới thì lâu dần cộng đồng sẽ không còn người mới.
• Nếu trả lời, trả lời cho ra hồn. Đừng đáp nửa vời, để người hỏi đoán phần còn lại.
• Hỏi lại để làm rõ trước khi mắng. Đôi khi câu hỏi dở chỉ vì người hỏi chưa biết phải cung cấp gì.
• Chỉ cách tìm, đừng chỉ đưa đáp án. Link tới doc, tới tag Stack Overflow, tới tool. Dạy cách câu cá quan trọng hơn việc cho cá.
• Đừng chế nhạo người mới. Bạn cũng từng là người mới. Câu trả lời của bạn sẽ được người khác đọc trong nhiều năm.
• Nếu không trả lời, đừng phá thread. Im lặng tốt hơn nhiều so với một câu “lol” hoặc “noob”.
• Đáp công khai khi có thể. Một câu trả lời tốt sẽ thành tài liệu cho rất nhiều người đến sau.

[14] Tài nguyên liên quan

• Bài gốc — How To Ask Questions The Smart Way
• How To Become A Hacker — ESR
• Stack Overflow: How do I ask a good question?
• Stack Overflow: Minimal Reproducible Example (MRE)
• The XY Problem
• No Hello Club — đừng chỉ chào rồi đợi người ta hỏi “bạn cần gì”.
• Don't Ask To Ask, Just Ask

[15] Lời cảm ơn

Bản gốc của Eric S. Raymond và Rick Moen đã định hình văn hóa hỏi-đáp kỹ thuật trong suốt 20+ năm. Hướng dẫn tiếng Việt này được viết với mong muốn giúp lập trình viên nói tiếng Việt tham gia cộng đồng quốc tế một cách tự tin và được giúp đỡ.

Nếu bài viết hữu ích, hãy chuyển nó cho người tiếp theo bạn thấy đang chuẩn bị đăng một câu hỏi mơ hồ trong một group lập trình.