做自己 好自在

= 提問之前 =

在通過電郵、新聞組或者聊天室提出技術問題前，檢查你有沒有做到：
1. 通讀手冊，試著自己找答案。
2. 在FAQ裏找答案（一份維護得好的FAQ可以包羅萬象:）。
3. 在網上搜索（個人推薦google~~~）。
4. 向你身邊精於此道的朋友打聽。

當你提出問題的時候，首先要說明在此之前你幹了些什麼；這將有助於樹立你的形象：你不是一個妄圖不勞而獲的乞討者，不願浪費別人的時間。如果提問者能從答案中學到東西，我們更樂於回答他的問題。

周全的思考，準備好你的問題，草率的發問只能得到草率的回答。越表現出在尋求幫助前為解決問題付出的努力，你越能得到實質性的幫助。

決不要自以為夠資格得到答案，你沒這種資格。畢竟你沒有為這種服務支付任何報酬。你要自己去「掙」回一個答案，靠提出一個有內涵的，有趣的，有思維激勵作用的問題，而不僅僅是被動的從他人處索要知識–去掙到這個答案。

另一方面，表明你願意在找答案的過程中做點什麼，是一個非常好的開端。「誰能給點提示？」、「我這個例子裏缺了什麼？」以及「我應該檢查什麼地方？」比「請把確切的過程貼出來」更容易得到答覆。因為你顯得只要有人指點正確的方向，你就有完成它的能力和決心。

= 怎樣提問 =

- 謹慎選擇論壇
小心選擇提問的場合。如果象下面描述的那樣，你很可能被忽略掉或者被看作失敗者：
1. 在風馬牛不相及的論壇貼出你的問題
2. 在探討高級技巧的論壇張貼非常初級的問題；反之亦然
3. 在太多的不同新聞組交叉張貼

- 用辭貼切，語法正確，拼寫無誤

- 使用含義豐富，描述準確的標題

- 精確描述，信息量大
1. 謹慎明確的描述症狀。
2. 提供問題發生的環境（機器配置、作業系統、應用程式以及別的什麼）。
3. 說明你在提問前是怎樣去研究和理解這個問題的。
4. 說明你在提問前採取了什麼步驟去解決它。
5. 羅列最近做過什麼可能有影響的硬體、軟體變更。


- 話不在多
你需要提供精確有效的資訊。儘量把它剪裁得越小越好。 這樣做的用處至少有三點。
第一，表現出你為簡化問題付出了努力，這可以使你得到回答的機會增加；
第二，簡化問題使你得到有用答案的機會增加；
第三，在提煉 你的bug報告的過
- 只說症狀，不說猜想
- 按時間順序列出症狀

- 明白你想問什麼
漫無邊際的提問近乎無休無止的時間黑洞。最能給你有用答案的人也正是最忙的人。這樣的人對無節制的時間黑洞不太感冒，因此也可以說他們對漫無邊際的提問不大感冒。

因此，優化問題的結構，儘量減少專家們解決它所需要的時間，會有很大的幫助–這通常和簡化問題有所區別。因此，問「我想更好的理解X，能給點提示嗎？」通常比問「你能解釋一下X嗎？更好。如果你的代碼不能工作，問問它有什麼地方不對，比要求別人替你修改要明智得多。

- 別問應該自己解決的問題

- 去除無意義的疑問
別用無意義的話結束提問，例如「有人能幫我嗎？」或者「有答案嗎？」。

- 謙遜絕沒有害處，而且常幫大忙

- 問題解決後，加個簡短說明
問題解決後，向所有幫助過你的人發個說明，讓他們知道問題是怎樣解決的，並再一次向他們表示感謝。

=三思而後問 =

提問：我能在哪找到X程式？
回答：就在我找到它的地方啊–搜索引擎的那一頭。

= 好問題，壞問題 =

聰明問題：FOO專案代碼在Nulix 6.2版下無法編譯通過。我讀過了FAQ，但裏面沒有提到跟Nulix有關的問題。這是我編譯過程的記錄，我有什麼做得不對的地方嗎？
// 他講明瞭環境，也讀過了FAQ，還指明了錯誤，並且他沒有把問題的責任推到別人頭上，這個傢伙值得留意。

聰明問題：我在S2464主板上試過了X、Y和Z，但沒什麼作用，我又試了A、B和C。請注意當我嘗試C時的奇怪現象。顯然邊帶傳輸中出現了收縮，但結果出人意料。在多處理器主板上引起邊帶洩漏的通常原因是什麼？誰有好主意接下來我該做些什麼測試才能找出問題？
// 這個傢伙，從另一個角度來看，值得去回答他。他表現出了解決問題的能力，而不是坐等天上掉答案。

在最後一個問題中，注意「告訴我答案」和「給我啟示，指出我還應該做什麼診斷工作」之間微妙而又重要的區別。
以上引自 http://mmdays.wordpress.com/2007/09/25/question/