在編程神話中，一個 10 倍效率的程序員可以完成一個普通程序員 10 倍的工作量。「普通程序員」就是指，善于完成工作但沒有 10 倍效率程序員那神奇能力的人。實際上，為了更好地描述普通程序員，我們可以這樣認為，就是在專業程序員之中，代表那些可以輸出平均編程成果的程序員。

是否存在 10 倍效率的程序員，在這件事上編程社區內是嚴重的兩極分化：有人說根本沒有這樣的人，也有人說事實上不僅存在這種人，如果你知道到哪里去尋找，甚至還存在 100 倍效率的程序員。

如果你認為編程是一個“線性”的學科，那存在 10 倍效率的程序員這件事看起來幾乎是不可能的。一個跑步的人怎么可能跑得比另一跑步的人快10倍？在相同的時間內，一個建筑工人怎么可能建造東西的速度比另一個建筑工人快 10 倍？然而編程是一門設計學科，并以一種非常特殊的方式。即使程序員不參與實際的程序的架構設計，實施它的行為仍然需要一個實施策略上的子設計。

因此，如果一個程序的設計和實現不是線性能力，像經驗、編碼能力、知識和識別等無用之物，在我看來，不僅僅是線性的優勢，當這些事物作用在一起時，它們的效果就遠不是一加一這么簡單了。當然，當程序員可以同時處理程序的設計和實現時，這種現象發生得更多。如果越以“目標導向”為任務，那么擁有10倍效率潛力的程序員為了輕松地達到目標就越可以開拓她/他的能力。

當手頭有非常剛性的任務時，這個任務有具體的指南：必須使用哪些工具和如何實現事物。那么 10 倍效率的程序員在更短的時間內執行大量工作的能力就被削弱了：他仍然可以開拓“局部”上設計的潛能，但卻不能以更意義深遠的方式去實現目標，這也許包括，可能、甚至完全從項目中刪除部分規范，即便需要達到的目標幾乎看起來相同但需要付出的努力程度由于一個大因素被減少了。

在作為程序員工作的二十年中，我觀察著與我一起工作的其他由我指導的程序員同事，我下發指定的目標，他們則給 Redis 和其他項目提供補丁。期間，很多人告訴我，他們相信我是一個非常高效的程序員。考慮到我根本不是一個工作狂，我也把自己當作快速編碼的一類人。

以下這些品質，我認為將引發程序員生產力高低截然不同：

純粹的編程能力：完成子任務

程序員最顯著的限制或優勢之一就是處理實際執行程序部分的一個子任務：一個函數，一個算法等。令人驚訝的是，根據我的經驗，非常有效地使用基本的命令式編程結構來實現某些功能的能力，并不像人們想象的那么普遍。在一個團隊中，有時我觀察到非常無能的程序員，甚至不知道一個簡單的排序算法，和在理論上非常有能力、但實施解決方案的實踐非常不足的剛畢業程序員相比，他們的工作往往事倍功半。

經驗：模式匹配

通過使用經驗：我的意思是一系列已經探索完成的用于大量重復的任務解決方案。有經驗的程序員最終知道如何處理各種子任務。這既避免了很多的設計工作，也是針對設計錯誤的非常強大的武器，但反過來卻又是簡潔的最大敵人之一。

專注：實際時間 VS 虛假時間

如果不考慮時間質量，那么評價花費多少時間來編寫代碼是不恰當的。內部和外部因素都可能導致專注度下降。內部因素是拖延，對手邊的項目缺乏興趣（你不能做好你不喜歡的事情），缺乏運動/福祉，不好的睡眠質量或者睡眠不足。外部因素是頻繁的會議，沒有實際辦公室的工作環境，同事經常打擾等等。很自然的是，嘗試改善專注度和減少中斷對編程生產率將產生非邊際影響。有時為了變得專注，需要采取極端措施。例如，我只會偶爾閱讀電子郵件，并且不回復他們中的大多數。

設計上的犧牲：刪減 5%，獲得 90%

當不愿意認識到一個項目的非基本目標占據了很大的設計復雜性，或者正在使另一個更重要的目標難以實現時，往往會產生復雜性，因為在基本特征和非基本特征之間有設計張力。設計師認識到設計中所有不容易實現的部分是非常重要的，即在努力和優勢之間沒有絕對的比例。為了最大限度地實現產出而執行的一個項目，將完全地集中在可以在合理的時間內實現的方面。例如，當設計Disque（一個消息的代理工具）時，在某些時候，我意識到通過為消息提供性能最好的順序，項目的所有其他方面都可以大大提升：可用性、查詢語言和客戶端交互、簡潔性和性能 。

簡潔性

設計時保持簡潔性，這個明顯的觀點意味著一切。為了理解什么是簡潔性，核查復雜性大多數時候是如何產生的是值得做的。我認為復雜性的兩個主要驅動因素：不愿意進行設計上的犧牲以及在設計活動中累積的錯誤。

如果在設計過程中，每次都追求錯誤的路徑，我們將離最優解決方案越來越遠。一個初始設計錯誤，在不好的方面，不會導致該系統重新設計。為了應對初始設計錯誤，卻會導致另一個復雜的解決方案被設計。因此，項目在每個錯誤的步驟之后將變得更加復雜和效率低下。

實現簡潔性的方式是以“概念證明”來推敲，從看起來最可行和直接的解決方案開始工作，以便大量簡單的設計能在程序員腦中被探索。之后，經驗和個人設計能力將有助于改進設計，并為需要解決的子設計找到合理的解決方案。

然而，每次需要實現一個復雜的解決方案時，重要的是要長時間地推敲如何避免復雜性，只有在沒有更好的可能性的、即使考慮到完全不同的替代方案情況下，才繼續這個方向。

完美主義，或者如何扼殺你的生產力和影響你的設計

完美主義有兩種變體：在程序中達到最佳可衡量的性能的工程文化，以及作為一種人格特征。 在這兩種情況下，我認為這是程序員快速交付事情的最大障礙之一。 完美主義和外部帶有偏見的觀點的恐懼帶入了一種設計偏差，導致僅根據心理或簡單可衡量的參數來改進設計時可選擇項較少，其中諸如健壯性、簡潔性、及時交付的能力往往不被考慮。

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

在處理復雜任務時，有關數據結構的知識、計算的基本限制和非常適合于模擬某些任務的非平凡算法將對找到合適設計的能力產生影響。 成為一切事物的超級專家不是必需的，但是至少，知道一個問題的潛在解決方案是必需的。例如，應用設計犧牲（接受一些誤差百分比）和清楚概率集合基數估計器可以組合在一起，以避免復雜、緩慢和記憶效率低下的用于統計整個流程中唯一的項目的解決方案。

底層：了解核心

即使使用高級語言，程序中的一些問題也是由于對計算機如何執行給定任務的誤解而產生的。 這甚至可能導致需要從頭開始重新設計和重新實現項目，因為在使用的工具或算法中存在著根本問題。良好的 C 語言能力，了解 CPU 的工作原理以及關于內核如何運行以及系統調用如何實現，這些可以避免糟糕的后期意外。

調試技巧

有時候為了發現那些 bug 會花費大量的工作時間。善于獲取一個bug的狀態、一系列合理的解決問題的步驟、以及編寫不太可能包含太多錯誤的簡單代碼的態度，這三點對程序員的工作效率有很大的影響。

看到程序員的上述品質如何能夠對輸出產生 10 倍的影響，我并不奇怪。 結合起來講，從可行的模式開始，它們允許良好的設計實現，可以比替代方法簡單幾倍。 有一種方法可以用來強調簡潔性，我喜歡稱之為“機會主義編程”。 基本上在每個開發步驟中，選擇一系列要實施的功能，用最少的付出，以最大程度地影響程序的用戶基礎。