幾個月前一個新工程師加入了我們的團隊。和往常一樣，我花了些時間和他相處，來更好地了解他是哪種類型的人、他的驅動力是什么。我們經常討論過去的經歷，但更重要的是：未來的目標。結果發現，他有個有趣的目標：

「我想成為世界上最好的程序員」

野心勃勃。我喜歡。

但是，這讓我思考了一個問題：成為“最好的程序員”實際上意味著什么。怎么衡量“好”？怎么知道他（她）是“最好的程序員”？

這讓我想起了上世紀 60 年代，Sackman、 Erikson 和 Grant 撰寫的論文《Exploratory Experimental Studies Comparing Online and Offline Programming Performance》。該研究的目的是調查程序員在編程的多個方面的表現，無論他有電腦——那時是主機——的交互權限還是用“紙和筆”高效工作。盡管這個問題的答案幾乎要過時了——誰還在紙上編程啊——仍然有幾點發現現在仍然適用：

研究對象中，

最好和最差的程序員完成一個編程練習所用的編程時間有 20 倍的差距。

調試時間有 25 倍的差距。

所寫程序大小有 5 倍差距。

程序執行速度有 10 倍差距。

研究對象都有幾年的經驗，事實上經驗年數對這些數字似乎沒有顯著的影響。總之，差距還是挺顯著的，不是嗎？

10 倍價值的程序員

“10 倍價值程序員”這個概念起源于這篇論文。這個概念吸引了人們數十年，而且及其有爭議。直接 Google 一下這個英文短語（10x programmer）。

公平來講，Sackman 等人的數字一定被夸大了，很多人都對他們的方法提出了質疑。但是幾乎沒有人反對在糟糕的程序員與優秀的程序員之間有著顯著差距。甚至據傳，每個人都認識一個人，他能在極短時間內寫出驚人的軟件。

誰在乎？

“所以……誰在乎？”你可能會問。為什么 10 倍價值程序員這么重要呢？

一方面來說，10 倍價值程序員至少表面上對雇主來說是樁好買賣。理論上，雇主可以：

1.炒掉 90% 的員工

2.剩余 10% 雇傭 10 倍價值程序員

3.付給他們大約 2 倍工資

4.盈利

簡單，對吧？

然而現實會有點不一樣。首先，這假設你能招到一個 10 倍價值程序員的團隊……祝你好運。由于你很可能做不到這一點，你得把他們整合進現存的一倍價值程序員團隊中去。結果發現，團隊中有一個比你更更更高產的程序員并不是那么鼓舞人心。

但是實際上，我不想太過詳述 10 倍價值程序員這個概念。因為在我看來，有這么一群不同的“人種”，他們的影響力遠超過 10 倍價值程序員。

是誰呢？

我們先來仔細研究一下“程序員”這個概念。在 Sackman 的研究中，他們完全只關注編程能力。練習是高度與算法相關的，像“假定某網格代表一個迷宮，編寫一個程序找到通路”這樣的類型。好“程序員”擅長這種類型的工作：輸入編程挑戰，輸出代碼。每個程序員都有自己的任務列，并且在逐個完成。

輸入代碼。

如果這是你喜歡的工作，我肯定你能找到如此工作的地方。

然而，在我曾經工作的任何地方，實際編程都不是這樣的。實話實說——謝天謝地。我覺得長期這樣編程會無聊透頂的。

我覺得更有趣的角色是工程師的角色。工程師把想法變成實實在在的產品，他們也因此有更廣闊的視野。他們手頭有大量工具可以完成工作，當然編程也是工具之一。

但是實話實說，并且我想我也可以在此說，我們真的超級不擅長在那些被過分吹噓的技能。

統計量不會說謊：

（a）行業均值：“每 1000 行代碼中大約有 15 到 50 處錯誤。”他進一步聲明這對那些背后有一定程度結構化編程、可能混有一些代碼技巧的代碼具有代表性。

（b）微軟應用：“內部測試時每 1000 行代碼中大約有 10 到 20 處錯誤，發布產品中每 1000 行代碼中大約有 0.5 處錯誤（Moore 1992）。”他將其歸功于代碼閱讀技巧和獨立檢測的組合（在其著作的另一章中有進一步討論）。

（c）“Harlan Mills 開創了名為 ‘cleanroom development’ 的技巧，能實現在內部測試時每 1000 行代碼有 3 處錯誤，在發布產品中每 1000 行代碼有 0.1 處錯誤（Cobb 和 Mills 1990）。幾個項目——例如飛船軟件——利用了格式開發方法系統、同行審查和統計測試實現了在 500，000 行代碼中有 0 處錯誤的水平。

要我說——我們應該盡力避免編程，使世界免受每次在集成開發環境（IDE）中按下某鍵產生的所有 bug 的侵害。

所以沒錯，10 倍價值程序員是個好主意，但是我要把門檻設置得高一點。到 2018 年了，世界已經變了。

…………

100 倍價值工程師

我喜歡延伸目標。它們經常引導我們后退一步，并帶來思維的巨大轉變。這個目標也一樣。如果我們想成為 100 倍價值工程師——其影響力是老一倍價值工程師的 100 倍，該怎么實現呢？

做到自己高產并不夠——當然單單有編程天賦就可能實現 10 倍價值，但達到 100 倍價值就不可能了。為了擁有有 100 倍的影響力，你得讓團隊和組織的生產率均大幅提高，并最終領導其他人用同樣的工作方式。

盡管 100 倍價值聽起來很極端，我在職業生涯中仍然和許多我認為有“100 倍價值的觀念模式”、獨特的思考、說話和行動方式的人合作過。

可能讓某些人吃驚的是，這些與編程能力、科技和編程語言沒有任何關系。常見的口號是：“為什么我們還在用 Java？如果我們能只用 Scala、Clojure、Node，《《在此輸入今日便好 insert flavor of the day here》》就會更高產！”現實是，一種不同的編程語言可能最多讓你達到 1.5 倍到 2 倍。這與 100 倍價值相比簡直是小巫見大巫。100 倍價值是完全不同的游戲。

所以，到底什么是“100 倍價值的的觀念模式”？讓我們一起來討論兩個方面。

1. Ownership 所有權

100 倍價值工程師掌控他們所做的事。他們知道為什么這么做、怎么做、所做的是什么。在《Extreme Ownership》這本書中，兩位前海豹突擊隊隊員解釋了他們的極端所有權（extreme ownership）概念。這個概念的核心是，當我說“擁有某物”時到底意味著什么。這意味著：接受你要對你所做的任何事情負責。

最重要的是這意味著：不能指別人。這不意味著所有事情都在你的控制之下，卻意味著：當事情不可避免地出錯時，你要對你如何反應負責。這意味著：你要負責預期可能發生的事情，并做好應急措施。這意味著你要從錯誤中學習，甚至從中汲取價值。掌控你所做事情的各個方面。

要得到這種程度的所有權，我只知道一個方法：挑戰。挑戰你和你的團隊被要求做的任何事情，這樣你能理解并掌控每一個決定。

2. Challenging the status quo 挑戰現狀

100 倍價值工程師在三個維度進行挑戰：

1.做什么（What）？

這主要是關于范圍的：我們在開發什么？是否仔細研究過？要求是否明確？我們確定所有這些都是重要的并且需要（馬上）完成嗎？

2.怎么做（How）？

這是關于在怎樣機智地執行某事。有可以得到同樣結果的更輕松方法嗎？這也是關于過程的：我們怎么樣得到想要的結果，以及怎樣提高？

3.為什么（Why）？

這是關于業務環境的、關于完全理解為什么需要開發某個特性并檢查產品經理的方法是否是滿足用戶需求的正確方法。

來逐個看看更多細節。

What？ 做什么？

更快地提供某產品的唯一最好方法是：縮減范圍。它需要擁有的特性是什么。

可以在此應用我的“5 個真的嗎？”技巧：

產品經理：我們需要有所有這 10 個特性

100 倍價值工程師：真的嗎？

產品經理：嗯。

100 倍價值工程師：真的嗎？

產品經理：好吧，好吧，可能不需要第七個特性。但是剩下的都要。

100 倍價值工程師：真的嗎？

產品經理：嗯，是的，我是這么想的……讓我跟客戶確認一下。

好吧，他們可能需要第四個和第五個特性，但是我們可以之后再做這兩個。剩下的都是必須的。

100 倍價值工程師：真的嗎？

產品經理：是的。

這可能聽起來像個玩笑，但是產品經理常常會拿一張長長的必需特性清單出現。然后經過幾小時、幾天、有時是幾個月的談判后，你得到了一張幾乎只有原清單四分之一的清單。這是自然的，想出要加上的新特性要比移除特性更容易。

另一個在將范圍降低到較低水平的方法，是使用“帕累托法則”，二八法則。維基百科：

帕累托法則（也叫二八法則，關鍵少數法則，或者稀疏因子法則）表明，對很多事件來說，大約 80% 的影響來自于 20% 的原因。

該法則有很多應用，軟件開發就是其一。往往有很多種實現某特性的方法，使用極少的精力（比如說 20%）就能帶來大多數收益（例如 80%）。這點吸引人，不僅僅是因為更少的工作量，還因為你能更經濟地徹底檢查特性，并且只在這些特性有價值、使用過后才進行完全開發。

How？ 怎么做？

既然需要開發的清單已經減少到一小部分了，仍然要通過挑戰特性的實現方法來獲得機動空間和好處。一般來說，實現某特性有很多方法。一旦團隊想出一種方法，很多團隊就滿意了。100 倍價值工程師總會進一步尋找替代方法，根據各自的優缺點評估所有選擇。

“怎么做”也會被技術債務影響。經常有“變態的”方法來實現某些快、臟的特性，“合適的”方法來首先還清技術債務，再干凈地實現特性。什么是最好的方法？100 倍價值工程師認識到不只有一個正確答案，并且這取決于不同情況和累積技術債務的費用。一個 100 倍價值工程師能在不同的情景中作出正確抉擇，能在合適的時機和產品談判來降低技術債務。

“怎么做”的另一個方面是過程。我對 Scrum 很喜歡的一點是，它能有效設定一個基礎，如果用得合適可以鼓勵 100 倍價值的行為：

?改進是討論和挑戰做什么、怎么做和為什么的好平臺。產品所有者提出要開發的新特性，開發團隊挑戰做什么和為什么，來得到全面的背景，并相互挑戰如何實現特性。

?Plannings 針對下一步沖刺（sprint）做什么的計劃，計劃也是通往“輝煌和頭腦”的手段：記起到底需要做什么，并且計劃團隊如何合作來交付產品

?Retrospectives 回顧是團隊提升的方法。在一次沖刺循環中，有些事情出錯了，有些事情進展不順利。回顧是 100 倍價值工程師挑戰團隊來提升、下次做得更好的時刻。回顧也能練習所有權。100 倍價值工程師不抱怨低產，不指向自己以外的其他人。

Why？ 為什么？

上周我和一個工程師聊了聊，他剛剛發現自己花了整整 3 個月時間實現某特性，后來有發現對用戶來說同樣的價值本可以在 3 日內實現。顯然不會是同一種功能，但是實現的目標是一樣的。

這種事情怎么會發生呢？

除非工程師退后一步、擴大視野、挑戰為什么，這種事情就會發生。為什么要開發這個特性？用戶想要實現什么？他們的需求是什么？產品經理往往會提出非常具體的特性要求，偶爾具體化程度會比較低。他們的出發點是好的。然而更可能的情況是：產品經理也是人，也會遺漏。此外，風險在于工程師不再挑戰更基礎的問題：為什么我們要這么做？不是還有用其他更少的精力實現同樣結果的方法嗎？

但是，等等

說起來容易做起來難。做起來也應該難，不是什么人都應該能躋身 100 倍價值工程師。然而，我們都可以渴望變得更好，并找到相應的方法。

因此，看看 100 倍價值工程師的技能集合是值得的。你會注意到，這與 10 倍價值程序員是非常非常不同的。

?溝通——這點幾乎明顯得不用提了，但是它是重要的一點。100 倍價值工程師有優秀的溝通技巧。溝通是擁有 100 倍影響力的關鍵部分。

?創造力——顯然這在 10 倍價值程序員中是常見的，但是所要求的創造力不是關于算法的，也不是關于靈巧的類繼承結構（class inheritance structures）的，而是關于想出更有效的方法來實現目標。

?同理心——在“挑戰所有”的長篇大論中隱藏著“生產力挑戰”。那么我這么說意味著什么？讓我用我的大兒子做例子來解釋一下。他 4 歲了。4 歲小孩最喜歡的問題是什么？“為什么！？”這意味著我兒子是個 100 倍價值工程師嗎？不。為什么不呢？因為他總是問“為什么？”，無論時機正確與否，無論有沒有意義，無論他是不是讓他的父母想自殺。擁有知道該挑戰什么、怎么挑戰和何時挑戰的同理心也是 100 倍價值工程師的重要技能。

?談判——好主意被高估了。人人都有好主意，但幾乎沒人真正實現這些想法。你知道需要實現一個想法，實現它的一個重要因素就是談判——與其他開發人員談判，與產品經理談判，與其他利益相關者談判。解釋為什么某個主意是個好主意，以及為什么需要時間執行它們。100 倍價值工程師知道怎么做。所以當他們在場時，所有事情都似乎有可能實現。

?技術——這是清單上的最后一點，但依然重要。雖然大多數提到的技巧都是“軟實力”，但這并不意味著 100 倍價值工程師不需要技術。事實上，他（她）擁有領先的技術天賦是先決條件，原因有二：（1）挑戰技術層面上的事情會產生巨大收益，也因此要求對技術有深層次的理解；（2）理念是重要的，如果 100 倍價值工程師沒有高技術，就不會被同輩接受。你得是“我們的一員”。

…………

幾個月后，“我想成為世界上最好的程序員”先生作為程序員工作得非常順利。他有天賦、努力工作、高產而且非常聰明。他會成為世界上最好的程序員嗎？我不知道。

但是私下里，我希望這不重要。

我希望某一天，不是現在，但是可能是幾年后，他會想做更多事。那時他會調整他的理想，不僅僅要擅長這個叫“編程”狹窄領域，而且渴望擁有 100 倍價值工程師的影響力。