我即將迎來我在 Stack Overflow 上的十週年紀念日。多年來，我使用該網站的方式和對其的看法發生了很大變化，我想與您分享我的經驗。我是從一般使用者的角度來寫這篇文章的，他們不太參與網站社群的生活或其文化。這些天我只回答與我正在開發的產品 VS Code 相關的問題。然而，我過去常常積極參與各種話題的討論。 10年後我 ，瀏覽了無數其他人的評論。
喬恩·斯基特 比我能做的更好、更有權威。它的出版影響了本文的一些章節，但總的來說，這些是我自己對 Stack Overflow 的經歷、網站的優點和缺點以及今天如何使用它的坦率反思。這個討論將相當膚淺，不會深入探討網站的運作或其歷史。
以下是我使用 Stack Overflow 10 年來的經驗教訓。
你需要能夠提問
乍一看，沒有比這更簡單的了：在文字欄位中輸入幾個單詞，點擊“提交”，互聯網將神奇地幫助您解決所有問題！但我花了近 10 年的時間才弄清楚在那個該死的欄位中輸入什麼字才能真正得到結果。事實上，我每天仍然在學習它。
提出好的問題確實是一項被低估的技能（就此而言，撰寫好的問題報告也是如此）。首先，我們如何確定一個問題是否「好」？ Stack Overflow 優惠 ，其中列出了好問題的以下品質：
- 是否符合網站的主題？
- 意味著客觀的答案。
- 還沒被問到。
- 已被研究。
- 通常使用最小的、易於重現的範例來清楚地描述問題。
好的，但是「明確的問題陳述」在實務上是什麼樣子的呢？哪些資訊相關，哪些資訊不相關？有時感覺為了問一個好問題，你首先需要知道答案。
不幸的是，小文字欄位在這裡沒有幫助。那麼，這麼多用戶發布低品質的問題有什麼奇怪的嗎？有時，他們得到的唯一答案是一些令人困惑的文檔的連結。他們仍然會很幸運。許多低品質的問題只是默默地被否決，然後消失在無盡的問題線索中。
提出好問題是一種技巧。幸運的是，它是可以開發的。我主要是透過閱讀一堆問題和答案來學習的，注意哪些有效，哪些無效。哪些資訊有用，哪些資訊令人討厭？儘管你仍然會害怕在實踐中使用你所獲得的知識並提出問題。只要盡力而為，並從結果中學習。我必須承認，我自己對我早期的一些無知問題感到有點尷尬，儘管這也許證明自從我發現自己在這個網站上以來，我的提問技巧已經提高了很多。
壞問題和不太好的問題不是一回事
我不會粉飾這個藥丸：有些問題就是不好。
由螢幕截圖和短語“為什麼這不起作用！？！”組成的問題- 壞的。為什麼？看得出來作者幾乎沒有付出什麼努力。這與其說是一個問題，不如說是一個要求：“為我做這件事！”我為什麼要這樣做？我的時間太寶貴了，不能浪費在幫助那些一開始就不想學習並且不感激我的幫助的人。了解什麼是 Stack Overflow。
現在考慮一個題為“如何刪除頁面上的藍色邊框”的問題，該問題由幾段討論 CSS 輪廓屬性的文本組成，但沒有明確提及“CSS”或“輪廓”一詞。雖然這樣的問題可能違反許多 Stack Overflow 指南，但我不同意，這不是一個壞問題。作者至少試圖提供一些信息，即使不知道該提供什麼。嘗試很重要，感知和學習的意願也很重要。
然而，許多 Stack Overflow 貢獻者可能會以相同的方式處理這兩個問題：否決並關閉。這是令人沮喪的，並且在許多沒有經驗的用戶能夠學會提出更好的問題甚至理解網站如何運作之前就對他們失去了興趣。
真正糟糕的問題不值得你花時間。但必須記住，那些提出不太好的問題的人是無意的。他們想提出好問題，但不知道如何提出。如果你一味地懲罰新人，不加解釋，他們將如何學習？
好問題並不能保證得到答案
Stack Overflow 通常可以更快回答許多人可以回答的簡單問題。您對 JavaScript 或 HTML 中的二分搜尋有疑問嗎？精彩的！不到一個小時就收到五個答案。但問題越複雜或具體，無論措辭品質如何，您得到答案的可能性就越小。
隨著時間的推移，獲得答案的可能性也會迅速下降。當一個問題深入提要幾頁時，它就會丟失。一週後，你只能祈禱有正確知識的人會偶然發現你的問題（或慷慨地點擊它）。
您可能不喜歡正確答案
每個月我都會收到幾張所謂不受歡迎答案的反對票。這些答案本質上是說，“原因是因為它是這樣設計的”，或者“這是不可能的，因為......”，或者“這是一個需要首先修復的錯誤。”在上述所有情況下，作者都沒有收到解決方案，甚至沒有找到解決方法。我懷疑當人們不喜歡答案時，他們就會投反對票。我什至理解它們，但這並不意味著答案是錯誤的。
當然，反之亦然：好的答案不一定會告訴你想聽到什麼。一些最佳答案首先回答原始問題，然後描述解決問題的其他方法。有時我會回答使用者的問題，然後寫一篇長文說明為什麼不建議這樣做。
每當態度的表達被簡化為贊成票和反對票或按讚按鈕時，重要的區別就會消失。這個問題在網路上常出現。有多少社交網路可以讓你區分「我支持這個」和「我認為這說得很好，即使我不喜歡它或同意它」？
總的來說，儘管每月都有反對票，但我相信 Stack Overflow 社群的投票是公平的。我們將堅持這條道路。
我幾乎從不在 Stack Overflow 上提問
我使用這個網站的時間越長，我在上面問問題的次數就越少。這部分歸功於我的職涯成長。我在工作上遇到的許多問題都太複雜，無法用簡單的問題來表達，或太具體，任何人都無法幫助我。我已經意識到該網站的局限性，因此我避免提出幾乎肯定不會得到很好答案的問題。
但我很少在這裡問問題，即使在學習新的語言或框架時也是如此。不是因為他是天才，恰恰相反。只是，在 Stack Overflow 上待了多年之後，當我有問題時，我深信我不太可能是第一個提出這個問題的人。我開始搜索，幾乎總是發現幾年前就有人問過同樣的問題。
觀察其他人的問題是了解有關產品的新知識的好方法。
現在我正在努力 ，所以我養成了看帶有 vscode 標籤的問題的習慣。這是了解我的程式碼在現實世界中如何使用的好方法。用戶遇到什麼問題？如何改進文件或 API？為什麼我認為絕對清楚的事情會引起這麼多的誤解？
問題是顯示您的產品如何使用的重要訊號。但重點不是回答並繼續前進，而是先試著理解對方提出問題的原因。或許產品存在你不知道的問題，或是你無意識地做出的一些假設？這些問題也幫助我發現了許多錯誤並激勵我繼續工作。
如果您正在為開發人員維護產品，請不要將 Stack Overflow 視為垃圾場（或更糟的是，將其視為問題墓地）。定期回來查看出現了哪些問題和答案。這並不意味著您需要自己回答每個問題，但來自 Stack Overflow 的訊號太重要了，不容忽視。
問題、錯誤報告和功能請求之間的界線是模糊的。
Stack Overflow 上有不少關於 VS Code 的問題其實是錯誤回報。還有許多其他實際上是對新功能的請求。
例如，標題為「為什麼當我執行...時 VS Code 會崩潰？」的問題- 這是一個錯誤報告。 VS Code 不應在各種情況下崩潰。回答錯誤回報問題會適得其反，因為作者可能對解決方法感到滿意，而從不提交真正的錯誤報告。在這種情況下，我通常會要求用戶在 Github 上提交錯誤報告。
在其他情況下，差異可能不太明顯。例如，問題“為什麼 JavaScript IntelliSense 在 VS Code 中不起作用？”根據 JavaScript IntelliSense 的工作方式，問題可能分為以下三類之一：
- 如果是使用者配置問題，那麼這確實是 Stack Overflow 的問題。
- 如果在所描述的情況下 IntelliSense 應該起作用，但實際上不起作用，那麼這是一個錯誤報告。
- 如果在所描述的情況下 IntelliSense 不起作用，則這是對新功能的請求。
歸根結底，大多數用戶並不關心這些細微差別，他們只是希望 JavaScript IntelliSense 能夠正常運作。
雖然這些差異對我來說很重要，但身為專案負責人，一般來說它們對我來說應該不重要。因為問題、錯誤報告和功能請求都是表達想法的方式：使用者期望從我的程式碼中得到一些東西，但沒有得到它。如果產品是完美的，用戶永遠不會問有關它的問題，因為一切對他們來說都是清楚的，而且它會完全按照他們想要的方式做（或至少清楚地告訴他們為什麼它不能）。
開發者也是人
人們都是情緒化的。人們是非理性的。人們都是混蛋。當然，並非總是如此，但有時！不管你相信與否，開發人員也是人。
我們開發人員喜歡告訴自己一個幻想：「我們與電腦一起工作，所以我們必須保持理性。我們理解神秘的符號，所以我們必須聰明。軟體已經佔領了世界，所以我們必須保持冷靜！涼爽的！向前！
這是錯誤的。如果是這樣，那麼上帝會幫助其他人。即使在 Stack Overflow 這個為專業人士設計的客觀知識庫工具上，即使在我自己的 VS Code 的高度具體的角落，我仍然遇到各種憤怒：邏輯謬誤、侮辱、從眾心理等。
不要欺騙自己：你可能不像你想像的那麼完美。但這並不意味著我們不應該努力改掉我們的缺點。
兄弟，我是創造這個的人
我也是一個人，Stack Overflow 上發生的事情有時會讓我感到惱火。例如，當用戶自信地寫出廢話或簡單地對與 VS Code（我創建的並且我非常了解的產品）相關的問題給出錯誤答案時。奇怪的是，似乎答案越是錯誤，就越有可能有人稱之為不爭的事實。
當這種情況發生時，我就按照圖中的動作寫下正確答案。
有幾次這導致了很長的話題：我有禍了，因為我敢於質疑他們對我創造的東西的了解！別再總想自己是對的了，你們這些該死的聰明人！因為我是對的！ ！
在這種絕望中很容易變得憤世嫉俗
當面對源源不絕的低品質問題時，很容易變得憤世嫉俗。他從來沒有聽過谷歌嗎？他甚至知道如何建構連貫的句子嗎？你是什麼，狗？
有時我一天會看幾十個新問題。不斷觀察所有這些低品質的問題可能會導致蔑視或憤世嫉俗。這種憤世嫉俗的情緒可能會蔓延到網站上，任何遇到過熱版主或花了幾個小時研究和提出問題的人都會證明這一點，結果只會收到負面回應，然後在沒有任何解釋的情況下消失得無影無蹤。
當然，也有一些用戶不付出一點努力，就提出了不好的問題。但我相信大部分低品質的問題來自善意的人（儘管是愚蠢的）。我總是試著記住成為新手意味著什麼。當你剛開始時，你不明白這裡的一切到底是如何運作的。在某些情況下，您甚至不知道該用什麼字眼來正確表達您的問題。相信我，處於這個位置很難。當你只是為了問一個問題而被潑上污水時，這是令人不愉快的。
儘管 Stack Overflow 為幫助新手做了很多工作，但仍有許多工作要做。我試圖在遵守網站標準和對沒有經驗的用戶寬容之間找到平衡。這可能涉及解釋為什麼我投票結束問題或發表評論鼓勵用戶提供更多資訊。我還有成長的空間。
另一方面，我會毫不猶豫地對那些發布諸如“JavaScript 開發的最佳VS Code 佈局是什麼？”之類問題的用戶，或者上傳代碼而不是文本的肥皂劇屏幕截圖的擁有50 名聲譽的用戶投反對票。
有時我只是想感謝你
Stack Overflow 上的感恩文化很弱。我記得有一次，該網站會自動從問題中刪除“你好”和“謝謝”這兩個詞。也許這仍然是完成的，我還沒有檢查過。
如今，任何從事過客戶支援工作的人都清楚，過多的禮貌可能會造成阻礙，甚至顯得強迫。但有時這個網站上的某人做了一些對你來說非常重要的事情，感謝他們的唯一方法就是給他們加分。太糟糕了。
效率並不要求我們成為沒有靈魂的機器人。當然，如果使用者自己願意的話，側通道可以提供人與人之間更真實的溝通。
有時我想知道收到答案後發生了什麼
Stack Overflow 遵循交易原則：有些人提出問題，有些人回答。收到回覆後會發生什麼事？誰知道？有時我想知道這一點。我的回答有幫助嗎？他幫助了什麼不起眼的項目？提問者學到了什麼？
當然，這種好奇心是不可能滿足的。要求用戶說明他們將如何使用他們收到的資訊將是非常有問題的，即使你可以做到這一點。但想想就很有趣。
遊戲化是有效的...
……當把流程變成遊戲時。
當我在狀態列中看到 +10 或 +25 小圖示時，我仍然有點擔心。也許這些遊戲化的小細節是我十年來再次訪問該網站的原因。但這些年來，我也開始思考 Stack Overflow 是一款什麼樣的遊戲，以及獲勝意味著什麼。
我確信該系統的創建是出於最好的意圖：獎勵人們提出有用的問題和答案。但只要你加了高分，它就生效了 ，而有些用戶開始調整自己的行為不是為了實現最大價值，而是為了獲得最大收視率。這很重要，因為...
聲譽並不意味著你所認為的那樣。
聲譽並不等於技術能力、溝通技巧或對 Stack Overflow 如何運作或應該運作的理解。
我並不是說聲譽沒有用。它只是不代表 Stack Overflow 管理員的意思，也不代表「聲譽」這個字的意思。我意識到聲譽是影響力的衡量標準。考慮網站上發布的兩個假設答案：
- 一個關於常見的 git 操作的內容。我用谷歌在兩分鐘內寫了一個三行答案。
- 另一個是關於糾纏圖論的。或許全世界只有一百個人能夠回答。我寫了幾段程式碼和範例程式碼來解釋問題以及如何解決它。
五年內，第一個答案的瀏覽量達到了 5 萬次，並獲得了 2000 個讚。第二個答案被看了 300 次，只得到了兩次微不足道的讚。
從某種程度上來說，這是非常不誠實的。為什麼要獎勵在正確的時間出現在正確的地點的東西？ （並不是一切都由運氣決定；了解遊戲規則也起著巨大的作用）。另一方面，第一個問題實際上比第二個問題幫助了更多的人。或許值得認識的是，從某種意義上來說，認可導致了「聲譽」的累積？
所以我認為 Stack Overflow 上的「聲譽」是一種影響力的衡量標準。真正的聲譽不能用積分來衡量，它來自社群。我聽誰的建議，誰幫助別人，我信任誰？也許這些都是不同的人，這取決於我是用 PHP 還是 iOS 寫。
話雖如此，我不知道Stack Overflow在這方面該做什麼。如果用戶獲得的不是“聲譽”而是“狡猾點”，他們還會有動力嗎？如果根本沒有積分系統，使用者還會保持參與嗎？我認為這不太可能。 Stack Overflow 上的「聲譽」等同於真實聲譽的神話不僅有利於網站本身，也有利於其最活躍的用戶。好吧，說實話，誰不喜歡提升自己的聲譽呢？
不，正如生活中經常發生的那樣，為了真正了解正在發生的事情，您不僅需要分析數字。如果一篇貼文在 Stack Overflow 上有 10 分，那麼看看這個人如何溝通，他發布了哪些問題和答案。除特殊情況外，請記住，僅 Stack Overflow 分數不太可能表明一個人使用該網站的能力以外的任何資訊。根據我的經驗，他們通常甚至不談論這個。
如果沒有 Stack Overflow，我就不會有效率
每次我需要在 git 中做一些複雜的事情時，我都會去 Stack Overflow。每當我在 bash 中需要一些簡單的東西時，我都會去 Stack Overflow。每次遇到奇怪的編譯錯誤時，我都會去 Stack Overflow。
如果沒有 IntelliSense、搜尋引擎和 Stack Overflow，我的工作效率就不會很高。從一些書來看，這使我成為一個非常糟糕的程式設計師。我可能會失敗很多測試並且無法解決板上的許多問題。就這樣吧。說真的，每次我在 JavaScript 中使用 .sort 時，我都必須查找有關何時獲得 -1、0 或 1 的信息，而且我每天都編寫 JS，開發該語言最受歡迎的編輯器。
不，Stack Overflow 是一個令人難以置信的工具。只有傻瓜才不會使用所有可用的工具。那為什麼不像我一樣成為一個內心的傻瓜呢？把你的大腦資源留給重要的知識，例如記住《宋飛正傳》系列的所有情節，或想出複雜的雙關語（本文中缺少這些，但會有許多其他性質完全不同的）。
堆疊溢位是一個奇蹟
Stack Overflow 讓任何人，無論經驗或知識如何，都可以發佈程式設計問題。這些問題的回答者都是完全陌生的人，他們中的大多數人都將一生和職業生涯的時間都花在無償幫助他人上。
奇蹟是 Stack Overflow 存在的事實和工作的結果。我確信並不是一切都如其創造者所願，但他們嘗試了。儘管有這些缺點，該網站多年來仍然幫助了許多人，包括我。
堆疊溢位不會永遠持續下去。有一天，會有更好的事出現。希望這能從 Stack Overflow 的錯誤中學到教訓，並從中獲得最好的結果。在那之前，我希望我們不要認為這個網站是理所當然的。這既是一個地標，也是一個充滿活力的社區，不斷補充新的人口。如果這讓您擔心，請記住，這一切都非常脆弱，即使是很小的行動 - 例如幫助善意但尚無知的新來者 - 也可以產生積極的效果。如果我批評這個網站，那隻是因為我關心並且我知道如何讓它變得更好。
聚苯乙烯
當我來到 Stack Overflow 時，我還是個小學生。我剛開始在 Eclipse 中編寫（ES5！）JavaScript，似乎 90% 的問題都以「使用 jQuery，只是...」開始。儘管我不知道自己在做什麼，陌生人還是花時間幫助我。我想我當時並沒有真正感激過它，但我並沒有忘記。
人們總是希望 Stack Overflow 有所不同：問答網站；解決家庭問題的工具；編程的生活水準。對我來說，這個網站儘管不斷發展並存在缺陷，但其核心是一個開放的社區，陌生人可以在這裡互相幫助學習和進步。那太好了。我很高興在過去 10 年裡一直是 Stack Overflow 的一員，並希望繼續這樣做。我想在接下來的十年裡學到和過去十年一樣多的新東西。
來源： www.habr.com