本文翻譯自https://redd.one/blog/how-to-ask-questions
作為一名軟體工程師，你經常需要實現現實世界的功能並修復棘手的漏洞。有時你可能覺得自己缺乏知識，或者不確定如何完全處理任務。這是完全正常的，即使是最有經驗的工程師也會偶爾遇到困難，沒有人真正知道一切，儘管他們可能看起來很聰明。尋求幫助（以及提供幫助）是編程不可或缺的一部分，就像編寫代碼或進行代碼審查一樣。然而，提問本身就是一門學問，需要一些時間學習如何以較少的投入獲得更多的成果。
提問即學習#
我知道害怕或羞於提問的感覺，擔心你的同事可能會認為你智商或者技術水平較低，對你提出他們認為顯而易見的問題皺眉，甚至欺負你，要求你現在應該已經知道答案。如果你感到所處的環境不鼓勵提問，那麼你可能處於一個很差的環境中，需要盡快離開。那些瞧不起興趣、實驗和提問的人，很少是聰明人，因為他們阻止自己和他人獲取知識。知識來自學習，而學習來自提問。確保你與那些理解這一點的人一起前行。
然而，如果你在尋求幫助時感到害羞或不自信，我有一個小窍門給你：不要把你的問題看作是你不知道某件事情的標誌，而應該把它看作是想要學到更多的標誌。在我看來，提問是學習任何領域最有效的方式。通過這種方式，你可以在提問這門偉大的藝術中取得進步，並且更有可能記住答案，因為我們最容易記住自己親身經歷過的問題的解決方案。
💡 不要剝奪自己最好的學習方式：提問。
提問的偉大藝術#
提出正確問題的技巧非常難以掌握。然而，如果不去實踐並關注那些讓你更接近答案的細節，你是不會變得更擅長提問的。這個話題值得一本厚厚的書來探討，但現在讓我們探討提問中最常見的問題之一：具體性。
問題的具體性通常是模棱兩可的，既可能讓你更接近答案，也可能讓你離答案更遠。讓我們來看看為什麼會這樣。
無關的具體性#
這裡有一個問題的例子：
如何在 React 中在頁面刷新時保持來自谷歌的身份驗證令牌？
雖然這可能是一個有效的問題，但它包含了太多在回答問題時沒有用的細節。例如，不要將身份驗證過程綁定到谷歌，而是考慮詢問關於通用身份驗證持久性的問題。因為對於谷歌、亞馬遜或其他任何提供商，在這方面的情況大致相同。不要將答案限制在 React 生態系統內，而是嘗試從問題中去掉框架，以了解 JavaScript 中的持久性。這樣，你得到的答案更有可能被其他框架和庫複用，使其更有價值。最後，當涉及持久性時，保持身份驗證令牌、唯一 ID 或任何類型信息的重要性很小。即使是問題中的 “身份驗證” 部分也可以用 “如何保持數據” 來替換，任何數據。
雖然你所處的背景可能很重要，但往往放棄它有助於找到一個最終會引導你找到正確答案的線索。
💡 提問就是調查：你找到線索，引導你提出更具體的問題，最終找到答案。
當你需要把一個紅色的球體變成一個藍色的尖銳立方體時，不要指望立刻找到解決這個任務的方法。首先學習如何將球體變成立方體，然後學習如何使任何立方體變成藍色，最後學習如何使藍色物體變得尖銳。任何編程任務都可以分解成一系列較小的任務，從長遠來看，研究這些任務將是一個更有價值的過程。在這個過程的中間，你可能會意識到你甚至不需要讓立方體變尖銳。
我強烈建議從問題中去掉背景的原因是，這樣可以讓你更有機會找到答案。這也會讓你明白一個問題很少有唯一的直接答案。開始時可以從宏觀方面入手，隨著你逐漸發現的每一個知識點，逐漸縮小到具體的細節。你會驚喜於通過這種方式學到的東西有多少。
相關的具體性#
提供包括庫名稱、瀏覽器版本或特定選項名稱在內的技術細節可以幫助縮小調查範圍，讓你更接近答案。但是，在提供這些信息時，有一件重要的事情：你必須知道哪些是相關的。
看看這個問題：
Axios 在 componentDidMount 中的 POST 請求失敗。
評估這些技術細節的實用性完全不可能，因為它們可能既相關又無關，這取決於特定的用例。提問時知道包括什麼，和省略什麼，就成了你的責任。說實話，這是提出正確問題的難點之一，也是隨著時間和實踐而獲得的技能之一。
💡 在包括技術細節時，你必須知道什麼是相關的，什麼不是。
不幸的是，提到無關的細節可能會使你的調查工作偏離軌道。幸運的是，如果你詢問的人熟悉這個話題，他們可以幫助你根據相關性篩選這些細節。
隨著時間的推移，當你不斷提問時，你會開始注意到某些技術細節對你來說變得非常重要，而其他一些則逐漸變得不那麼重要。關於這點，我沒有其他更高明的建議，只是鼓勵你繼續提問！
15 分鐘規則#
在提問時應該小心，不要養成把問題交給別人的習慣。雖然在絕境中尋求幫助是應該做的事情，但我們都不喜歡掙扎。因此，當我們期待已久的幫助終於到來時，我們自然會感到滿足和歡喜。為了讓這種幫助持續更長時間，試著在提問之前學會評估情況。這可以防止不必要的問題，並給你一種獨立完成的感覺。
💡 最後，期望答案的質量與你願意花費尋找它的時間成正比。
在我的職業生涯中，採用 “15 分鐘規則” 對我非常有幫助。每當我發現自己陷入困境時，我就會專注地花 15 分鐘時間自行解決當前問題。到時間結束時，我會檢查我所提的問題是否仍然相關。如果不再相關，我會用另外 15 分鐘處理接下來出現的問題。只有在我的努力證明無果時，我才會向同事或其他開發人員提問。
這個規則非常有用，因為它可以增加你問題的價值。在嘗試解決問題的過程中，你通常會學到一兩個知識點，即使沒有找到答案。你所獲得的知識和嘗試過的方法，可能會幫助你未來的 “顧問”，也就是幫你解決問題的人，更準確地解決你的問題。同時，你在解決問題中的努力，也為得到他人理解和同情的回應奠定了基礎。
耐心#
軟體工程可能會讓人感到壓力：由於某個問題導致客戶失去收入，經理對錯過的截止日期憤怒 —— 我們都經歷過。壓力並不能真正解決這些情況，也不能找到問題的答案。
請記住，解釋問題和提出正確的問題同樣困難。花時間幫助你的人可能會努力尋找最合適的方式來向你傳達答案。在這個過程中，耐心和善良至關重要。
幫助他人#
無論你認為自己有多麼缺乏經驗，總會有一個人比你落後一步。那個人正走著與你類似的道路，但他們可能還沒有完全理解你已經掌握的某些概念或模式。下次當你看到有人對你覺得非常明了的話題感到困惑時，請幫助他們。
💡 提供幫助與尋求幫助同樣有用。
無私奉獻並不是幫助他人的唯一原因。最佳的確認自己是否真正理解了問題的方式，也許就是通過解釋這個問題來實現。因為我們每個人的思考和記憶方式各不相同，一開始向需要幫助的人傳達你的想法可能會很具挑戰性。有時候，這需要你驗證自己所學到的知識，以免給出錯誤或不完整的答案。這可能會幫助你發現自己知識中的一些盲點！
得出結論#
得到答案當然很有成就感，但請嘗試將其記在腦海裡。問題並不是一個燃燒的爐子，一個接一個地抛出答案並無益處，因為提問的目的是學習。從答案中獲取有價值的信息可能需要回顧原始問題並得出結論。問題的原因是什麼？解決方案是什麼？解決方案是直接還是間接影響了原因？在解決這個問題時，還有什麼補充知識可以幫助嗎？
學習本身就是一項技能，因為我們所有人學習、記憶和解釋事物的方式都截然不同。既然如此，為什麼不在答案已經掌握的情況下提高另一項技能呢？嘗試找到最適合你的學習方式，無論是畫圖、編寫簡短的文檔，還是在書籤中收藏有用的鏈接。下次有問題出現時，這個寶庫是開始使用 15 分鐘規則的好地方！