我一直在思索我們工程師對項目的多樣化影響，以及像 "10x 工程師" 這類評價背後的真實意義。過去幾年裡，很多文章都討論過這個概念，有些人稱其為神話，而有些人則認為你的團隊裡至少需要有一位。這是一個備受關注的話題；很容易理解，這個術語經常引起爭論。然而，我認為理解一個開發者給團隊帶來的真正價值，超越任何數字評價以及他們的 leetCode 分數是非常重要的。
我是那派認為 10x 工程師是偉大的人之一，而且，我的觀點並非出於天方夜譚。但是我有一個更為細微的看法，我認為 10x 工程師與他的編碼能力無關，更重要的是，我認為任何人都有可能成為 10x 工程師。這不是個人品質，而是你作為軟體開發者所做出的所有微小決策的累積效果 —— 你選擇的工具，你嘗試 debug 的方式，你與團隊隊友交往的方式。
在我早期的職業生涯，我親眼目睹了一個普通的開發者如何一夜之間成為一個 10x 工程師：我們有一個每秒鐘應對成千上萬請求的高負載項目，這個項目由一小團隊開發 —— 這是一個需要快速工作，並且需要掃描大量的數據以匹配多維度查詢的搜尋模組。乍一看，一切都很順利，代碼已經在生產環境運行了一段時間，但有些用戶抱怨說他們隨機地收不到響應。
隨著時間的推移，錯誤率持續上升，但我們卻無人可以求助。最初的開發團隊已經轉向另一個項目，實在沒有時間幫助我們。產品已經上線了，由於尚未解決的並發問題導致不可預測的行為，用戶們對此有理由感到苦惱。
然後，我們的主要開發者站了出來。他花了幾天時間試圖定位問題，調試每一行代碼。他是我所認識的最優秀的工程師嗎？他並不是，但在那個關鍵時刻，他對項目的貢獻是團隊中任何其他人的 10 倍。他一己之力解決了我們搏戰了半年以上的問題。
回過頭來看，"10x 開發者" 這個詞實在不足以公正對待那些必要的貢獻。這並不是關於你比其他工程師快 10 倍，而是關於做出關鍵的決策，為整個團隊帶來顯著的正面效果。如果你的速度快了，但其他所有東西都出問題了，你是真的 10 倍工程師還是 0.1 倍工程師呢？
10 倍效率工程師：被認知偏見所扭曲的觀點#
10 倍效率工程師（10x engineer）這個術語頗具吸引力。它戲劇性地抓住了人們的注意。有人在一天之內就快速構思出解決方案，於是立刻 —— 他們就被冠以 10 倍效率工程師的美譽。但問題在於，這個術語的使用充滿了我們的認知偏見。我們總是目不轉睛地關注那些如星辰般耀眼的人物，卻往往忽略了那些腳踏實地、可靠的工程師，正是他們默默地維持著系統的正常運轉。
為什麼會這樣呢？嗯，我們的大腦偏愛英雄故事。我們天生很容易對那些因突出而引人注意的異常者表示欽佩。這可以追溯到我們早期生存的本能。當某人在某事上表現得非常突出，我們就會注意到他們，哪怕這樣的情況只在滿月之夜偶爾出現一次。在野外，這種啟發式的思考很有用，但在日常判斷中，它可能會讓我們產生偏見。
比如，上圖就是一個關於 10 倍效率工程師的糟糕範例，它也完全錯誤。
一種非常普遍的認知偏差是暈輪效應（halo effect）。當我們對一個人的整體印象被某個突出特質或成就所影響時，就出現了暈輪效應。例如，如果團隊裡的某個成員曾經在短時間內解決了一個複雜的 bug，我們可能會因此忽視他在項目截止時間上連續的掙扎，依舊把他們看做高效能人士，這是基於他們那一次令人難忘的壯舉。這可能會導致我們高估他們的能力，從而不合理地提高對他們的期望值。
對比效應（contrast effect）可能會導致我們因為一個人的技能不如其他更耀眼的同事那樣立即顯眼而低估了他們。這可能讓我們忽略那些對我們的成功同樣至關重要卻相對隱蔽的穩定貢獻。當我們直接比較兩位工程師的能力而不是基於他們自身的優點作出判斷時，也會出現這種情況。設想一下，如果我們的一位開發者剛完成了一個出色的功能演示，而緊接著另一位的演示就沒那麼搶眼。第二位工程師在大家心目中可能就會不公平地顯得不那麼出色 —— 並非因為他們的工作不好，而是因為他們被他人的光芒所遮蓋。僅僅因為被遮蓋，他們就是 0.1 倍效率工程師了嗎？我不認同這一說法。
接下來的偏差是確認偏差。當我們看到某人曾經做得很棒，之後我們開始留意那些支持我們看法的細節，並忽視那些不符合的情況。比方說，如果我們給某人貼上了 0.1 倍效率的標籤，我們可能就會在無意識中忽視他們的成功，並過度關注任何小失誤，從而加固了我們的初步評判。
“生產環境出了一個 bug。肯定又是 David 推出的有問題的改動。”
這裡的問題是，當我們對那些搶眼的行為給予讚賞時，我們可能就看不到那些默默在後台重構代碼以提高整潔度的團隊成員，或者是花時間輔導新同事的人。這些行為可能不會大聲疾呼 “10 倍效率工程師在此”，但是它們對於團隊的長遠成功至關重要。
典型場景及行為表現#
正如我之前所述，關於 10 倍效能工程師與 - 10 倍效能工程師的辯論，主要取決於無數我們日常做出的決策，以及我們如何面對不同情境的反應；它並不僅僅與你編寫代碼的速度快慢或實現的算法有多麼 “聰明” 相關。讓我們通過一些具體場景來展示成為一名 10 倍效能工程師其實並不難。
處理生產中的 Bug#
設想一下，一個客戶或者利益相關方發現應用中有一些與你負責開發功能相關的不一致之處。當有人告訴你你的代碼出了問題時，以下可以作為你反應的基本準則。
✅ 10 倍效能工程師：“我們會立即查看並盡快回覆您。” 你迅速定位問題、修復 Bug、通知團隊，並在事後分析中分享解決方案以避免未來的問題。
❌ 0.1 倍效能工程師：“在我的電腦上運行得很好。” 一開始無視報告，將問題歸咎於環境或用戶操作錯誤，並且最終施加的臨時性熱補丁並未徹底解決問題。
響應代碼審查#
一位經驗更豐富的開發者正在審查你的代碼，他建議使用另一種實現方案，並表示在 Pull Request 被批准前，你應該先按照公司通用標準進行重構。
✅ 10 倍效能工程師：“感謝你的反饋。我非常欣賞這些建議！” 你真心感激這些反饋，努力整合這些建議，並感謝你的同事提供的洞察。專注於產品更好的發展，而不是推動個人議程或自我。
❌ 0.1 倍效能工程師：“你錯了，我的代碼已經很完美了。” 對反饋表現出防禦性，無理辯駁，這不僅拖慢了審查過程還只關注於個人 —— 認為他們所寫的代碼比產品整體的改進更重要。
處理上層管理和行政事務#
眾所周知，軟體工程不僅僅是關於編寫代碼；發布任何功能都伴隨著大量的額外工作。想像在日常會議中，管理者開始要求通過項目管理工具增加透明度。他們表示自己缺乏情境理解，難以保持整個項目的順利進行。
✅ 10 倍效能工程師：“是的，Jira 有時確實令人煩惱，但我明白你的意思，它確實能讓每個人保持同步，助於各司其職。” 你明白開發與管理間平衡的重要性，並努力處理必要的行政任務，確保兩者都得到重視。
❌ 0.1 倍效能工程師：“Jira 太糟了，根本沒人在意它，它甚至不能算是真正的工作。” 對每一次演示、繪圖和票務工作都顯得很不耐煩。
引入新技術#
自從你的項目上次正確地進行了重構已經過去了五年。隨著業務發生了許多變化，代碼庫中添加了許多臨時解決方案來應對所有由業務增長引入的新邊界情況。是時候正確地做事了，從零開始以適應不斷變化的業務需求。
✅ 10 倍效能工程師：“我們做一個概念驗證，看看哪種技術最適合我們，然後再決定我們要投入哪種技術。” 你在評估新框架時深思熟慮，考慮團隊能力和項目需求。你考慮到了潛在的技術債務，思考做必要的重構。
❌ 0.1 倍效能工程師：“我們應該選擇 Angular，因為它是最好的，因為那是我唯一熟悉的框架，我打算在接下來的 45 分鐘裡和你爭論。” 毫不考慮地推動新技術的採用，允許技術債務累積，並將新功能的開發優先於長期項目健康。
團隊會議#
你和團隊坐下來討論落實一個需求功能的替代開發方案。可以有許多不同的實現方式，有人提議走無伺服器的路線，有人建議使用 Rust 語言，並在本地設施上構建。眾多不錯的想法在團隊成員之間頻繁交換。
✅ 10 倍效能工程師：“我們來聽聽每個人怎麼說。” 你以建設性態度參與討論，確保對話有序進行，並遵守時間限制。激勵每個成員發表見解，基於團隊的共同決策挑選最合適的行動方針。
❌ 0.1 倍效能工程師：“這裡是我的見解，請大家靜聽 45 分鐘。” 在討論中佔據主導地位，使話題偏離重點並情緒化爭論。
面對失敗的項目#
事情不總是順心如意的，有時你會失敗。你在失敗面前的反應同樣能體現出你與 0.1 倍效能工程師的不同。這些細小的互動非常至關重要。
✅ 10 倍效能工程師：“好的，我們來客觀分析一下哪裡出了問題，避免指責任何人，並確保將來不再發生類似情況。” 你以建設性的方式分析問題，並在一個不尋找替罪羊的環境中探討，理解需要哪些改進來防止將來發生類似的問題。
❌ 0.1 倍效能工程師：“這都是某某的錯，她 / 他的代碼總是出問題。” 將責任推卸給他人，避免共同承擔責任，往往掩蓋了項目失敗的真正原因，以保護自己的立場或虛榮心。
最小可行產品（MVP）的開發#
如果你是團隊中的主要工程師或剛開始承擔技術共同創始人的角色，CEO 可能會來向你徵詢建議，詢問應該開發什麼以及何時發布。重要的是要明白，工作量會填滿為它分配的時間。
✅ 10 倍效能工程師：“我們來製作一個足夠好的產品並將其推向市場。” 你專注於交付一個具有足夠特性滿足早期使用者，同時驗證產品概念的最小可行產品（MVP）。
❌ 0.1 倍效能工程師：“我們要把產品做到完美然後再也不發布。” 追求完美，希望在產品推出時就功能全面完備。
功能的優先級排序#
每一位軟體工程師都需要和管理者密切合作。通常，管理者會和團隊討論確定哪些功能的開發順序，並徵求團隊的意見，看看接下來應該開發什麼。
✅ 10 倍效能工程師：“客戶有什麼反饋呢？他們最大的问题點在哪裡？” 你與產品管理緊密合作，優先開發那些為客戶帶來最大價值的功能。
❌ 0.1 倍效能工程師：“我想部署 Kubernetes。” 堅持要開發技術含量高但影響力較小的複雜功能，這些功能雖然顯示了技術實力，但卻不符合用戶的需要或業務目標。
我希望這些場景達到了揭示的目的，那就是：你無需熬夜、加班就能交付高度複雜軟體，並以此獲得 10 倍效能工程師的認可，關鍵是要在日常工作中做出正確的決策，並提交高質量的代碼。
普通人作為推動力#
大項目的成功推進得益於團隊的集體（共同）努力，而非某一位超級明星開發者的獨力作為。當然，如果有能迅速解決問題、像打印機一樣編程的人在團隊裡，那自然是極好的。但即使是十倍能力或者百倍效能的工程師，也有其局限性。他們可能會生病，需要假期休息，或有時候狀態不佳。他們也可能會離職。一味依賴這些 “超級英雄” 的項目，當這些 “超級英雄” 需要休息時，可能就會遇到棘手的困境。
招納十倍工程師。來源：workchronicles.com
正如你從前述場景中所見，保持正確態度已足夠讓你在團隊中脫穎而出，被視作一名十倍工程師。如果每個人都這樣前進，那麼你就會有一個著眼於最佳實踐、力求盡善盡美的出色團隊。這難道不是最重要的嗎？比起慶祝某人一天之內編寫出一個極為複雜的功能更重要對吧？想想那些進行順利的重要軟體更新或者產品發布。那僅僅是由一人完成的嗎？幾乎不可能。這是整個團隊共同處理了數以千計的小任務、投訴、問題、事務，以確保一切正確無誤。
我們應當公平地看待並欣賞各種層面上的貢獻。畢竟，真正成功的項目來自於各方面的共同努力，而非僅憑個人的瞬間靈光。
2024 年 4 月 23 日更新：如果你更喜歡觀看視頻而不是閱讀，或者只是想見識一下我的風采 —— 我錄製了一段視頻，分享一個十倍工程師應該具備的特點。請觀看至視頻末尾，分享我的個人經歷。點擊這裡觀看視頻。