100 倍價值的工程師

（點選上方公眾號，可快速關註）

編譯：伯樂線上/精算狗

【導讀】：工程師如何花同樣的時間比其他人生產的價值多100倍：知道自己在做什麼，不需要別人過多幹預；不斷對自己發出挑戰，使工作更有效；一個人是無法成為100被價值工程師的，需要帶動周圍人一起提升生產力。

---

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

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

野心勃勃。我喜歡。

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

這讓我想起了上世紀 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，<>就會更高產！”現實是，一種不同的程式語言可能最多讓你達到 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 倍價值工程師的影響力。

【關於投稿】

如果大家有原創好文投稿，請直接給公號傳送留言。

① 留言格式：
【投稿】+《 文章標題》+ 文章連結

② 示例：
【投稿】《不要自稱是程式員，我十多年的 IT 職場總結》：

http://blog.jobbole.com/94148/

③ 最後請附上您的個人簡介哈~

覺得本文有幫助？請分享給更多人

關註「演演算法愛好者」，修煉程式設計內功