我即將迎來我在 Stack Overflow 的十週年紀念日。多年來，我使用和感知該網站的方式發生了很大的變化，我想與大家分享我的經驗。我是從不太參與網站社區生活或文化的普通用戶的角度來寫這篇文章的。最近幾天，我一直在回答與我所從事的產品 VS Code 相關的問題。然而，過去我一直積極參與各種主題的討論。十年來我 ，看了無數別人的評論。
喬恩·斯基特 比我曾經做過的更好、更有權威。他的貼文影響了本文的一些章節，但總的來說，這些都是我自己對 Stack Overflow 的使用體驗、該網站的優缺點以及它在今天的用途的坦誠反思。這次討論將相當膚淺，不會深入探討該站點的運作或歷史。
以下是我使用 Stack Overflow 10 年所學到的。
你需要知道如何提問
乍一看，沒有什麼比這更簡單的了：在文字框中輸入幾個單詞，單擊“發送”，互聯網就會神奇地幫助您解決所有問題！但我花了將近 10 年的時間才弄清楚應該在那個該死的領域輸入什麼字才能真正得到結果。事實上，我每天都在學習這一點。
提出好的問題是一項真正被低估的技能（就像製定一個好的問題陳述一樣）。首先，我們要如何判斷一個問題是「好」的？ Stack Overflow 提供 其中列出了好問題應具備的以下特質：
- 它是否與網站的主題相符？
- 暗示客觀的答案。
- 尚未被詢問。
- 受到調查。
- 清楚描述問題，通常使用最小且易於重現的例子。
好的，但是在實務上「清晰的問題陳述」是什麼樣的呢？哪些資訊是相關的，哪些資訊不相關？有時感覺為了提出一個好問題你首先需要知道答案。
不幸的是，小文字框在這裡沒有幫助。那麼，這麼多用戶發布低品質的問題也就不足為奇了？有時他們得到的唯一答案是一些令人困惑的文檔的連結。他們會很幸運。許多低品質的問題只是被默默地否決，然後消失在無盡的問題回饋中。
提出好問題是一項技能。幸好，它是可以開發出來的。我的學習主要透過閱讀大量問題和答案，記錄哪些有效，哪些無效。哪些資訊是有用的，哪些資訊是有害的？儘管你還是會害怕在實踐中運用所學到的知識並提出問題。只需嘗試並從結果中學習。我必須承認，我對自己早期的一些無知問題感到有點尷尬，但也許這證明自從我來到這個網站後，我的提問技巧已經大大提高。
壞問題和不太好的問題不是一回事
我不會粉飾太平：有些問題就是很糟糕。
由一張截圖和一句話組成的問題“這為什麼不起作用！？！” - 壞的。為什麼？顯然作者幾乎沒有付出任何努力。這與其說是一個問題，不如說是一個要求：「為我做這項工作！」我為什麼要這麼做？我的時間太寶貴了，不值得浪費在幫助那些從一開始就不想學習、也不會感激我的幫助的人身上。了解 Stack Overflow 的全部內容。
現在考慮一個標題為「如何刪除頁面上的藍色邊框」的問題，該問題由幾段討論 CSS outline 屬性的文字組成，但沒有明確提到「CSS」或「outline」字樣。雖然這個問題可能違反了 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 為幫助新手做了很多工作，但還有很多工作要做。我試圖在遵守網站標準和對缺乏經驗的用戶寬容之間找到平衡。這可能涉及解釋我為什麼投票關閉該問題或發表評論鼓勵用戶提供更多資訊。我還有成長的空間。
另一方面，我會毫不猶豫地對那些擁有 50 聲譽的用戶投反對票，這些用戶會提出諸如「什麼是最適合 JavaScript 開發的 VS Code 主題？」之類的問題。或上傳模糊的程式碼截圖而不是文字。
有時我只想感謝你
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 不會永遠存在。總有一天會出現更好的事。希望這能從 Stack Overflow 的錯誤中學習並取得最佳效果。到那時，我希望我們不會將這個網站視為理所當然。它既是一個參考點，也是一個不斷補充新人的生活社區。如果您對此感到擔心，請記住，所有這一切都非常脆弱，即使是小小的舉動 - 例如幫助善意但仍然無知的新來者 - 也會產生積極的影響。如果我批評這個網站，那隻是因為我關心並且知道如何讓它變得更好。
聚苯乙烯
當我來到 Stack Overflow 時，我還只是個小學生。我剛開始在 Eclipse 中編寫 (ES5!) JavaScript，似乎 90% 的問題都是以「我正在使用 jQuery，只是…」開頭的。儘管我不明白自己在做什麼，陌生人還是花時間幫助我。我想我當時並沒有真正感激它，但我沒有忘記。
人們總是希望 Stack Overflow 有所不同：一個問答網站；解決家庭問題的工具；程式設計的活生生的標準。對我來說，這個網站儘管還有發展和缺陷，但其核心是一個開放的社區，陌生人可以互相幫助學習和進步。這真是太棒了。我很高興在過去的 10 年裡成為 Stack Overflow 的一部分，並希望它能繼續如此。我希望在未來十年能學到和過去十年一樣多的東西。
來源： www.habr.com
