Redis之父：10x程序員應該具備哪些素質？

英文原文：The mythical 10x programmer

編者按：在開發界有一個長期引起爭議的說法，那就是所謂的 10x 程序員是否存在？這個說法是 Brooks, F. P 在《沒有銀彈》中首次提出的，他認為在普通設計師（程序員）和優秀設計師（程序員）之間，有著 10 倍多的差異。對于 10x 程序員是否存在這個問題，開源鍵值存儲數據庫系統 Redis 的開發者 antirez（Salvatore Sanfilippo）認為，如果把編程工作看作是一門“非線性”學科的話，那么不僅存在 10x 程序員，甚至連 100x 程序員這種異獸都有，同時他還列出了自己認為的 10x 程序員必備的一些素質，可供各位開發者對照一下。

10x 程序員，是指在編程方法論中，所做的工作 10 倍于普通程序員的程序員。而所謂的普通程序員是指擅長所做工作，但卻沒有 10x 程序員魔力的程序員。實際上“普通程序員”這么歸納也許更好：普通程序員是指在專業的程序員當中有著平均編程產出的人。

對于這樣一種異獸是否存在，編程社區有著兩級分化的觀點：有人說所謂的 10x 程序員并不存在，而有人則說 10x 程序員不僅存在，而且甚至 100x 程序員都有，如果你知道去哪里找的話。

如果你把編程看作是“線性”的學科，那么顯然 10x 程序員存在的可能性是不合邏輯的。一名跑步運動員怎么可能比另一名快 10 倍？或者一名建筑工人在相同時間內建造的東西怎么可能比另一名多 10 倍？然而，編程是一門設計學科，屬于一種特殊的設計。即便程序員并未參與到程序實際的架構設計當中，但實現本身仍然需要對實現策略的子設計。

那么，在我看來，如果程序的設計和實現不是一種線性能力的話，像經驗、編碼能力、知識、對無用部分的識別等這些就不僅僅是線性優勢，而且湊到一起會對程序的編制產生倍增效應。當然，如果程序員能夠同時處理程序的設計和實現時，這種現象會出現得多很多。任務越是“目標導向”，10x 程序員以事半功倍的方式發揮能力的潛能就越大。如果手頭的任務比較僵化，對于應該使用什么工具以及應該如何實現東西等方面有著具體指南的話，10x 程序員以更少時間完成更多事情的能力就會變弱：雖然仍然可以通過挖掘“本地”設計的可能性來把工作做得更好，但卻不能以更加深遠的方式（這種方式包括甚至連項目的部分規范都徹底去掉，從而仍然能夠以幾乎相同的效果實現目標，同時實現所需的付出卻要少了一大截）去改變目標的實現路徑了。

在 20 年程序員的生涯當中，我觀察了跟我一起工作的程序員同事，他們在我的指導下實現給定目標，為 Redis 等項目打補丁等。與此同時，許多人告訴我說他們認為我是一個非常快的程序員。考慮到我遠不是個工作狂，我也把我自己作為是編碼非常快（效率高）的人的參考。

以下所列我認為是最能拉開程序員生產力差異的一些素質：

裸編程能力：完成子任務

程序員最大的限制或者說優勢之一，就是處理程序實際實現部分的子任務，也就是實現函數或者算法之類的能力。令人吃驚的是，就我的經驗來看，非常有效地利用必要的基本編程結構去實現東西并不是一種普遍具備的能力。在一個團隊中我有時候觀察到有的程序員看似非常的不勝任，因為他們甚至連一個簡單的排序算法都沒有意識到，但是所完成的工作卻要比那些理論上極其勝任、但在實現解決方案的實踐方面卻非常糟糕的已經畢業的程序員還要多。

經驗：模式匹配

所謂經驗是指一組已經過探索的、針對若干周期性任務的解決方案。有經驗的程序員最終會知道如何處理各種子任務。這既避免了大量的設計工作，但尤其重要的是它還是一項針對設計錯誤的強大武器，而后者是簡潔性的最大敵人之一。

專注：實際時間 vs 假設時間

如果不看時間質量的話編寫代碼花費的小時數無關緊要。缺乏專注往往有來自于內外部因素的影響。內部因素是拖延癥，對手頭項目缺乏興趣（不熱愛的事情是做不好的），缺乏練習/快樂，睡眠不足或很少等。外部因素包括頻繁開會，工作環境沒有真正的辦公室，同事經常打斷自己等等。試圖改善專注和減少中斷會對編程生產力產生非邊際效應，這是很自然的。有時候為了獲得專注，需要極端的手段。比方說我只會時不時讀讀郵件，但是大部分都不會去回復。

設計犧牲：干掉5% 得到 90%

當不愿意認識到項目的一個非根本性的目標要對設計的很大一部分復雜性負責時，或者由于某基本功能與次要功能之間存在設計沖突而導致另一個更加重要的目標難以實現時，復雜性就產生了。設計的所有部分都不會輕而易舉實現，也就是說，付出的努力與得到的好處之間是不成比例的，設計師意識這一點非常重要。旨在取得最大化產出的項目只會專注于重要且可以在合理時間內實現的事情上。比方說，在設計消息代理 Disque 的時候，在某一刻我突然意識到只需要為消息提供盡力而為的排序，項目的其他方面就都可以獲得實質性的改進：比如可用性、查詢語言以及客戶端交互、簡潔性和性能等。

簡潔性

這一點的重要性很顯然，意味著成王敗寇。為了理解什么是簡潔性，看看復雜性往往是如何產生是值得的。我認為復雜性的兩個主要的驅動力是不愿意做出設計上的犧牲，以及設計活動中錯誤的累積。

只要思考一下設計流程，每一次追求到一條錯誤的路徑時，我們就會距離最優方案越來越遠。一項初步設計錯誤，如果落到錯誤的人手中的話，他不會對同一系統進行重新設計，而是會為了處理當初的錯誤而設計出另一套復雜的解決方案。因此每邁出錯誤的一步該項目都會變得更加復雜、效率更低。

簡潔性可以通過在腦子里進行“概念驗證”方面的推理來實現，這樣可以讓程序員對大量的簡單設計進行探索，然后從看起來最可行和直接的解決方案開始。隨后利用經驗和個人設計能力可以改進設計，為有待解決的子設計找到合理的解決方案。

無論每次需要多復雜的解決方案，對于如何避免這種復雜性進行長時間的推敲都是很重要的，只有在考慮過完全不同的替代方案也沒有發現更好的可能性之后才可以繼續原方案。

完美主義，或者如何干掉你的生產力，偏袒你的設計

完美主義有兩種派生：一種是癡迷在程序中實現可能達到的、可衡量的最佳性能的工程文化，另一種是作為個人特質。我把這兩種情況均視為程序員快速交付的最大障礙之一。完美主義以及對外部評判的恐懼會植入一種設計偏見，導致會根據心理或者無關緊要的可衡量參數而做出糟糕的重新設計選擇，而像健壯性、簡潔性、及時交付的能力往往卻從未考慮。

知識：一些理論會有所幫助

在處理復雜性任務時，有關數據結構、計算的根本性限制、非常適合對特定任務建模的算法方面的知識對于找到合適設計的能力會產生影響。你沒有必要成為一切事情的超級專家，但是至少能意識到某問題存在大批潛在解決方案是必要的。

底層：理解機器

程序里面的出現一些問題，即便是使用高級語言的時候，往往都是因為誤解了計算機執行特定任務的方式。就因為使用的工具或者算法存在根本問題，甚至會導致需要進行從頭開始對項目進行重新設計和重新實現。非常擅長C語言，理解 CPU 的工作方式，對于內核如何運作、系統調用如何實現有著清晰了解的話，可以避免到了后面遇到糟糕的“驚喜”。

調試技能

為了找到 bug 往往很容易就會花費掉大量的精力。擅長逐步地獲取 bug 相關狀態，以便在合理的步驟內修補好問題，知道編寫簡單代碼不大可能會導致太多 bug，這些對于提高程序員的效率都會產生很大的影響。

在我看來，如果一位程序員具備上述特質的話，能夠取得 10 倍于平均水平的產出并不奇怪。這些特質聯合起來可以先從可行模型開始，慢慢做出好的設計實現，而且做出來的東西往往要比替代方案簡單好幾倍。為了強調簡潔性，我愿意稱之為“機會主義編程”。意思是說在開發的每一步都要對實現的功能集進行挑選，目的是為了以最小的代價對程序的客戶群產生最大的影響。

來自: 36kr.com