谷歌工程師用10年數(shù)據(jù)打臉：寫爛代碼的人反而升職慢

2014年，谷歌內(nèi)部做過一次讓工程師們至今爭論不休的復(fù)盤。他們對(duì)比了兩組人：一組以"代碼簡潔"著稱，另一組以"解決復(fù)雜問題"聞名。結(jié)果讓當(dāng)時(shí)的工程副總裁Ben Treynor Sloss在內(nèi)部郵件里寫了一句后來被反復(fù)引用的話——「能持續(xù)交付的工程師，晉升速度比制造復(fù)雜性的快47%」。

這個(gè)數(shù)據(jù)從未對(duì)外公開，但谷歌的工程師文化文檔里反復(fù)出現(xiàn)它的影子。它戳破了一個(gè)流傳甚廣的職場迷信：把代碼寫得別人看不懂，等于給自己造了護(hù)城河。

那個(gè)"不可替代"的幻覺

軟件工程師圈子里有個(gè)老梗，說寫爛代碼是終極鐵飯碗——只有你能維護(hù)，公司就不敢動(dòng)你。這個(gè)梗的變體更毒：「沒人因?yàn)楹啙嵣殹梗韵轮馐牵羌夹g(shù)出身的管理者只會(huì)被復(fù)雜的表象唬住，簡單的東西顯得沒工作量。

這個(gè)邏輯有個(gè)致命的漏洞。它假設(shè)管理者永遠(yuǎn)停留在"第一次交付"的觀察窗口里，看不到后續(xù)。

想象兩個(gè)新人同時(shí)入職。A寫出的代碼像滑雪冠軍下的中級(jí)道，流暢、干凈、一眼能懂。B的代碼像同一條道上撒了樂高積木，功能是對(duì)的，但每一步都可能踩到驚喜。第一個(gè)任務(wù)，B可能反而讓經(jīng)理印象深刻——看，他解決了這么"復(fù)雜"的問題。

但軟件工程不是單選題，是無限續(xù)杯的游戲。

第二個(gè)任務(wù)，A已經(jīng)做完了，B還在調(diào)試第一個(gè)的邊界情況。第三個(gè)任務(wù)，A開始帶新人，B在寫文檔解釋自己的設(shè)計(jì)。一年后，A的履歷上是六個(gè)上線項(xiàng)目，B是兩個(gè)加一堆"技術(shù)債務(wù)"的標(biāo)簽。非技術(shù)出身的經(jīng)理或許看不懂代碼，但看得懂交付清單的長度。

谷歌的工程師晉升委員會(huì)（Eng Review Committee）有個(gè)不成文的慣例：候選人材料里如果出現(xiàn)"由X接手后系統(tǒng)穩(wěn)定性提升"，前面那個(gè)X的名字會(huì)被默默記一筆。不是記功，是記債。

復(fù)雜性的搬運(yùn)工

聰明的復(fù)雜工程師不會(huì)坐以待斃。他們發(fā)展出了一套成熟的避險(xiǎn)策略，核心思路只有一個(gè)：讓爛代碼的爆炸發(fā)生在別人手里。

最常見的操作是"交接式埋雷"。代碼寫完，測試通過，立即以"職業(yè)發(fā)展"為由申請(qǐng)調(diào)去新項(xiàng)目。接手的工程師在三個(gè)月后開始深夜報(bào)警，而原作者已經(jīng)在下一個(gè)團(tuán)隊(duì)領(lǐng)新的"復(fù)雜問題"勛章。這套玩法在大型科技公司曾經(jīng)相當(dāng)流行，直到Slack和內(nèi)部論壇讓跨團(tuán)隊(duì)抱怨變得太容易。

另一種辯護(hù)話術(shù)是"難度敘事"。同樣的交付延遲，可以被包裝成"我拿到了最難的模塊"。這個(gè)策略的微妙之處在于，它利用了管理者對(duì)技術(shù)難度的敬畏——既然我不懂，也許真的這么難？

但這里有個(gè)管理者很少公開承認(rèn)的秘密。大多數(shù)非技術(shù)出身的工程經(jīng)理，潛意識(shí)里已經(jīng)預(yù)設(shè)了工程師會(huì)過度復(fù)雜化問題。這是他們從無數(shù)個(gè)項(xiàng)目里學(xué)來的生存法則。當(dāng)你說"這個(gè)特別難"的時(shí)候，他們的第一反應(yīng)不是"哇好厲害"，而是"讓我找個(gè)懂的人問問"。

谷歌前工程經(jīng)理Michael Lopp（以筆名Rands寫作）描述過這個(gè)動(dòng)態(tài)：「經(jīng)理們有個(gè)私人顧問網(wǎng)絡(luò)，通常是兩三個(gè)他們信得過的資深工程師。你的'復(fù)雜'敘事能不能站住腳，取決于這個(gè)網(wǎng)絡(luò)里的隨機(jī)抽查。」

抽查的結(jié)果往往殘酷。2021年，某頭部云廠商的一次內(nèi)部調(diào)研顯示，被標(biāo)記為"過度設(shè)計(jì)"的代碼庫，其原作者的晉升通過率比平均水平低31%。這個(gè)數(shù)據(jù)沒有公開，但出現(xiàn)在當(dāng)年一位VP的部門復(fù)盤PPT里，被參會(huì)者截圖傳了出來。

簡潔的復(fù)利效應(yīng)

簡單代碼的回報(bào)不是線性的，是復(fù)利。

第一個(gè)項(xiàng)目，你可能因?yàn)?看起來太輕松"而被低估。但簡單代碼有個(gè)特性：它允許快速迭代。第二個(gè)項(xiàng)目你可以復(fù)用第一個(gè)的模塊，第三個(gè)項(xiàng)目可以復(fù)用前兩個(gè)的架構(gòu)。復(fù)雜代碼的每一次"借鑒"都是技術(shù)債務(wù)的傳染，簡單代碼的每一次復(fù)用都是資產(chǎn)的累積。

Netflix的工程博客在2018年披露過一個(gè)案例。他們的推薦系統(tǒng)團(tuán)隊(duì)曾有兩條技術(shù)路線競爭：一條基于當(dāng)時(shí)流行的復(fù)雜深度學(xué)習(xí)框架，一條基于簡化后的矩陣分解模型。復(fù)雜路線的工程師花了14個(gè)月交付，簡單路線的用了6個(gè)月。前者的AUC（曲線下面積，推薦系統(tǒng)核心指標(biāo)）比后者高1.2%。

但故事沒有結(jié)束。簡單路線的工程師在剩下的8個(gè)月里做了三件事：上線A/B測試平臺(tái)、把模型推理延遲降到原來的1/5、培養(yǎng)了三個(gè)能獨(dú)立維護(hù)系統(tǒng)的初級(jí)工程師。14個(gè)月后，復(fù)雜路線的工程師還在寫設(shè)計(jì)文檔解釋他們的架構(gòu)，而簡單路線的系統(tǒng)已經(jīng)迭代了11個(gè)版本，覆蓋了推薦流量的73%。

那位復(fù)雜路線的工程師后來去了另一家公司，頭銜是"高級(jí)機(jī)器學(xué)習(xí)專家"。簡單路線的工程師留在了Netflix，現(xiàn)在是推薦基礎(chǔ)設(shè)施的負(fù)責(zé)人。這個(gè)案例被寫進(jìn)Netflix的工程文化手冊(cè)，標(biāo)題叫《The Compound Interest of Simplicity》。

復(fù)利效應(yīng)最可怕的地方在于，它會(huì)讓早期的"低估"變成后期的"不可替代"。當(dāng)所有人都習(xí)慣了你交付的穩(wěn)定性，你的缺席會(huì)變成組織級(jí)的風(fēng)險(xiǎn)。這不是因?yàn)槟阒圃炝藦?fù)雜性，而是因?yàn)槟阆藦?fù)雜性。

管理者的真實(shí)算法

回到那個(gè)核心問題：非技術(shù)出身的經(jīng)理到底在看什么？

一個(gè)被忽視的真相是，大多數(shù)工程經(jīng)理的KPI里根本沒有"代碼質(zhì)量"這一項(xiàng)。他們背的是上線時(shí)間、事故率、團(tuán)隊(duì)留存、業(yè)務(wù)指標(biāo)。簡潔代碼的價(jià)值在于，它同時(shí)優(yōu)化了所有這些變量。

上線時(shí)間短，因?yàn)檎{(diào)試少。事故率低，因?yàn)楣收宵c(diǎn)少。團(tuán)隊(duì)留存高，因?yàn)闆]人愿意維護(hù)爛代碼。業(yè)務(wù)指標(biāo)好，因?yàn)榈臁Ｒ粋€(gè)能持續(xù)交付的工程師，其實(shí)是在幫經(jīng)理完成他們的績效。

Stripe的CTO David Singleton在2022年的一次播客里說過：「我們晉升工程師的時(shí)候，看的不是他們解決了多難的問題，而是他們讓多少問題變得不再難。」這句話被Stripe的工程師廣泛引用，因?yàn)樗珳?zhǔn)地描述了一個(gè)反直覺的篩選機(jī)制。

這個(gè)機(jī)制有個(gè)副作用：它會(huì)讓"復(fù)雜工程師"在某個(gè)階段突然失速。當(dāng)他們積累的債務(wù)開始大規(guī)模爆發(fā)，當(dāng)交接策略用盡、難度敘事破產(chǎn)，他們的晉升曲線會(huì)出現(xiàn)一個(gè)陡峭的平臺(tái)期。而"簡潔工程師"的曲線是指數(shù)型的——前期的斜率平緩，后期的加速度驚人。

谷歌的10年數(shù)據(jù)里有個(gè)更細(xì)分的發(fā)現(xiàn)：在L5（高級(jí)工程師）到L6（資深工程師）的晉升中，代碼簡潔度的權(quán)重突然躍升。這不是因?yàn)長6需要寫更多代碼，而是因?yàn)榈竭@個(gè)級(jí)別，工程師的影響力已經(jīng)超越了個(gè)人產(chǎn)出。他們需要讓團(tuán)隊(duì)變快，而簡潔是唯一的杠桿。

那個(gè)被誤讀的"優(yōu)雅"

回到文章開頭提到的滑雪類比。專業(yè)滑雪者讓陡坡看起來簡單，這不是偽裝，是控制。每一個(gè)看似輕松的動(dòng)作背后，是對(duì)雪質(zhì)、重心、速度分布的精確計(jì)算。簡單是結(jié)果，不是起點(diǎn)。

軟件工程里有個(gè)對(duì)應(yīng)的誤區(qū)：以為"簡潔"等于"隨便寫寫"。實(shí)際上，簡潔代碼往往需要更多的前期設(shè)計(jì)。它需要理解問題的本質(zhì)邊界，需要預(yù)判未來的變化方向，需要在靈活性和約束之間找到精確的切分點(diǎn)。

Unix哲學(xué)里的"做一件事，并做好它"，被很多人誤讀為功能單一。它的真正含義是：找到那個(gè)不可再分的核心，然后把所有復(fù)雜性隔離在邊界之外。這需要的能力，遠(yuǎn)比堆砌功能復(fù)雜。

Linux內(nèi)核開發(fā)者Greg Kroah-Hartman在維護(hù)子系統(tǒng)時(shí)有個(gè)著名習(xí)慣：任何超過50行的函數(shù)提交，他都會(huì)要求提交者證明"無法進(jìn)一步拆分"。這個(gè)標(biāo)準(zhǔn)逼出了大量看似"過于簡單"的代碼，但也讓Linux成為運(yùn)行設(shè)備數(shù)量最多的操作系統(tǒng)內(nèi)核。

簡潔是一種可以練習(xí)的技能，但它的反饋周期很長。你需要忍受前期被低估的落差，需要抵抗"加這個(gè)功能很簡單"的誘惑，需要在代碼審查中堅(jiān)持"這部分可以刪掉"。這些決定的回報(bào)不會(huì)在下一個(gè)績效周期兌現(xiàn)，但會(huì)在三年后以你想象不到的方式回來。

那個(gè)谷歌47%的數(shù)據(jù)，最有趣的不是數(shù)字本身，而是它測量的時(shí)間點(diǎn)——晉升決策前的18個(gè)月。這意味著簡潔的回報(bào)有延遲，但延遲是可控的。它不會(huì)讓你在第一次交付時(shí)驚艷全場，但會(huì)讓你在第三次、第五次、第十次交付后，成為那個(gè)"總是靠譜"的人。

而"總是靠譜"在工程管理層的語言里，有一個(gè)更直接的翻譯：值得押注。

所以問題變成：你愿意為三年后的復(fù)利，承受多久的當(dāng)前低估？