最近，我在網上看到不少關于 10 倍開發者的討論。有些人想要成為這樣的人，也有些人想遠離這樣的人。但在此之前，我們可能先要弄清楚這樣一個問題：10 倍開發者真的存在、只是傳說，或者僅僅是人們由于相對認知而感受到的概念？

在得出結論之前，我想先給大家講講自己的經歷。

1. 與 10 倍開發者共事

大約十年之前，公司的軟件開發總監雇傭了一名三級軟件工程師，我們都叫他 Gary。大概在同一時期，我們還雇用了一位名叫 Mitch 的二級軟件工程師。最初幾個月里，Gary 非常安靜，總是一個人待著，努力解決一個個純技術性的問題。當時我們的任務，是為實時 3D 機械訓練軟件制作空氣等流體的流動動畫。公司里的每個人都一直希望實現這個效果，但由于種種挑戰，始終未能達成。而 Gary，成為幫助我們沖擊難關的英雄。

在他準備把功能提交給 QA 進行審查時，整個功能的觀感至少比我想象中還要好，性能也超出預期，并擁有數千項單元測試斷言作為支持。相比之下，我們的主體代碼庫根本就沒經受過這么全面的測試。不用說了，各級管理人員都對這項睽違已久的功能感到非常滿意。

我們的代碼中有很多龐大，而且復雜得讓人害怕的部分。

不久之后，Gary 又組織了一次工程展示。展示內容主要集中在架構層面，即圍繞對象生命周期、依賴倒置、ad-hoc 生命周期 / 明確限定范圍的對象、某些分配反模式的危害、有礙單元測試覆蓋的代碼耦合，以及這些因素與很多內部工程問題之間的關聯等等。這次展示讓與會者們感到困惑，甚至感到頗為尷尬。畢竟這一切赤裸裸的批評，指向的正是那些最早加入公司、并一路構建起知識產權體系的老員工。

我們的技術債務問題確實嚴重，但……也沒有那么嚴重。雖然不會影響到生產力，但我們的代碼中確實有很多龐大、而且復雜得讓人害怕的部分。Gary 要做的正是揭露出這一切。但我們壓力很大，因為我們每個人都是他提出的問題中的一部分。

他對現代軟件設計的理解領先我們好幾年。

這個人的特點是，他永遠是對的。不只是在爭論當中，也包括在各種判斷當中，他更像是個全知全能的神。雖然我一直以先弄清事實再發言的好習慣著稱，但我也得承認，在整個共事期間我一共只揪出過他一到兩次不太準確的表達。和這樣的人共事壓力很大，因為同事們總會發現一些自己本該了解、但卻一無所知的重要知識。考慮到他們往往與 Gary 有著同樣的職稱和頭銜，這就更讓人感到無地自容。

人性總有陰暗面，大家不喜歡那些特別聰明的人。特別是在對方提出的真知灼見既正確、又缺乏善意時，就更是讓人不爽。所以同事們的普遍共識是，這家伙是個刻薄鬼。我個人并不覺得他是故意要讓人難堪，但 Gary 在讓人難堪這事上真的很有天賦。與此同時，他對現代軟件設計的理解領先我們好幾年，而這些心得還得在我們公司逐步實踐，也許他覺得身邊的同事真的讓他很失望。

公平地講，我們沿用陳舊技術與方法是有原因的，而且也靠這些舊辦法開發出了強大的產品。任何公司都可能存在類似的問題。

Gary 強悍的技術實力加上對于敏捷流程的堅定擁護，最終擠走了雇用他的老領導，并由他自己上位。同事們震驚了一段時間，但很快就發現 Gary 主管帶來了一系列令人興奮的新變化。公司調整了自身產品各類，Mitch、我和另一位新任軟件開發測試工程師（SDET）并納入新團隊中，嘗試公司之前從未做過的工作。

根據交流感受，Gary 一直以為我是二級軟件工程師。但在發現我實際上只是一級時，他相當憤怒，并很快去找公司高層理論。幾周之后，我就升職了。同樣的，Mitch 雖然只是二級軟件工程師，但他卻擁有不遜于三級工程師的知識與技能。但沒辦法，他只能等……不知道在等什么，總之需要一段時間才能得到與自己水平相符的職稱。

有時候，Mitch 與 Gary 形影不離。我記得我們曾經花無數個小時在辦公室里對未來新產品的架構設計組織頭腦風暴與思維實驗。到這個時候，我才意識到這兩位的水平高到不知道哪里去了。有很長一段時間，他們兩個人似乎開始用一種獨特的語言交流。雖然他們之前從來沒有協作過，但他們都認為公司內部缺少現代編程的基本概念。剛開始，人們不喜歡這兩個人在那里說東說西；但事實證明，在他們碰頭之后，兩個人的編碼效率確實高、質量也是真的穩定。

我這個人比較擅長處理技術上的困難任務，Mitch 特別聰明，而 Gary 則擁有最強的編碼質量。更讓人稀奇的是，雖然 Gary 總是在全體大會和管理層會議中占用很長的時間，包括設計并記錄新的標準流程、為各個開發者提供幫助與指導，但我到現在也不太確定他究竟是怎么在短時間內為公司帶來這么顯著的生產力提升的。總之在他的帶領下，整個團隊都不需要加班了，包括他自己。

讓所有開發者擁有共同的價值觀，是建立和諧團隊與強大代碼庫的關鍵。

盡管我已經有了幾年的編程經驗，但在 Gary 團隊中度過的兩年，絕對為我后續的高級開發者頭銜奠定了良好的基礎。他幫助我改掉了不少多年來養成的習慣——就是那種特別普遍，但并沒什么用處，有時候甚至令人討厭的習慣。相反，我們開始建立起更有前瞻性的視角，并積極使用先進工具與更高效的解決辦法。而我從他身上學到的最重要一點，在于讓所有開發者擁有共同的價值觀，是建立和諧團隊與強大代碼庫的關鍵。

我們開發出的應用程序幾乎沒有缺陷，性能非常好、易于擴展，而且能夠在之后的項目中重復使用。從各個方面來看，這都是我在入職以來見證到的最令人振奮的技術成功。

如果這樣的狀況都不能給公司敲響警鐘，那管理層就太失敗了。

如果各位讀者朋友也是那種重視工作、熱愛工作的人，應該也曾被企業內的政治問題折磨得發狂。我懷疑 Gary 也是因為這個才決定離職，因為當時他并沒有跳槽的打算。Mitch 在之后不到一年也選擇離開，同樣沒有什么跳槽計劃。兩位最具才華的員工選擇裸辭，這絕對是個強烈的信號。如果這樣的狀況都不能給公司敲響警鐘，那管理層就太失敗了——或者說，他們已經陷入了更大的問題當中。

Gary 給我的臨別忠告是，“你需要多多表達自己。”回顧我們一起奮斗的那段時間，Gary 和 Mitch 都特別善于表達自己，他們有時候甚至不給我說話的余地。但只要把話筒交給我，我說出來的就一定會是有意義的東西。在他們的引導下，我意識到這確實非常重要。

我必須快速成長，幫助填補他們離去后留下的空白。雖然我的工作績效同樣非常出色，但最終我也離開了這家公司。我在這里度過了一段黃金歲月，也感激這家公司幫助我開啟了職業生涯。但離別終有時，大家沒必要總是強綁在一起。

幾年之后，我仍然在把自己從 Gary 身上學到的價值觀帶到其他崗位上，也努力讓自己成為一個善于表達的人。事實證明，這種價值觀確實讓我在其他公司里也獲得了尊重與廣闊的發展空間。

2. 要點匯總

不知道大家在這個故事里有什么心得，下面我來談談自己的切身感受……

我們很難量化什么才是真正的 10 倍程序員，但這個問題其實沒那么重要

真正重要的，是幫助你身邊的人獲得提升。

有些人可能會爭論某個同事到底是不是真正的 10 倍程序員。這樣的 10 倍到底是在跟誰比？10 倍又具體體現在哪些方面？

不少朋友都有過在一半的要求時間內完成了 4 倍工作量的經歷，在項目中實現了更高的單元測試覆蓋率以及更出色的代碼質量，總體產出可以達到其他初級開發者的 10 倍以上等等。有時候，與具有一定經驗的同行競爭時，您可能也憑借著更少的技術債務或者更強的特定領域專業知識達成了類似的優勢。

但這一切終究會被慢慢抹平，大家會憑借類似的從業經驗、使用相同的工具、基于同一套代碼庫、以相同的理念 / 流程 / 設計模式處理同樣的技術債務。在這樣的前提下，開發者之間的效率仍有區別，但恐怕絕不可能有 10 倍那么夸張。

問題的關鍵并不在于比其他人更強，而是幫助你身邊的人獲得提升。出色的開發者沒有理由用自己的優勢來打擊其他同事，最重要的是為他人提供指導、發現阻礙生產力進步的因素、解決問題并防止其再次發生。這樣，我們就能擁有一支真正有戰斗力的隊伍，而不只是圍繞著一位開發明星原地打轉。

成為專家，還是培養自己的專業性

自滿實際是在沉默當中尋找安全感。

我們不該因為某人出于長久以來的習慣、使用得到廣泛證明的標準與既定技術，并由此以毫無追求的安全方法完成功能實現就對其橫加指責。結合自己的經歷，Gary 當初眼中的我們就像是這樣一群業余愛好者。他不太注意自己的態度，只是他希望整個團隊成長為軟件開發專家的心情完全可以理解。

但請千萬不要忘記，其他人也是人，人總是有著種種缺陷。Gary 也是這樣，他在第 100 次看到同樣的錯誤時肯定要發脾氣；只是這樣的錯誤對其他人來講屬于“正常現象”。失去耐心的同時，你也失去了對同事們應有的尊重，這本身就是對專業性的踐踏。

軟件領域的專業性像是一條微妙的線，我們不能隨時越界，但在看到需要糾正的系統性問題時也不應視而不見。在此期間，你可能會引發混亂、可能會樹敵，甚至威脅到自己的這只飯碗……但自滿實際上是在沉默中尋找安全感。

如果希望改變，請在社交層面找到完美的平衡點。要用心挑選提出建議的契機，更要用心挑選提出建議時的用語。

重視實踐、技術與理念

如果能夠做到，這一切將改變你的職業生涯。

這些東西并不能保證把工作效率提升 10 倍。但我可以保證，只要培養起這樣的能力，您會對軟件開發擁有更加深刻的理解。

• 嚴格遵循 SOLID 設計原則
• 使用 MVC 模式進一步分離關注點
• 命令查詢職責分離
• 通過實時代碼覆蓋工具完成單元測試覆蓋
• 使用行為驅動型開發發現需求細節，同時實現 UI 測試自動化
• 明確定義并強制實施“已確認的定義”
• 代碼質量與分支策略，借此保證源代碼控制系統擁有良好的清潔度與性能
• 擁抱敏捷理念，但不必被動接受 SCRUM 中強調的一切流程

在職業生涯中親身實踐這些目標并不容易，畢竟每個人都已經在成長過程中積累起了自己的一套工作方式。但如果能夠做到，這一切將改變你的職業生涯。

10 倍程序員的背后，可能代表著 10 倍錯誤

這類開發者的根本問題，在于他們的頂頭上司。

公司里還有一位與眾不同的開發者，我們叫他 James。從某種意義上說，他在公司已經擁有相當豐富的資歷，非常擅長處理一部分編程任務。但他不愿意為自己的錯誤負責，經理多次批評還是無濟于事。

最要命的是，其他人的大部分工作都處于 James 團隊開發成果的下游。所以如果他弄錯了，每個人都能感覺到；而如果別人弄錯了，對他幾乎沒有影響。這就是上下游依賴關系的基本特征，要求上游一方必須擁有強大的責任心。

那么，為什么會陷入這么糟糕的狀況呢？因為這位牛仔不相信單元測試，覺得這純粹是在“浪費時間”，但其他人需要為他的武斷買單。此外，他會反復把有問題的代碼（包括無法編譯或者存在嚴重阻塞問題的代碼）添加到其他人正在使用的分支中，搞得公司內部民怨沸騰。

這類開發者的根本問題，在于他們的頂頭上司。這幫管理者沒有建立良好的實踐，甚至把這種獨行俠式的壞習慣視為理所當然。

3. 寫在最后

我覺得這個世界上的 10 倍開發者也分好幾種，有自私型的、有樂于助人型的、有平易近人型的，也有令人生畏型的。如果大家有天分能夠加入 10 倍開發者陣營，希望各位能認真選擇自己想成為哪一種類型。