原文鏈接：http://antirez.com/news/112
infoQ翻譯：http://www.infoq.com/cn/news/2017/04/Redis-father-10x?utm_source=infoq&utm_medium=popular_widget&utm_campaign=popular_content_list&utm_content=homepage
傳說中的10x程序員是指那些工作效率超過普通程序員10倍的人。我們所說的普通程序員可以勝任一個他的本職工作，但是卻沒有10x程序員的神奇能力。更準確一些，我們所說的“普通程序員”是指那些可以達到業內平均水平的編程人員。
編程社區中對于這樣的“怪物”是否存在，有著很大的爭議：部分人認為10x程序員根本就不存在，而其他的人認為不僅僅他是存在的，甚至還能找到100x程序員。
如果你認為編程是一種“線性”的工作，那毫無疑問10x程序員是不可能存在的，就像不可能有人能比其他人跑得快10倍一樣，也不可能有建筑工人在同一時間內比別人多干10倍的活。然而編程是一種特殊的設計工作。即使一個程序員從來沒有刻意訓練過編程方面的架構設計，在實現功能的過程中也需要一些簡單的設計。
在我看來，設計和實現程序都不是“線性”能力，它是由經驗，編碼能力，知識，對無用部分的甄別能力等這一系列非線性優勢組合而成的，尤其是當一個程序員同時負責設計和實現時，這個現象就更加明顯。任務越是目標明確，10x程序員就月能釋放他的潛力來盡快達成目標。如果手上的工作非常死板，比如規定了必須要用什么工具來用什么方式完成任務，那么10x程序員的高效能力則會被削弱。他們始終可以在“局部地區”通過設計完成更好的工作，然而卻不能用更直接的方法來完成目標（甚至是拋棄現有工程的某些部分）。看上去最終達成的目標是相同的，但是效率卻大打折扣。
在二十年的職業生涯中，我關注著其他和我一起協作的程序員。他們在我制定的目標下一起完成一些任務，例如給Redis打補丁等等。同時許多人告訴我，他們認為我是一名十分高效的程序員。雖然我并不是一名工作狂，但我也經常會那自己來作為快速編碼的例子來介紹給別人聽。
下面列舉的品質是我認為的高產程序員的獨特品質。
分解編程任務的能力：完成各個子任務
將程序的分解為各種子任務（函數，算法或者其他），是程序員最顯著的能力之一。然而令人震驚的是，并沒有那么多人使用最基本的變成結構來有效地實現一些功能。我觀察到一些連最簡單的排序算法都不會的“低能”程序員，卻比那些受過良好理論教育（但缺乏實踐）的程序員完成更多的工作。
經驗：模式匹配
這里我說的經驗是指對于那些經常出現的任務的一系列解決方案。一名有經驗的程序員事實上知道如何去將問題分解。這樣就避免了很多的設計工作并且可以避免出現簡化問題時出現的最大問題——設計錯誤。
專注：實際時間VS假想時間
拋開時間的利用質量，只關注寫代碼所話費的時間，都是耍流氓。注意力無法集中可能由外因和內因兩方面導致。內因包括拖延癥，或者對手頭的項目不感興趣（你無法好好的做自己不喜歡的事情），缺乏鍛煉或者身體狀況不佳，以及缺乏睡眠。外因則是頻繁的會議，工作環境不佳，協作者的頻繁打斷。所以人們會很自然地想要提高注意力的集中程度，以及去減少打斷的次數來創造一個沒有邊界效應的編程環境。有時候為了可以更好地集中注意力，一些極端的方法也是必要的。比如我只在固定的時間點去閱讀郵件并且不會進行回復。
設計方面的犧牲：舍棄5%來贏得90%
項目的非基本功能會大大增加設計的復雜度，或者導致另外一個重要的目標難以達成，這是因為由于不重要的目標和基本功能之間總是存在著牽連，所以這么做會使任務變得非常復雜。所以設計者必須要意識到，項目中哪些部分是投入和產出不成正比的。如果一個工程是為了將輸出最大化，那我們只需要將精力集中在與之相關的方面，這樣就可以在合理的時間內完成它。舉個例子，當我們設計消息隊列 Disque時，我意識到最值得付出的功能是將消息組織排序，從而其他的各個方面就會有實質上的進步，包括可用性，請求語言和客戶端交互，簡潔性和性能。
簡潔性
這顯然是成敗的分界點。為了理解簡潔性是什么，我們有必要去找到復雜性產生的原因。我認為兩個導致復雜性的主要原因是不愿意犧牲部分設計，以及設計上的錯誤積累。
試想一下，在設計的過程中每一次我們都誤入歧途，最終會使我們離最優解越來越遠。最初的設計錯誤并不會讓這整個系統被重新設計，而是會導致下一次使用另一個復雜的解決方案來掩蓋它。從而整個工程會變得越來越復雜，并且在每一次錯誤的設計之后變得更加低效。
在腦海中進行許多細碎的“概念驗證”后，大量的簡介設計會在程序員的心里浮現，從而開始構建靈活而又有效的解決方案并最終達到簡潔性。之后，經驗和個人設計能力將會進一步提升設計和找到合理的子任務解決方案。
然而每當需要用到復雜的解決方案時，就需要花大量的時間來構思如何避免它，直到實在沒有其他可以代替的方案之后才能繼續前行。
完美主義， 為了偏袒設計而削弱生產力
完美主義有兩種：追求工程師文化中理論上的最強性能，或者追求個人特色。我認為這兩種都將阻礙程序員的生產力。完美主義和害怕外部的評價導致了設計上的偏袒，從而導致最終只是根據個人意愿和性能指標來作出設計方案，健壯性、簡潔性和按時交付都不會被考慮在內。
學識：某些理論知識是很有用的
如果了解數據結構，知道計算的極限性能，以及對于某些模型非差給你適用的算法，那么在面對復雜問題時就能給出非常合適的設計。你并不需要在各個方面都十分精通，但是知道問題的多種解決方案確實很有必要的。例如我們在設計上做出部分妥協（接受一定比例的錯誤）和并且預估了總體的基數，那么兩者結合就可以避免在一個數據流中進行統計特定目標這個問題上，給出一個復雜低速和內存使用率低的方案。
了解底層原理
即使在使用高級語言的時候，我們仍然會因為不理解計算機的運行原理而導致編寫出來的程序有些問題。這會導致我們必須推翻之前的設計，因為在某些工具或者算法上存在根本性的錯誤。深入理解C語言，并清楚的知道CPU和內核的工作原理，可以避免在工程后期發現一些根本上的問題。
調試技巧
尋找bug總是會花掉很多時間。所以如果你善于發現bug出現的原因，知道如何將它修復，并且更傾向與寫那些簡短的無誤代碼，將會大大提高你的編程效率。
對我而言，擁有上述品質的人能到達10倍的產出一點也不奇怪。這些品質讓程序員可以給出一個擁有靈活的模型的好設計，并且比其他的方案更加的簡潔。我認為簡潔性就是一種“投機取巧的編程”。簡而言之，就是在開發的每個階段選擇性地實現一些功能，以最小化的付出為用戶帶來最大化的影響。
