本文作者：余晟，微信公眾號：余晟以為（yurii-says）
技術(shù)領(lǐng)導(dǎo)要不要寫代碼？這是一個問題。

我剛工作的時候就聽說，程序員（那時候還沒有“碼農(nóng)”的說法）是 吃青春飯的，到30歲就熬不了夜寫不動代碼了，所以要盡早轉(zhuǎn)管理崗。相應(yīng)的，如果你走上管理路線成了技術(shù)領(lǐng)導(dǎo)，自然就不必干寫代碼這種低級重復(fù)的體力勞動 了。所以當(dāng)時自己代碼寫得很多，技術(shù)能力增長很快，但總感覺有點(diǎn)別扭。那感覺就像，你能把車開得又快又熟練，最終只是為了能按時到達(dá)機(jī)場趕上飛機(jī)。然后， 你就再也不用開車了。

不過無論如何，趕上飛機(jī)看來是更高級的選擇，為了它，放棄苦心修煉的車技也可以接受罷。但是等我真正走上管理崗位，才發(fā)現(xiàn)事實(shí)和我想的完全不一樣。

當(dāng) 時公司的業(yè)務(wù)增長飛快，支持業(yè)務(wù)的系統(tǒng)卻是幾年前“一錘子買賣”的外包項(xiàng)目，更要命的是技術(shù)團(tuán)隊(duì)的人員組成和工作習(xí)慣還處在作坊狀態(tài)。從我的角度來看，四 下里全是大坑，填坑的速度慢得讓人著急，在此過程中還經(jīng)常挖下新坑…… 在我的職業(yè)生涯中，我從沒有在那么短的時間里寫過那么多代碼。幾年后大家查提交排名，我的名字仍然第一。好在我的努力沒有白費(fèi)，系統(tǒng)終于沒有垮掉，順利回 到正軌。

當(dāng)時我身為技術(shù)領(lǐng)導(dǎo)，除去招人、定流程、做運(yùn)維，還花了大量時間寫代碼，這樣的做法是對的嗎？如果是對的，后來我再沒有寫過那么多代碼，好像也與“不稱職的領(lǐng)導(dǎo)”無緣，甚至還被夸獎過“忍住放手讓下屬去做事，鍛煉了組織”，這又是怎么回事呢？

很長時間里我都在思考這個問題，發(fā)現(xiàn)大家的說法也大不相同。有人言之鑿鑿“不寫代碼的好領(lǐng)導(dǎo)不是好領(lǐng)導(dǎo)，因?yàn)橹挥凶约簩懙拇a才心里有底”，也有人斬釘截鐵“當(dāng)了領(lǐng)導(dǎo)還寫代碼是對不起公司，公司發(fā)給你領(lǐng)導(dǎo)的工資不是讓你敲代碼的”。

大家的觀點(diǎn)水火不容，所以或許這個事情并沒有統(tǒng)一的答案，只有回到具體問題才有答案。我能確定的是，在我當(dāng)時所處的情況下，自己不寫代碼系統(tǒng)肯定會癱瘓。但是跳出來看，又不能說“領(lǐng)導(dǎo)要寫代碼”就是放之四海而皆準(zhǔn)的。所以只能具體問題具體分析，下面說說我的“具體”看法。

首先要確信的是，寫代碼不是丟臉的事情

為了心平氣和地理性討論，我們應(yīng)當(dāng)摒棄那些天然帶有強(qiáng)力感情色彩的詞語，比如“碼農(nóng)”，同樣也要注意摘掉其它的有色眼鏡。在我們所處的時代，再復(fù)雜的算法，再精妙的系統(tǒng)，也必須輸入一行行代碼來實(shí)現(xiàn)的。這就好比寫文章，文筆再好的人，也得自己一個一個字地把文章敲出來。

其 實(shí)這個比喻還不是那么合適，敲鍵盤是個“標(biāo)準(zhǔn)化”的過程，不存在“打字質(zhì)量”的問題。寫代碼更像“創(chuàng)意”，比如多個程序，有同樣的輸入和同樣的輸出，但是 這些程序到底能應(yīng)付多少異常情況，有多么穩(wěn)定，效率差多少倍，離開代碼是很難發(fā)現(xiàn)的。正因?yàn)槌绦虻馁|(zhì)量很大程度上取決于代碼的實(shí)現(xiàn)，所以寫代碼是必須的工 作環(huán)節(jié)，寫好的代碼更是非常值得追求的目標(biāo)。

其次，技術(shù)領(lǐng)導(dǎo)不是什么“高人一等”的角色

軟 件的“軟”就在于它是看不見摸不著的，很多時候不能從現(xiàn)實(shí)生活中照搬模型，只能靠思維和經(jīng)驗(yàn)去把握。技術(shù)領(lǐng)導(dǎo)肩負(fù)著更大的職責(zé)，就應(yīng)當(dāng)有更深厚的經(jīng)驗(yàn)與更 嚴(yán)密的思維，才能保證軟件開發(fā)的效果。單薄的專業(yè)經(jīng)驗(yàn)加上發(fā)號施令的權(quán)力，這樣的組合在其它行業(yè)或許能當(dāng)領(lǐng)導(dǎo)，但在軟件開發(fā)行業(yè)充其量只能誕生不稱職的技 術(shù)領(lǐng)導(dǎo)。埃里克·施密特在《How Google Works》里面寫道，Google需要的是既有領(lǐng)導(dǎo)才能又有自己實(shí)現(xiàn)能力的“創(chuàng)意精英”，我也覺得這種人是技術(shù)領(lǐng)導(dǎo)的最佳人選。

既然“寫代碼”不丟臉，“技術(shù)領(lǐng)導(dǎo)”也非高人一等，也就沒有必要把兩者對立起來。所以我們不妨放寬視界看看更要緊的問題。

技術(shù)領(lǐng)導(dǎo)這個角色，究竟應(yīng)當(dāng)干什么？

可以肯定的是，技術(shù)領(lǐng)導(dǎo)領(lǐng)導(dǎo)的是技術(shù)團(tuán)隊(duì)，所以要對整個技術(shù)團(tuán)隊(duì)的工作負(fù)責(zé)。下面我們用簡單的模型來分析技術(shù)團(tuán)隊(duì)的工作。

A是很不錯的程序員，寫代碼速度是2，是普通程序員的2倍，代碼質(zhì)量是1.5，是普通程序員的1.5倍。他對自己的狀態(tài)比較滿意，認(rèn)為“搞開發(fā)就得是這樣”。確實(shí)，他的生產(chǎn)率是普通程序員的3倍（2×1.5），他也確實(shí)很棒。

A的表現(xiàn)獲得上級的肯定，于是升任技術(shù)領(lǐng)導(dǎo)，領(lǐng)導(dǎo)3個普通程序員開發(fā)程序。如果大家的工作都保持不變，那么團(tuán)隊(duì)生產(chǎn)率是 2×1.5 + 1×1×3 = 6。

但是A升任領(lǐng)導(dǎo)之后，必然要花很多時間去做寫代碼之外的事情，不再保持“個人貢獻(xiàn)者”的角色。我們假設(shè)他花了一半的時間去做其它事情，而代碼質(zhì)量保持不變，那么他的生產(chǎn)率降低為 (2×0.5)×1.5 = 1.5，A的生產(chǎn)率下降了很多。

A應(yīng)當(dāng)記住，現(xiàn)在自己不是“個人貢獻(xiàn)者”了，所以應(yīng)當(dāng)關(guān)心團(tuán)隊(duì)的生產(chǎn)率。如果團(tuán)隊(duì)的生產(chǎn)率不變，那么整個團(tuán)隊(duì)的是(2×0.5)×1.5 + 1×1×3 = 4.5。這幾乎是最壞的情況，技術(shù)領(lǐng)導(dǎo)被瑣事纏身無法做出貢獻(xiàn)，團(tuán)隊(duì)的生產(chǎn)效率因此降低。

但是，如果A再減少自己寫代碼的時間到0.8，把省下來的時間用于制定開發(fā)規(guī)范、砍掉不合理需求、搞活團(tuán)隊(duì)氣氛等等，情況就會不一樣了。假設(shè)A的一系列安排，讓其他3個程序員的寫代碼速度提高到1.3，代碼質(zhì)量提高到1.3。

對 很多技術(shù)出身的技術(shù)領(lǐng)導(dǎo)來說，這種狀態(tài)往往不讓人滿意，因?yàn)榭床簧掀渌绦騿T寫的代碼，總歸要自己寫才放心。但是，這時候團(tuán)隊(duì)的生產(chǎn)效率卻變成了 0.8×1.5 + 1.3×1.3×3 = 6.27，反而高于最初的6.0。團(tuán)隊(duì)生產(chǎn)率的提高正是公司對領(lǐng)導(dǎo)者的期望與考核標(biāo)準(zhǔn)。所以這個技術(shù)領(lǐng)導(dǎo)或許自己不滿意，卻是稱職的。

這個道理我之前在《領(lǐng)導(dǎo)的對象，是人還是任務(wù)》中講過。領(lǐng)導(dǎo)的對象既不是單純的人也不是單純的任務(wù)，而是以人為媒介，驅(qū)動團(tuán)隊(duì)成員去完成更復(fù)雜的任務(wù)。

所以如果你是程序員出身的技術(shù)領(lǐng)導(dǎo)，一定要區(qū)分“自己”和“團(tuán)隊(duì)”，你要考慮的不是怎么讓自己寫得更快更好，而是怎么讓大家都寫得更快更好。只要你能持續(xù)提升整個團(tuán)隊(duì)的生產(chǎn)效率，你就是稱職的，哪怕“看不上”其他人的代碼，也得忍住。

在 上面的例子里，如果你能把剩下3個程序員寫代碼的速度都提升到1.5，代碼質(zhì)量都提高到1.4，總生產(chǎn)率就有 1.5×1.4×3 = 6.3。這時候技術(shù)領(lǐng)導(dǎo)一行代碼也不寫，而且下屬寫代碼的水平仍然趕不上自己，團(tuán)隊(duì)的生產(chǎn)率提高卻是板上釘釘?shù)氖聦?shí)——當(dāng)然你還有其他辦法，比如優(yōu)化人員 組合引入用生產(chǎn)率與自己相同甚至比自己更高的程序員，這樣的效率更高了。

當(dāng)然，“一行代碼也不寫”多半是理想情況， 許多時候技術(shù)領(lǐng)導(dǎo)還是必須要寫代碼的，因?yàn)檐浖_發(fā)終究是手藝活，大家認(rèn)同的也是手藝。所以很可能會出現(xiàn)下面的情況：團(tuán)隊(duì)很缺某方面的開發(fā)經(jīng)驗(yàn)或能力，除 了技術(shù)領(lǐng)導(dǎo)之外暫時沒人能對付；或者某個程序員不服氣或者不理解某個決定，不能用頭銜而只能用代碼來說服和闡釋……

除 了這些“必須”的情況，我也主張技術(shù)領(lǐng)導(dǎo)“應(yīng)當(dāng)”寫寫代碼。軟件開發(fā)這個行業(yè)還太年輕，層級隔離做不到那么好，只說不寫是找不到感覺的，而很多技術(shù)決策的 依據(jù)正是這種感覺。所以我每次接手新的項(xiàng)目和團(tuán)隊(duì)，通常都要把代碼全都看一遍心里才有底，自己提交幾個功能才算找到了感覺。

這樣看來，“技術(shù)領(lǐng)導(dǎo)要不要寫代碼”這個問題沒有統(tǒng)一的答案。所以有時候你不得不忍住“讓我來寫”的沖動，有時候你又不得不忍住惡心親自動手。

就我個人而言，我覺得寫代碼而且不愿意放棄寫代碼能力的技術(shù)領(lǐng)導(dǎo)更可愛。程序員大多是單純的，一起寫代碼，哪怕只寫幾個功能，也會告訴大家“我不是來發(fā)號施令的，而跟你們一伙的”。