提问的智慧（How To Ask Questions The Smart Way）

Quản lý diễn đàn Thông Báo & Quy Định
1

Nguyên văn: How To Ask Questions The Smart Way

Dịch: Vương Cương<yafrank at 126 dot com>
Thời gian: 26 tháng 10 năm 2013
Nội dung

Mục lục

Bản dịch: tiếng Indonesia, tiếng Belarus, tiếng Bồ Đào Nha Brasil, tiếng Trung giản thể, tiếng Hà Lan, tiếng Pháp, tiếng Gruzia, tiếng Đức, tiếng Hy Lạp, tiếng Do Thái, tiếng Nhật, tiếng Ba Lan, tiếng Bồ Đào Nha, tiếng Rumani, tiếng Nga, tiếng Tây Ban Nha, tiếng Thái. Nếu bạn muốn sao chép, làm gương, dịch hoặc trích dẫn bài này, vui lòng xem bản quyền của tôi.* Tiếng Anh không phải là tiếng mẹ đẻ của tôi, xin hãy thông cảm cho các lỗi chính tả.

  • Nếu bạn dùng ngôn ngữ某某, vui lòng gửi email/nhắn riêng cho tôi, có thể tôi cần bạn hỗ trợ dịch câu hỏi của mình.
  • Tôi rất thành thạo với thuật ngữ kỹ thuật này, nhưng lại không hiểu lắm một số cách dùng lóng hoặc thành ngữ của nó.
  • Tôi đã đặt câu hỏi bằng cả某某ngữ lẫn tiếng Anh; nếu bạn trả lời bằng một trong hai, tôi sẵn sàng dịch lại.

Gửi câu hỏi bằng định dạng tập tin dễ đọc và chuẩn

Nếu bạn cố tình làm câu hỏi khó đọc, khả năng cao nó sẽ bị bỏ qua; mọi người thích đọc thứ dễ hiểu, vì vậy:

  • Dùng văn bản thuần thay vì HTML (tắt HTML không hề khó)
  • Đính kèm MIME thường không vấn đề, miễn là có nội dung thực (ví dụ: mã nguồn hoặc bản vá), chứ không chỉ là mẫu do chương trình mail tạo ra (ví dụ: bản sao nội dung thư).
  • Đừng gửi mail chỉ toàn câu đơn rồi ngắt dòng liên tục (khó trích dẫn từng phần). Hãy tưởng tượng người đọc đang dùng terminal 80 cột; đặt ngắt dòng dưới 80 ký tự.
  • Tuy nhiên, cũng đừng bao giờ ngắt dòng cố định đối với dữ liệu “nguyên bản” (ví dụ: log hoặc bản ghi phiên làm việc). Hãy giữ nguyên để người trả lời thấy họ đang xem thứ giống bạn.
  • Trong diễn đàn tiếng Anh, đừng dùng mã hóa MIME ‘Quoted-Printable’. Mã này có thể cần cho ngôn ngữ không-ASCII, nhưng nhiều chương trình mail không hỗ trợ; các ký tự “=20” rải rác rất xấu và gây mất tập trung, thậm chí phá hỏng ngữ nghĩa.
  • Đừng bao giờ trông chờ hacker đọc tài liệu đóng dạng chuyên dụng như Word hay Excel. Phần lớn hacker phản ứng như bạn thấy ai đổ phân lợn nóng hổi trước cửa. Dù họ có thể xử lý, cũng rất ghét làm vậy.
  • Nếu gửi mail từ Windows, tắt “Smart Quotes” rắc rối (Tools → AutoCorrect Options → AutoFormat As You Type → bỏ tích “Straight quotes” with “smart quotes”) để khỏi rải rác ký tự rác.
  • Trong diễn đàn, đừng lạm dụng emoticon và HTML (nếu có). Một hai emoticon thường không sao, nhưng chữ màu sặc sỡ khiến người ta nghĩ bạn kém cỏi. Lạm dụng emoticon, màu mè, font kỳ dị khiến bạn trông như cô bé cười ngớ ngẩn—thường không hay, trừ khi bạn muốn sex hơn là câu trả lời hữu ích.
  • Nếu dùng mail client GUI (Netscape Messenger, Outlook, v.v.), nhớ cấu hình mặc định có thể không đáp ứng yêu cầu trên. Hãy dùng lệnh “View Source” để kiểm tra thư đã gửi, đảm bảo chỉ là plain text không tạp chất.

Mô tả vấn đề chính xác và có nội dung

  • Mô tả triệu chứng thật cẩn thận, rõ ràng.
  • Mô tả môi trường xảy ra lỗi (máy chủ, hệ điều hành, ứng dụng liên quan), kèm phiên bản phát hành (ví dụ: “Fedora Core 7”, “Slackware 9.1”).
  • Mô tả những gì bạn đã tìm hiểu và hiểu được trước khi hỏi.
  • Mô tả các bước chẩn đoán bạn đã thử để xác định vấn đề.
  • Mô tả mọi thay đổi gần đây trên máy hoặc cấu hình phần mềm.
  • Nếu có thể, cung cấp cách tái hiện lỗi trong môi trường kiểm soát.
  • Cố gắng đoán trước câu hỏi của hacker và chuẩn bị sẵn câu trả lời.

Nếu nghi ngờ lỗi nằm ở code, việc cung cấp cách tái hiện là cực kỳ quan trọng; khi đó bạn sẽ nhận được trả lời hữu ích và nhanh chóng hơn nhiều.

Simon Tatham đã viết bài How to Report Bugs Effectively, tôi khuyên mọi người nên đọc.

Lượng không quan trọng, ngắn gọn mới quý

Hãy viết ngắn gọn nhưng có nội dung; chèn cả đống code hay dữ liệu thô vào tin nhắn thì vô ích. Nếu có test case lớn và phức tạp khiến chương trình crash, hãy cắt gọn càng nhiều càng tốt.

Có ít nhất ba lý do:

  1. Người khác thấy bạn cố gắng thu gọn sẽ dễ trả lời hơn.
  2. Thu gọn giúp bạn dễ nhận được trả lời hữu ích.
  3. Trong quá trình thu gọn, bạn có thể tự tìm ra giải pháp hoặc cách vượt qua.

Đừng vội tuyên bố tìm được bug

Khi gặp sự cố phần mềm, trừ khi bạn rất, rất chắc chắn, đừng khẳng định đó là bug. Lưu ý: trừ khi bạn gửi kèm bản vá mã nguồn hoặc chứng minh bằng kiểm thử hồi quy, bạn vẫn chưa đủ cơ sở. Điều này cũng áp dụng cho tài liệu: nếu bạn “tìm thấy bug” trong tài liệu, hãy cung cấp văn bản thay thế.

Nhớ rằng còn nhiều người dùng khác không gặp lỗi bạn gặp, nếu không bạn đã thấy khi đọc tài liệu hay tìm web (bạn đã làm chứ?). Điều đó có nghĩa khả năng cao là bạn nhầm chứ không phải phần mềm lỗi.

Người viết phần mềm đã rất cố gắng làm mọi thứ hoàn hảo. Nếu bạn tuyên bố có bug, bạn đang nghi ngờ khả năng của họ; dù bạn đúng, cũng có thể khiến một số người khó chịu. Gào “BUG!” trên tiêu đề cũng rất kém duyên.

Khi hỏi, dù bạn chắc chắn phát hiện bug thực sự, hãy viết như thể bạn đã làm sai. Nếu đúng bug, bạn sẽ thấy trong câu trả lời. Làm vậy, nếu có bug, người bảo trì sẽ xin lỗi bạn—tốt hơn là bạn làm hỏng rồi phải xin lỗi họ.

Khúm núm không thay được việc tự học

Một số người biết không nên thô lỗ, nhưng lại đi cực đoan ngược lại: “Em chỉ là kẻ thất bại nghèo nàn, nhưng …”. Điều này vừa gây khó chịu vừa vô ích, đặc biệt khi kèm mô tả mơ hồ.

Đừng lãng phí thời gian bằng cách khỉ đầu chóng, thay vào đó mô tả rõ hoàn cảnh và câu hỏi—cách đó tôn trọng bạn hơn là khúm núm.

Đôi khi diễn đàn có mục dành người mới; nếu bạn nghĩ câu hỏi của mình nông cạn, cứ đến đó, nhưng cũng đừng khúm núm.

Mô tả triệu chứng, đừng đoán nguyên nhân

Nói với hacker nguyên nhân thường vô ích (nếu lý thuyết của bạn tuyệt vời, bạn còn hỏi họ làm gì?). Vì vậy, chỉ nêu triệu chứng gốc, để họ giải thích và chẩn đoán. Nếu bạn muốn nêu phỏng đoán, hãy ghi rõ đó chỉ là đoán và giải thích tại sao nó không ăn thua.

Dở:

Tôi gặp lỗi SIG11 khi biên dịch kernel, nghi ngờ có sợi dây trên main bị đứt, cách tìm tốt nhất là gì?

Khôn:

Máy tôi tự ráp (CPU K6/233, main FIC-PA2007 [chipset VIA Apollo VP2], RAM Corsair PC133 256 Mb) gần đây liên tục báo SIG11 khoảng 20 phút sau khi boot rồi biên dịch kernel, nhưng 20 phút đầu không sao. Khởi động lại không reset đồng hồ, nhưng tắt đêm lại thì được. Thay toàn bộ RAM không cải thiện, log phiên biên dịch điển hình đính kèm.

Vì nhiều người không nắm được, xin nhắc: “Mọi chuyên gia chẩn đoán đều đến từ tiểu bang Missouri.” Phương châm chính thức của bang Missouri là “Cho tôi xem” (từ bài phát biểu năm 1899 của dân biểu Willard D. Vandiver: “Tôi đến từ vùng đất của ngô, bông, cây ngưu bàng và đảng Dân chủ; hùng biện không thuyết phục hay làm tôi hài lòng. Tôi đến từ Missouri, bạn phải cho tôi xem.”) Đối với người chẩn đoán, đây không phải nghi ngờ mà là yêu cầu hữu ích để họ thấy bằng chứng gốc giống bạn thấy, chứ không phải phỏng đoán hay tóm tắt của bạn. Vì vậy, hãy cho họ xem.

Liệt kê triệu chứng theo thứ tự thời gian

Những gì xảy ra ngay trước lỗi thường chứa manh mối quý giá nhất. Vì vậy, hãy ghi chính xác bạn, máy và phần mềm đã làm gì trước khi crash. Trong môi trường dòng lệnh, log phiên (ví dụ: từ script) và trích 20 dòng liên quan rất hữu ích.

Nếu chương trình crash có tùy chọn gỡ lỗi (ví dụ: -v), hãy bật để log thêm thông tin. Nhớ: “nhiều” ≠ “tốt”. Chọn mức độ gỡ lỗi phù hợp để cung cấp thông tin hữu ích chứ không nhấn chìm người đọc.

Nếu log dài (trên bốn đoạn), nên tóm tắt ngắn ở đầu, sau đó liệt kê chi tiết theo thứ tự thời gian để hacker biết nên để ý chỗ nào.

Mô tả mục tiêu, không phải quá trình

Nếu bạn muốn biết làm cách nào (chứ không báo lỗi), hãy nêu mục tiêu tổng quát trước, rồi mới nói bước cụ thể bạn bí.

Thường gặp: người hỏi có mục tiêu cao hơn, bí trên con đường tưởng đúng, rồi hỏi cách đi tiếp mà không nhận ra con đường đó có vấn đề, khiến người khác phải vất vả.

Dở:

Làm sao để trình đồ họa X cho tôi giá trị RGB thập lục phân?

Khôn:

Tôi đang thay thế bảng màu của bức ảnh bằng màu tự chọn; cách duy nhất tôi biết là sửa từng slot, nhưng không cho trình chọn màu của X nhập giá trị RGB thập lục phân.

Cách hỏi thứ hai giúp người khác gợi ý công cụ phù hợp hơn.

Đừng yêu cầu trả lời riêng qua email

Hacker cho rằng quy trình giải quyết phải công khai, minh bạch; nếu câu trả lời ban đầu thiếu sót, người giỏi hơn có thể sửa. Người trả lời cũng được ghi nhận kiến thức trước cộng đồng.

Yêu cầu trả lời riêng cắt ngang quy trình và phần thưởng đó. Đừng làm vậy; hãy để người trả lời quyết định—nếu họ làm riêng, thường vì họ thấy câu hỏi kém hoặc nông, không có giá trị với người khác.

Ngoại lệ hạn chế: nếu bạn chắc câu hỏi sẽ gây ra hàng loạt câu trả lời giống nhau, câu “Email cho tôi, tôi sẽ tổng hợp” rất hữu ích—nhưng bạn phải giữ lời.

Đặt câu hỏi cụ thể

Câu hỏi lan man thường bị xem là “hố thời gian” không đáy. Người có khả năng trả lời hay nhất thường bận nhất, nên họ rất nhạy cảm với hố thời gian và ghét những câu hỏi lan man.

Nếu bạn nêu rõ muốn người khác làm gì (chỉ hướng, gửi code, xem patch, v.v.), bạn dễ nhận được câu trả lời hữu ích. Điều đó giúp họ tập trung và gián tiếp đặt giới hạn thời gian họ bỏ ra—rất tốt.

Hãy tưởng tượng thế giới chuyên gia: nguồn chuyên môn thì dồi dào nhưng thời gian trả lời thì khan hiếm. Bạn yêu cầu càng ít thời gian, càng dễ được trả lời.

Vì vậy, thu hẹp câu hỏi để người trả lời bỏ ít thời gian nhất—không đơn thuần là thu gọn vấn đề. Ví dụ: “Xin chỉ giùm tài liệu X” thường khôn hơn “Giải thích X giùm”. Nếu code không chạy, nhờ người chỉ lỗi thường khôn hơn nhờ họ sửa hộ.

Về câu hỏi liên quan đến mã

Đừng yêu cầu người khác gỡ lỗi hộ mà không nói nên bắt đầu từ đâu. Dán vài trăm dòng code rồi nói “nó không chạy” sẽ bị phớt lờ. Chỉ cần dán vài chục dòng, rồi nói “sau dòng 7 đáng lẽ hiện nhưng lại hiện ”.Rất có khả năng bạn sẽ nhận được câu trả lời.

Cách mô tả vấn đề trong mã chính xác nhất là cung cấp một ví dụ thử nghiệm tối thiểu có thể tái hiện lỗi. Ví dụ thử nghiệm tối thiểu là gì? Đó là đoạn mã chỉ vừa đủ để tái hiện hành vi không mong muốn. Làm sao để tạo ra nó? Nếu bạn biết dòng hoặc đoạn mã nào gây ra lỗi, hãy sao chép nó và thêm vào lượng mã “bệ đỡ” vừa đủ để trở thành một ví dụ hoàn chỉnh (đủ để trình biên dịch, trình thông dịch hay bất kỳ công cụ xử lý nào chấp nhận). Nếu không thu hẹp được phạm vi, hãy sao chép toàn bộ mã rồi lần lượt gỡ bỏ những phần không liên quan. Càng nhỏ càng tốt (xem “ít nhưng mà chất”).

Không phải lúc nào cũng tạo được ví dụ siêu nhỏ, nhưng cố gắng là một bài tập tốt, có thể giúp bạn tự tìm ra lỗi. Kể cả không tìm được, hacker cũng thích thấy bạn đã nỗ lực, và họ sẽ hợp tác hơn.

Nếu chỉ cần người review code, nói rõ ngay từ đầu, đồng thời chỉ ra phần bạn muốn họ tập trung và lý do.

Đừng đăng bài kiểu “bài tập về nhà”

Hacker dễ nhận ra câu hỏi dạng “bài tập về nhà”. Hầu hết chúng tôi đã từng tự làm xong bài tập của mình—đó là việc của bạn. Hỏi gợi ý được, nhưng đừng xin lời giải hoàn chỉnh.

Nếu nghi ngờ đây là bài tập về nhà mà vẫn không làm được, thử hỏi trong nhóm người dùng, diễn đàn hoặc (sau cùng) mailing-list “user” của dự án. Dù hacker có nhận ra, người dùng lâu năm vẫn có thể gợi ý.

Gỡ bỏ yêu cầu vô nghĩa

Đừng thêm vào cuối bài kiểu “Có ai giúp được không?” hay “Có câu trả lời không?”. Thứ nhất, nếu mô tả còn thiếu, câu hỏi phụ đó cũng thừa. Thứ hai, nó khiến hacker khó chịu—họ có thể đáp lại mỉa mai: “Có, bạn sẽ được giúp” hoặc “Không, chẳng có câu trả lời nào cả”.

Nói chung, tránh hỏi câu “có/không”, trừ khi bạn chỉ muốn nhận đúng “có” hoặc “không”.

Đừng gắn cờ “khẩn cấp”, dù với bạn có thế nào

Đây là vấn đề của bạn, không phải của chúng tôi. Ghi “khẩn cấp” thường phản tác dụng: hầu hết hacker xóa thẳng, coi đó là thiếu lịch sự và ích kỷ. Ngoài ra, từ “khẩn” dễ kích hoạt bộ lọc spam, khiến người có thể trả lời chẳng bao giờ đọc được!

Có ngoại lệ rất hẹp: nếu bạn dùng phần mềm tại nơi cực kỳ nổi tiếng khiến cộng đồng phấn khích, có thể đáng đề cập deadline một cách lịch sự. Tuy nhiên đây là canh bạc: tiêu chí “gây phấn khích” của hacker khác bạn. Đăng từ trạm vũ trụ quốc tế được, nhưng đại diện tổ chức từ thiện thì gần như chắc chắn thất bại. Thậm chí tiêu đề “Khẩn: Cứu lấy chú hải cẩu dễ thương!” sẽ bị lảng tránh.

Nếu thấy khó tin, hãy đọc lại đoạn này cho tới khi hiểu mới đăng.

Lịch sự luôn có lợi

Hãy lịch sự: dùng “làm ơn”, “cảm ơn sự chú ý của bạn”, v.v. để người khác biết bạn trân trọng thời gian họ bỏ ra giúp đỡ miễn phí.

Thẳng thắn mà nói, điều này không thay thế cho cú pháp đúng, văn rõ ràng, chính xác, có nội dung và tránh định dạng chuyên dụng. Hacker thà đọc báo cáo lỗi hơi cộc nhưng kỹ thuật rõ ràng còn hơn báo cáo lịch sự mơ hồ.

Tuy nhiên, khi đã trình bày kỹ thuật ổn, lịch sự sẽ tăng khả năng nhận câu trả lời hữu ích.

(Chúng tôi lưu ý: điểm duy nhất từng bị một số hacker lâu năm phản đối nghiêm túc là cụm “Cảm ơn trước”; họ cho rằng ám chỉ “sau đó không cần cảm ơn nữa”. Khuyên của chúng tôi: hoặc nói “Cảm ơn trước” rồi sau đó vẫn cảm ơn lại, hoặc dùng “Cảm ơn sự chú ý”/“Cảm ơn sự quan tâm”.)

Sau khi giải quyết, gửi thêm dòng tóm tắt

Khi xong, hãy thông báo cho mọi người biết cách bạn giải quyết và cảm ơn lại. Nếu thảo luận trên mailing-list/newsgroup, nên đăng ngay trong chủ đề cũ, sửa tiêu đề thêm “[Đã xong]”, “[Đã giải quyết]” hoặc tương đương. Người thấy “Vấn đề X” và “Vấn đề X – Đã xong” sẽ biết không cần bỏ thời gian nữa.

Tin nhắn không cần dài: “Chào—dây mạng bị đứt! Cảm ơn mọi người – Bill” cũng tốt hơn không có gì. Nếu kỹ thuật không quá phức tạp, tóm tắt ngắn gọn, thân thiện còn hơn bản trường ca. Nêu hành động cuối cùng đã khắc phục, không cần kể lại toàn bộ quá trình.

Với vấn đề sâu, nên đăng tóm tắt lịch sử gỡ lỗi: mô tả trạng thái cuối, cách giải quyết, sau đó mới liệt kê đường mò tránh được. Đặt phần “đường mò” sau lời giải. Kể tên những người đã giúp—bạn sẽ có thêm bạn.

Ngoài lịch sự, có nội dung, kiểu “follow-up” này giúp người sau tìm thấy lời giải khi lục lại tài liệu, và khiến mọi người cảm thấy mình đã góp phần thành công. Nếu bạn không phải chuyên gia, hãy tin rằng cảm giác “gãi đúng chỗ ngứa” này rất quan trọng với những người đã giúp. Cuối cùng, nó giúp bạn tích lũy uy tín cho lần hỏi sau.

Hãy cân nhắc việc viết tài liệu hoặc bổ sung FAQ để người khác khỏi lặp lại vấn đề. Nếu thấy cần, gửi bản vá cho người duy trì.

Trong cộng đồng hacker, hành động “follow-up” tốt còn quan trọng hơn lịch sự thông thường—đó là cách bạn gây dựng danh tiếng, một tài sản quý giá.

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

“Đọc mẹ cái manual đi” (RTFM) và “Search mẹ Google đi” (STFW): hiểu rằng bạn đã sai

Truyền thống thiêng liêng: nếu bạn nhận được “RTFM”, người viết nghĩ bạn nên đọc manual. Họ thường đúng—hãy đọc.

“RTFM” có họ hàng trẻ hơn: “STFW” (Search The Fine Web). Người bảo bạn “search” cũng đúng—hãy search. (Cách nhẹ nhàng hơn: “Google là bạn đấy!”)

Trong diễn đàn, bạn cũng có thể được yêu cầu search tài liệu. Đừng trông chờ ở đó; hãy tự search trước khi hỏi.

Thông thường, người bảo bạn search đã mở sẵn manual/web chứa câu trả lời. Họ nghĩ:

  • Thứ nhất, thông tin dễ tìm.
  • Thứ hai, tự tìm học được nhiều hơn.

Đừng cảm thấy bị xúc phạm; theo chuẩn hacker, việc họ còn trả lời đã là tôn trọng bạn. Hãy cảm ơn họ.

Nếu vẫn không hiểu…

Đừng phản hồi ngay “Làm ơn giải thích”. Hãy dùng lại các công cụ đã dùng lúc đầu (manual, FAQ, web, bạn hiểu biết, v.v.). Nếu vẫn cần, thể hiện những gì bạn đã hiểu.

Ví dụ:
Không tốt: “‘Mục nhập X’ là gì?”
Tốt: “Tôi đã đọc manual, thấy mục X chỉ được đề cập ở switch -z/-p, nhưng không thấy cách xóa. Tôi đã thử… Tôi nhầm chỗ nào?”

Đối mặt thái độ thô lỗ

Nhiều hành vi “thô lỗ” trong cộng đồng hacker không phải cố ý; đó là phong cách thẳng thừng, tập trung giải quyết vấn đề hơn là làm người khác dễ chịu.

Nếu cảm thấy bị xúc phạm, hãy bình tĩnh. Nếu ai đó thực sự quá đáng, “tiền bối” trong list sẽ xử. Nếu không mà bạn nổi giận, rất có thể chính bạn bị xem là sai, giảm cơ hội nhận được giúp đỡ.

Thỉnh thoảng bạn gặp kẻ thật sự thô lỗ, vô bổ. Lúc đó, phản bác bằng lý lẽ sắc bén là chấp nhận được, nhưng phải CÓ CƠ SỞ. Sửa lưu ý sai và bắt đầu khẩu chiến chỉ cách nhau một sợi tóc. Nếu bạn là người mới, tốt nhất đừng liều.

(Có người cho rằng nhiều hacker mắc chứng tự kỷ nhẹ/Asperger; dù đúng sai, bạn cứ biết vậy để đối phó với “kỳ quặc” của họ—chúng tôi không quan tâm, chúng tôi THÍCH vậy.)

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

Bạn sẽ có lúc “làm vỡ” trong diễn đàn—bị chỉ ra cách bạn sai, có khi còn kèm màu mè. Điều tồi tệ nhất: than vãn, kêu bị xúc phạm, đòi xin lỗi, la hét, đe dọa kiện, than với sếp họ, v.v. Thay vào đó:

Hãy vượt qua. Điều đó bình thường, thậm chí lành mạnh.

Chuẩn mực cộng đồng chỉ được duy trì khi mọi người thực thi công khai. Đừng rên rỉ rằng mọi phê bình phải qua email riêng—không hoạt động vậy.

Có diễn đàn cấm chỉ trích để “giữ thân thiện”, kết quả: người có năng lực bỏ đi, chỉ còn lèo nhèo vô nghĩa.

Hãy nhớ: khi hacker bảo bạn sai và yêu cầu đừng tái phạm, họ đang quan tâm đến bạn và cộng đồng. Họ hoàn toàn có thể bỏ qua. Nếu không cảm ơn được, cũng giữ chút danh dự, đừng gào thét hay tự coi mình là “nạn nhân” mong được nâng niu như búp bê.

Đôi khi bạn bị tấn công oan. Khi đó, kêu ca sẽ làm mọi thứ tệ hơn. Những kẻ công kích thường hoặc “chuyên gia hờ”, hoặc đang “test” bạn. Đừng dính vào khẩu chiến—sau khi xác minh chúng chỉ là khẩu chiến thuần túy.

Những câu hỏi cấm kỵ

Dưới đây là các câu hỏi ngu điển hình và điều hacker nghĩ khi bỏ qua.

Hỏi: Tôi tìm chương trình X ở đâu?
Hỏi: Làm sao dùng X để làm Y?
Hỏi: Cấu hình prompt shell của tôi?
Hỏi: Có thể dùng Bass-o-matic đổi tài liệu AcmeCorp sang TeX?
Hỏi: {Chương trình, cấu hình, SQL} của tôi không chạy!
Hỏi: Máy Windows tôi bị lỗi, giúp với!
Hỏi: Chương trình tôi không chạy, chắc công cụ X hỏng!
Hỏi: Cài Linux/X bị lỗi, giúp với!
Hỏi: Làm sao hack root/đánh cắp quyền op/xem email người khác?

Hỏi: Tôi tìm chương trình X ở đâu?
Đáp: Ở chỗ tôi tìm thấy—trình tìm kiếm. Trời ơi, không ai biết dùng Google sao?

Hỏi: Làm sao dùng X làm Y?
Đáp: Nếu bạn cần Y, đừng đề xuất giải pháp có thể sai. Câu hỏi cho thấy bạn không hiểu X, cũng mơ hồ về Y. Hãy mô tả đúng bài toán.

Hỏi: Cấu hình prompt shell?
Đáp: Nếu đủ thông minh để hỏi, cũng đủ để RTFM.

Hỏi: Dùng Bass-o-matic đổi AcmeCorp→TeX?
Đáp: Thử đi. Xong bạn có câu trả lời và đừng lãng phí thời gian tôi.

Hỏi: {Chương trình, cấu hình, SQL} không chạy!
Đáp: Không phải câu hỏi; tôi không rảnh đoán. Phản ứng thường thấy:

  • Còn gì nữa không?
  • Ồ, tiếc quá, hy vọng bạn xong.
  • Liên quan gì đến tôi?

Hỏi: Máy Windows tôi bị lỗi?
Đáp: Gỡ bỏ Windows, cài Linux/BSD đi.
(Lưu ý: Nếu phần mềm có bản Windows chính thức hoặc tương tác Windows (Samba), bạn vẫn có thể hỏi, nhưng đừng ngạc nhiên nếu được bảo lỗi do Windows.)

Hỏi: Chắc công cụ X hỏng!
Đáp: Bạn có thể là người đầu tiên thấy lỗi trong thư viện hệ thống được hàng vạn người dùng, nhưng khả năng lớn hơn là bạn không có cơ sở. Khẳng định phi thường cần bằng chứng phi thường.

Hỏi: Cài Linux/X bị lỗi?
Đáp: Không, tôi cần ngồi trước máy bạn mới gỡ lỗi được. Tìm nhóm LUG địa phương.
(Lưu ý: Nếu lỗi liên quan distro cụ thể, hỏi list/forum của distro; trước đó search kỹ.)

Hỏi: Hack root/đánh cắp quyền/xem email?
Đáp: Muốn vậy chứng tỏ bạn đê tiện; muốn hacker dạy chứng tỏ bạn ngu.

Câu hỏi tốt – câu hỏi tồi

Cùng một vấn đề, cách hỏi ngu/ngon khác nhau.

Tồi: Tìm thông tin thiết bị Foonly Flurbamatic ở đâu? → đáng bị STFW.
Tốt: Tôi đã Google “Foonly Flurbamamic 2600” nhưng không được, ai biết chỗ có tài liệu lập trình?

Tồi: Code ngu vậy, không compile được! → kêu ca, tự cao.
Tốt: Code không compile trên Linux 6.2; đã đọc FAQ, không thấy; đây là log lỗi; tôi sai đâu?

Tồi: Mainboard tôi hỏng, giúp! → “Cần tôi thay tã luôn không?”
Tốt: Tôi thử X, Y, Z trên main S2464 đều thất bại, rồi A, B, C. Khi làm C có hiện tượng lạ… Trên main Athlon MP thì nguyên nhân thường gì? Tôi còn có thể thử gì thêm?

Chú ý khác biệt tinh tế: “Trả lời tôi” vs “Cho tôi thêm gợi ý để tự tìm”.

Câu hỏi cuối có thật trên lkml 8/2001 (Eric đăng). Nhờ cách hỏi đúng, anh nhận thông tin then chốt. Một thành viên lkml bảo: “Không phải vì tên cậu, mà vì cách cậu hỏi.” Hacker là dạng tinh hoa không khoan nhượng; nếu tôi hành xử như ký sinh, tôi bị lờ hoặc mắng. Anh đề nghị ghi lại làm hướng dẫn → bài viết này ra đời.

Không nhận được trả lời

Không có nghĩa chúng tôi không muốn giúp; có thể họ không biết. Im lặng ≠ bỏ rơi. Đừng repost—có thể bị xem là spam. Hãy kiên nhẫn; người biết có thể đang ngủ ở múi giờ khác, hoặc câu hỏi bạn ban đầu chưa rõ.

Còn nhiều nơi khác: nhóm người dùng, diễn đàn newbie, hoặc dịch hỗ trợ thương mại. Đừng buồn vì phải trả tiền—bạn vẫn rẻ hơn mua phần mềm đóng, và dịch vụ cho phần mềm đóng thường đắt hơn, kém hơn.

Cách trả lời tốt hơn

Tử tế. Áp lực câu hỏi khiến người ta có vẻ bất lịch sự; thực ra không phải.

Trả lời riêng cho người mới. Không cần làm nhục người thành thật; họ có thể không biết search hay FAQ.

Không chắc thì nói! Một câu sai trông “uyên thâm” còn tệ hơn im lặng. Khiêm tốn, trung thực.

Không giúp được thì đừng cản. Đừng đùa về bước cụ thể—kẻ nào đó sẽ làm theo và hỏng cài đặt.

Dùng câu hỏi phản biện để khai thác thêm chi tiết. Biến câu hỏi dở thành hay; đừng quên chúng tôi cũng từng gà mờ.

Thay vì chỉ gào “RTFM”, hãy chỉ chỗ tài liệu hoặc gợi ý từ khóa Google.

Nếu trả lời, hãy cho câu trả lời tốt. Đừng khuyên dùng cái dở khi họ dùng sai công cụ; hãy gợi ý công cụ tốt hơn, tái cấu trúc bài toan.

Trả lời đúng câu hỏi! Nếu người ta đã thử X, Y, Z, A, B, C và ghi rõ không được, thì bảo “Thử A hoặc B” hoặc gửi link “Thử X–C” là vô ích!

Giúp cộng đồng học: khi trả lời câu hay, tự hỏi “Làm sao sửa tài liệu/FAQ để khỏi lặp lại?”, rồi gửi bản vá.

Nếu bạn mất công nghiên cứu mới trả lời, hãy thể hiện kỹ năng, đừng chỉ đưa cá. “Dạy câu cá hơn cho cá.”### Tài nguyên liên quan

Nếu cần kiến thức cơ bản về máy tính cá nhân, Unix và cách Internet hoạt động, hãy tham khảo Nguyên lý cơ bản về cách hoạt động của Unix và Internet.

Khi phát hành phần mềm hoặc bản vá, hãy cố gắng tuân theo Thực tiễn phát hành phần mềm.

Lời cảm ơn

Evelyn Mitchell đã đóng góp một số ví dụ câu hỏi ngớ ngẩn và truyền cảm hứng để viết mục “Cách trả lời câu hỏi tốt hơn”, Mikhail Ramendik đã đóng góp một số gợi ý và cải tiến đặc biệt có giá trị.

基于STM32的同步整流Buck-Boost数字电源 开源
LCD1602 I2C模块无法显示字符