在程式設計神話中，一個 10 倍效率的程式設計師可以完成一個普通程式設計師 10 倍的工作量。「普通程式設計師」就是指，善於完成工作但沒有 10 倍效率程式設計師那神奇能力的人。實際上，為了更好地描述普通程式設計師，我們可以這樣認為，就是在專業程式設計師之中，代表那些可以輸出平均程式設計成果的程式設計師。
（Redis 作者 antirez ）
是否存在 10 倍效率的程式設計師，在這件事上程式設計社群內是嚴重的兩極分化：有人說根本沒有這樣的人，也有人說事實上不僅存在這種人，如果你知道到哪裡去尋找，甚至還存在 100 倍效率的程式設計師。
如果你認為程式設計是一個“線性”的學科，那存在 10 倍效率的程式設計師這件事看起來幾乎是不可能的。一個跑步的人怎麼可能跑得比另一跑步的人快10倍？在相同的時間內，一個建築工人怎麼可能建造東西的速度比另一個建築工人快 10 倍？然而程式設計是一門設計學科，並以一種非常特殊的方式。即使程式設計師不參與實際的程式的架構設計，實施它的行為仍然需要一個實施策略上的子設計。
因此，如果一個程式的設計和實現不是線效能力，像經驗、編碼能力、知識和識別等無用之物，在我看來，不僅僅是線性的優勢，當這些事物作用在一起時，它們的效果就遠不是一加一這麼簡單了。當然，當程式設計師可以同時處理程式的設計和實現時，這種現象發生得更多。如果越以“目標導向”為任務，那麼擁有10倍效率潛力的程式設計師為了輕鬆地達到目標就越可以開拓她/他的能力。
當手頭有非常剛性的任務時，這個任務有具體的指南：必須使用哪些工具和如何實現事物。那麼 10 倍效率的程式設計師在更短的時間內執行大量工作的能力就被削弱了：他仍然可以開拓“區域性”上設計的潛能，但卻不能以更意義深遠的方式去實現目標，這也許包括，可能、甚至完全從專案中刪除部分規範，即便需要達到的目標幾乎看起來相同但需要付出的努力程度由於一個大因素被減少了。
在作為程式設計師工作的二十年中，我觀察著與我一起工作的其他由我指導的程式設計師同事，我下發指定的目標，他們則給 Redis 和其他專案提供補丁。期間，很多人告訴我，他們相信我是一個非常高效的程式設計師。考慮到我根本不是一個工作狂，我也把自己當作快速編碼的一類人。
以下這些品質，我認為將引發程式設計師生產力高低截然不同：
純粹的程式設計能力：完成子任務
程式設計師最顯著的限制或優勢之一就是處理實際執行程式部分的一個子任務：一個函式，一個演算法等。令人驚訝的是，根據我的經驗，非常有效地使用基本的指令式程式設計結構來實現某些功能的能力，並不像人們想象的那麼普遍。在一個團隊中，有時我觀察到非常無能的程式設計師，甚至不知道一個簡單的排序演算法，和在理論上非常有能力、但實施解決方案的實踐非常不足的剛畢業程式設計師相比，他們的工作往往事倍功半。
經驗：模式匹配
通過使用經驗：我的意思是一系列已經探索完成的用於大量重複的任務解決方案。有經驗的程式設計師最終知道如何處理各種子任務。這既避免了很多的設計工作，也是針對設計錯誤的非常強大的武器，但反過來卻又是簡潔的最大敵人之一。
專注：實際時間 VS 虛假時間
如果不考慮時間質量，那麼評價花費多少時間來編寫程式碼是不恰當的。內部和外部因素都可能導致專注度下降。內部因素是拖延，對手邊的專案缺乏興趣（你不能做好你不喜歡的事情），缺乏運動/福祉，不好的睡眠質量或者睡眠不足。外部因素是頻繁的會議，沒有實際辦公室的工作環境，同事經常打擾等等。很自然的是，嘗試改善專注度和減少中斷對程式設計生產率將產生非邊際影響。有時為了變得專注，需要採取極端措施。例如，我只會偶爾閱讀電子郵件，並且不回覆他們中的大多數。
設計上的犧牲：刪減 5%，獲得 90%
當不願意認識到一個專案的非基本目標占據了很大的設計複雜性，或者正在使另一個更重要的目標難以實現時，往往會產生複雜性，因為在基本特徵和非基本特徵之間有設計張力。設計師認識到設計中所有不容易實現的部分是非常重要的，即在努力和優勢之間沒有絕對的比例。為了最大限度地實現產出而執行的一個專案，將完全地集中在可以在合理的時間內實現的方面。例如，當設計Disque（一個訊息的代理工具）時，在某些時候，我意識到通過為訊息提供效能最好的順序，專案的所有其他方面都可以大大提升：可用性、查詢語言和客戶端互動、簡潔性和效能 。
簡潔性
設計時保持簡潔性，這個明顯的觀點意味著一切。為了理解什麼是簡潔性，核查複雜性大多數時候是如何產生的是值得做的。我認為複雜性的兩個主要驅動因素：不願意進行設計上的犧牲以及在設計活動中累積的錯誤。
如果在設計過程中，每次都追求錯誤的路徑，我們將離最優解決方案越來越遠。一個初始設計錯誤，在不好的方面，不會導致該系統重新設計。為了應對初始設計錯誤，卻會導致另一個複雜的解決方案被設計。因此，專案在每個錯誤的步驟之後將變得更加複雜和效率低下。
實現簡潔性的方式是以“概念證明”來推敲，從看起來最可行和直接的解決方案開始工作，以便大量簡單的設計能在程式設計師腦中被探索。之後，經驗和個人設計能力將有助於改進設計，併為需要解決的子設計找到合理的解決方案。
然而，每次需要實現一個複雜的解決方案時，重要的是要長時間地推敲如何避免複雜性，只有在沒有更好的可能性的、即使考慮到完全不同的替代方案情況下，才繼續這個方向。
完美主義，或者如何扼殺你的生產力和影響你的設計
完美主義有兩種變體：在程式中達到最佳可衡量的效能的工程文化，以及作為一種人格特徵。 在這兩種情況下，我認為這是程式設計師快速交付事情的最大障礙之一。 完美主義和外部帶有偏見的觀點的恐懼帶入了一種設計偏差，導致僅根據心理或簡單可衡量的引數來改進設計時可選擇項較少，其中諸如健壯性、簡潔性、及時交付的能力往往不被考慮。
知識：一些理論將會有所幫助
在處理複雜任務時，有關資料結構的知識、計算的基本限制和非常適合於模擬某些任務的非平凡演算法將對找到合適設計的能力產生影響。 成為一切事物的超級專家不是必需的，但是至少，知道一個問題的潛在解決方案是必需的。例如，應用設計犧牲（接受一些誤差百分比）和清楚概率集合基數估計器可以組合在一起，以避免複雜、緩慢和記憶效率低下的用於統計整個流程中唯一的專案的解決方案。
底層：瞭解核心
即使使用高階語言，程式中的一些問題也是由於對計算機如何執行給定任務的誤解而產生的。 這甚至可能導致需要從頭開始重新設計和重新實現專案，因為在使用的工具或演算法中存在著根本問題。良好的 C 語言能力，瞭解 CPU 的工作原理以及關於核心如何執行以及系統呼叫如何實現，這些可以避免糟糕的後期意外。
除錯技巧
有時候為了發現那些 bug 會花費大量的工作時間。善於獲取一個bug的狀態、一系列合理的解決問題的步驟、以及編寫不太可能包含太多錯誤的簡單程式碼的態度，這三點對程式設計師的工作效率有很大的影響。
看到程式設計師的上述品質如何能夠對輸出產生 10 倍的影響，我並不奇怪。 結合起來講，從可行的模式開始，它們允許良好的設計實現，可以比替代方法簡單幾倍。 有一種方法可以用來強調簡潔性，我喜歡稱之為“機會主義程式設計”。 基本上在每個開發步驟中，選擇一系列要實施的功能，用最少的付出，以最大程度地影響程式的使用者基礎。