什麼是 10x 程序員

原文轉載自 Antirez
翻譯：江宏

在編程界的傳說中，一個 10x 程序員能夠完成普通程序員十倍的工做量。所謂普通程序員，能夠想象是一個擅長他/她的工做，但沒有 10x 程序員那樣神奇能力的人。更好地描述「普通程序員」的說法是它表明了專業程序員裏平均的編程輸出水平。

編程社區對於這種動物是否存在有兩極分化的見解：有的人認爲根本不存在，有的人卻認爲不只存在 10x 程序員，若是你知道怎麼尋找的話，甚至能找到 100x 程序員。

若是你認爲編程是一個「線性」學科，很明顯 10x 程序員存在的可能性看起來確實不符合邏輯。跑步者如何作到比另外一個跑者快 10 倍？或者說一個建築工人在相同的時間內如何作到其餘人十倍的工做量？然而，編程是一種很特殊的設計學科，即便當程序員不參與架構上的實際設計時，在實現一個產品時，仍舊須要對實現策略進行設計。

因此若是程序的設計和實現不是線性能力，那麼在我看來，工做經驗、編程能力，知識儲備，辨別無用組件的能力等都是非線性的優點，它們以乘積的方式在產品開發中發揮做用。固然，當程序員能同時負責軟件的設計和實現時，這種事半功倍的現象就更多了。一個任務越是「目標導向」，潛在的 10x 程序員就越有空間利用她/他的能力以比別人少不少的努力達到目標。當手頭的任務更僵化，對開發工具及實現方式有不少限制時，10x 程序員在更短的時間內完成更多工做的能力就被削弱了：它仍然可能利用對「局部」設計的把控來作的更好，但卻沒法根本上改變到達目標的路徑，包括把設計規範的某些部分完全去掉，以大大減小工做量卻達成幾乎一樣的目標。

在做爲程序員工做的二十年裏，我觀察過不少和我一塊兒工做的程序員，由我指導以達到既定目標，如爲 Redis 和其餘項目提供補丁。正是在這些協做過程當中，不少人認爲我是很高效的程序員。考慮到我遠非工做狂，我就以本身爲參考來談談如何快速開發。

如下是我認爲對編程效率影響最大的幾點特質。

純編程能力：完成子任務

程序員最明顯的優劣勢體如今實現程序的一個部分的子任務中，包括函數，算法或其餘任何東西的實現。使人驚訝的是，根據個人經驗，很是有效地使用基本指令式編程工具以實現某些東西的能力並不像大多數人認爲的那麼廣泛。在一個團隊中，有時我觀察到很是不稱職的、甚至簡單的排序算法也不知道的程序員能完成的工做卻比理論上應該很強在實踐中卻很弱的大學畢業生要多。

經驗：模式匹配

我所說的經驗指的是已經探索過的一系列重複性任務的解決方案。經驗豐富的程序員通過積累最終知道如何處理各類子任務。這不只能提升效率，也是防止設計上的錯誤的強大武器，這些錯誤每每是簡化設計的最大敵人。

重點：實際時間 VS 假設時間

不看質量光看編程花費的時長是毫無心義的。內部和外部因素均可能影響你的專一程度。內部因素是拖延症、對項目缺少興趣（不喜歡的事情你必定沒法全身心投入）、缺少鍛鍊、睡眠很差或不多等。外部因素是頻繁的會議、工做環境不佳、常常被同事打斷等等。很天然，提升專一度，減小中斷對於提升開發效率有不可忽視的做用。有時爲了集中注意力，須要採起一些極端措施。好比我，一般只在固定時間收發電子郵件且只回復重要部分。

學會取捨：經過幹掉 5％ 來得到 90％

當人們不肯認可一個非根本的目標形成了很大一部分設計的複雜度，或者由於一個根本功能和一個非根本功能之間存在取捨壓力而形成更重要的目標難以達到時，複雜度就產生了。對設計者而言，認識到設計中難以都實現的那些部分很是重要，也就是說，付出的努力與收益不必定是成正比的。在項目中爲了得到最大收益，就須要專一於能在有限的時間內完成的最重要的部分。例如，在設計消息代理 Disque 時，我意識到經過只盡力（而不是絕對）保證消息的順序，項目的其餘方面均可以獲得實質性的改進：好比可用性、查詢語言以及客戶端交互、簡潔性和性能等。

簡潔性

這是一個顯而易見的觀點，這一點相當重要。爲了理解簡潔性，有必要檢查複雜度都是如何產生的。我認爲複雜度的兩個主要驅動因素是不肯意進行設計上的犧牲，以及設計活動中錯誤的積累。

仔細考慮設計的過程，每一次錯誤選擇都使咱們離最優解決方案更遠。一個最初的錯誤當遇到錯誤的人時，不會致使這個系統的從新設計，而會致使設計另外一個更復雜的方案來應對這個錯誤，所以，這個項目就隨着每一個錯誤的出現而變得更加複雜和低效。

簡潔性能夠經過在腦子裏進行「概念驗證」的推理來實現，這樣可讓程序員設想大量的簡潔的設計，而後動手實現看起來最可行和最直接的方案，隨後再靠經驗和我的設計能力改進設計，併爲子級設計找到合理的方案。

然而每當須要一個複雜的解決方案時，都有必要花不少時間思考如何避免複雜度，只有在考慮過各類替代方案後都沒發現更好的選擇以後再繼續朝那個方向走。

完美主義，或者說如何犧牲生產力並引入設計偏見

完美主義有兩種類型：一種是讓程序的可量化性能達到最優的工程師文化，另外一種是人格特質。我認爲這兩種狀況下完美主義都是程序員實現快速交付的最大障礙。完美主義和對他人評價的恐懼會致使設計誤差，致使選擇不當，僅根據心理或可有可無的可量化參數來改進設計，卻從未考慮諸如程序的健壯性，簡潔性，及時交付能力之類的事情。

知識：一些理論會有幫助

在處理複雜的任務時，關於數據結構，計算的根本侷限性，適合特定任務的重要算法等的知識將會對找到合適設計的能力產生影響。並無必要在各方面都成爲一個超級專家，但知道一個問題的多種潛在解決方案是必須的。例如，接受設計上的犧牲（接受必定錯誤率）並瞭解高几率地估計集合大小的方法，能夠避免設計出複雜，緩慢和佔用大量內存的從流數據中計算惟一元素數量的方案。

底層：瞭解機器

即便是在使用高級語言時，有不少程序裏的問題都是由對計算機完成特定任務的方式產生誤解形成的。由於所使用的工具或算法存在根本問題，這甚至可能致使項目須要從頭開始從新設計和實現。掌握好 C 語言，理解好 CPU 如何工做以及搞清楚內核如何運行、系統調用是怎樣實現的，能夠避免在後期出現嚴重的意外。

調試技巧

花費大量時間找 Bug 是很常見的事。若是你善於逐步獲取 Bug 狀態以用理性的步驟修復，而且編寫代碼的時候注意儘可能簡化以減小 Bug，就能夠大大提高效率。

在我看來，以上這些特質對輸出產生 10 倍的影響並不奇怪。它們使得好的實現能夠從一個可行的模型和比替代方案簡單數倍的設計開始。有一種強調簡潔性的方式，我喜歡稱之爲「機會主義編程」：在開發的每一步中，選擇實現對用戶有最大影響並須要最少努力的功能。