程式員生存定律[三] 管理向左，技術向右

【軟體這個行當的根本特征】

規律是必須順應而不能改變的，但除此之外現實中還有一些事實也是無法改變的，這兩者都很像程式中的常量，想提高人生的高度則需要同時駕馭這兩者，而不能試圖為兩者指派。下面我們就一起來看一下，軟體世界中隻能順應，而不能試圖改變的特質有那些。

技術更疊偏快

在學校裡，動力機械類專業往往會學習一門叫工程熱力學的課程，如果耐心翻閱就會發現雖然封皮換了，但這門課程現在的教科書和五幾年的教科書其實差别不大，熱力學第一定律還是那個熱力學第一定律。

與之相對應《C#進階程式設計》這本書在2005年還是第三版，但到2011年已經出到了第七版，頁數則從1027頁增加到了1473頁。

這看着是一個很小的不同，但實際上已經折射出了軟體行業的一個根本特質：技術更疊、增加速度較快。

技術更疊較快說的是這樣一種現象：今天有價值的，明天可能會貶值為0。

在軟體行業裡，你所依賴的某一平台或語言很容易産生更疊。單以Windows平台而論，10幾年前很多人隻有Win32 API好用，但一個人如果隻停留在Win32 API裡，是不太能适應今天的軟體開發的---雖然沒有官方統計，但感受上在今天Web開發、手機終端開發明顯比Windows開發要火熱。

這也許源自于這樣一種現實，很多傳統行業的技能直接依賴于某種自然規律，如：熱力學、流體力學、材料力學等等。這些東西自身隻會深化或細化，比如從牛頓定律到相對論，但很少會有颠覆性變化。但軟體開發所需的東西(API等)往往依賴于某一個公司或組織，比如微軟、蘋果等，進而是一種人造系統。一旦社會基本需求發生變化，這些公司或組織就必需不斷的抛棄并更新自己的系統，比如：GDI -->GDI+ -->WPF。

同時一旦公司因為某種原因倒閉，這一公司所支撐的技術也會變得淹沒無聞。

1995前後開始從事這個行業的人很多都會知道Delphi，但我估計2005後加入這個行業的人就會對這個東西感覺陌生了。我們很難去深究原因，但至少現象上來看，Delphi這樣的開發平台随着Borland一起遠去了。當然，與之一起遠去的還有Delphi世界裡的很多牛人。

極端來講，如果Windows徹底打輸了目前移動終端這場戰争，那麼靠Windows吃飯的人（包括研究Native API的和研究.net framework的）無疑的都有貶值的風險。

可以打一個比方來使這種差異更形象一點：

好比說兩個不同的人，一個在傳統行業一個在軟體行業，兩個人都很勤奮，不停的往自己腳下墊東西，努力使自己達到更高的位置。傳統行業中的人比較自然的會越墊越高，而軟體行業中的人則會墊到一定時候，突然間某幾塊磚就會消失了。

這倒并不意味着軟體行業中并非沒有具有較長生命價值的東西，但這些東西往往集中在一些特定的領域裡，牽涉的從業人員比較少是以不太具有代表性。

具有長久價值的東西裡面最典型的東西是通用資料結構和算法，今天的排序算法在10年後必然同樣具有價值，但專門從事算法優化改良的畢竟是少數。可以講大部分人群還是處在技術更疊的大潮之中。此外，圖形算法、分析設計方法等也具有穩定且長久的價值。形象來講似乎越抽象、越偏向于研究的東西其價值越長久，而越具體、越立刻可用的東西其時效性就越強。 

這一基本特質的影響非常深遠，甚至引出了學習可能會産生較大負效應這類比較特别的問題，這點将在後續内容中陸續有所陳述。

為了讓大家對技術更疊有一個更直覺的印象，我們來看一下袁峰先生所著的《Windows圖形程式設計》的目錄，并看一下這本書裡那些東西在過去的10年裡被更疊掉了，而那些沒有？目錄有點長，但為了能把事情說清楚，我還是把它整個貼出來：

第1章 基本技術和知識 

第2章　Windows圖形系統體系結構 

第3章　GDI／DirectDraw内部資料結構 

第4章 Windows圖形系統窺視 

第5章 圖形裝置抽象 

第6章　坐标空間和變換 

第7章 像素 

第8章　直線和曲線 

第9章 區域 

第10章　位圖基礎 

第11章 進階位圖圖形學 

第12章　用Windows位圖進行圖像處理 

第13章　調色闆 

第14章 字型 

第15章　文本 

第16章　元檔案 

第17章　列印 

第 18章 DirectDraw和 Direct3D立即模式 

如果你仔細觀察，你會發現其中第一章，第四章牽涉的是一些基礎知識，比如Windows 基本結構、如何Hook API等，是以雖然部分内容有點過時，主體上仍然是有現實意義的。

第十章、第十一章、第十二章主要和位圖格式相關，而位圖格式變化不大，是以這幾章的主體部分仍然是有現實意義的。

第十四章主要講的是字型，而Truetype字型即使在今天也是字型的主流，是以也還是有現實意義的。

其他的章節則因為主要是和GDI相關聯大緻上是過時了（不意味着完全沒用），也就是說18個章節裡隻有6個章節還有較大的現實意義。

這本書在國内的出版時間是2002年，到2012年正好是間隔10年，10年時間淘汰了某一類技術差不多80%的内容。不知道還有那個行業會有這種淘汰率。

如果任何人以為書裡被淘汰的那80%的内容容易學，那就錯了，在當年即使是有Windows基礎程式設計知識的人（知道線程、消息機制等）把這部分知識搞通至少也需要1年（工作後）。

介入門檻偏低

某一次喝酒的時候和幾個朋友閑聊，談到了自己的專業：

有的說我是學實體的，和核能有關系。

有的說我是學渦輪機的，這是主要動力機械，發電廠常用。

有的說我是學變壓器的，負責把電送出去。

聽了之後，其中一人大笑，說：你們幾個拼起來就是一個發電站，純屬打入軟體隊伍的雜牌。

雖然看不到具體數字，但就日常感受來看軟體行業中來自其他專業的人似乎确實偏多。這反過來就不成立，你很少聽說學軟體的跑去做數學了。

這背後隐含的是這樣一個事實：軟體行業介入的門檻相對比較低。雖然做到高處，很難講軟體就好做，機械就難做，但從介入壁壘來看，确實是軟體行業偏低。

如果去做動力機械，那麼要學習工程熱力學、傳熱學、材料力學這樣的課程，但如果要做軟體開發，那麼學好一門程式設計語言以及對應的IDE已經可以開始工作了。

當然，後勁不足可能會把不思進取的軟體開發人員限制在某個範圍内，比如說隻能做應用級的開發，最終讓他們等待淘汰。

軟體的這個特質，也導緻了軟體開發人員所特有的一些問題，比如：如果自身沒有突破，那麼很容易就會被海量的後來者趕上。這點的影響也将在後續章節裡陸續提到。

那門檻可以低到什麼程度？

以著名的北大青鳥為例，其公開資料是累計培養了50萬IT人才，均攤到10年裡，這麼一家教育訓練機構每年就可以提供大概5萬人。當然這其中不都是程式員，但從北大青鳥的角色來看，其中的主體部分是程式員。而國内的教育訓練機構則遠不止北大青鳥一家。這是量的視角。

如果你再細心去關注北大青鳥公開出來的故事，你就會發現，聯考落榜者、酒店保安、流水線勞工都在介入這個行業。這裡并沒有一點歧視任何人出身的意思，而隻是想說，這個行業的介入門檻相對比較低。

而同時我們也很難講，隻有做編譯器的、檔案系統、MapReduce的才是程式員。也許有的人做的工作更難，而有的人做的工作則相對容易，但不管怎麼樣，大家确實是屬于同一個行業，都叫程式員。

軟體和軟體差别可以很大

我在《完美軟體開發：方法與邏輯》這本書裡曾經寫過一段有點抽象的話：

從特質上來看，既然軟體是固化的思維，那就必然同時具備思維以及思維所承載之物之特質。

• 思維的特質是指：思維的澄清通常是漸進的，思維自身是不可度量的，思維的主體一定是人，思維通常由概念和邏輯組成，思維的無邊界化（靈活易變）這樣的特質。這部分特質是共通部分，同時屬于所有軟體。

• 思維承載之物之特質是指：當思維的對象是數學的時候，思維本身也就具備了數學的特質；當思維的對象是商業邏輯的時候，思維自身也就具備了商業邏輯的特質。

既然思維自身的特質是複合的，那麼作為固化思維的軟體，其特質必然也是複合的：

既有屬于所有軟體的共同特質，也有特屬于某類軟體，甚至同其他類軟體完全相反的獨有特質。

上述文字主要想強調的是雖然都是軟體但軟體A和軟體B可以有相似部分，但差異可能更大。一個人可能研究OCR算法好幾年最終隻寫幾百行代碼，完全不需要用什麼面相對象和設計模式，但在資訊管理系統中一個人一兩天内可能就需要寫幾百行代碼。這兩者雖然有巨大差異，但實際上都會被稱作軟體。

這種特質導緻了軟體開發所需要的知識日益的分化，最終結果就是不同軟體領域差别很大。想用唯一的知識體系覆寫所有的軟體類别變的非常困難。

對方法論而言，基于這一點最關鍵的一個引申結論是：任何一種方法論不隻要陳述自己的方法，還要陳述自己方法的适用邊界。

對個人發展而言，那就意味着要關注知識的可流動性這類問題。可流動性是說，你在A類軟體中可能達到了一定高度，但如果穿越到了B類軟體的領域中，可能江湖地位會一下子下降很多。

通俗的說法是：男怕入錯行，不同的軟體種類也勉強可以被看做是不同的行業，雖然他們都用一個詞：軟體來概括。

這一特質也帶來很多非常典型的問題，比如：學習必須聚焦。這點的影響也将在後續内容裡陸續提到。

那多内部分野可以多到什麼程度？

要想對多内部分野這一點有個直覺感覺，最直接的方法是去看招聘廣告。

有以語言來區分職位的：.net開發工程師、C++軟體開發工程師、PHP開發工程師、Java工程師等。

有以平台來區分職位的：Android開發工程師、iPhone遊戲軟體開發工程師等。

有以領域來區分職位的：GIS資料工程師、金融項目軟體工程師、電子商務軟體工程師等等。

接下來還會有各種交叉，比如：Java軟體工程師（金融）等。

這裡面未必沒有重疊，但大緻上來講很難在彼此間穿越，年頭越多穿越越難。

如果覺得這個分類不是很系統，那麼可以參照軟體工程中對軟體的分類，再乘上平台和程式設計語言就可以切分出大緻不同的領域：

• 航空電子
• 應用系統
• 指令與控制
• 嵌入式系統
• 微代碼
• Web應用
• 科學研究和工程研究
• 實時系統
• 驅動程式
• 電信軟體
• ... ...

最極端的情形是也不用分什麼軟體種類，一個項目的整個生命周期就能耗盡一個人一生中大部的能量，想嘗試的可以維護個電信或銀行裡的大系統試試。

【管理向左，技術向右】

一個程式員在考慮增值時無法回避的一個根本問題是到底是做技術還是做管理。當然也有些職位會介于兩者之間比如架構師，但我們暫時不去做細分，而是用簡單的二分法。

這種基本方向上的選擇對後續很多細節上的取舍有關鍵影響，是以在考慮其他之前，最好先回答一下這個問題。這就和修煉時要選擇少林、武當、華山還是魔教一樣，一旦選擇，基本上是回不了頭。

當然選擇管理不意味着不需要掌握程式設計技能，畢竟當下大多公司還是信奉“宰相拔于州郡，将軍起于行伍”的。但當技術達到一定水準後，管理還是技術這種方向性的選擇将對下一步做什麼有比較大的影響。在考慮那個方向前，則要先弄清楚管理和技術的關鍵差異。

技術與管理的關鍵差異

到了30幾歲後，轉為管理人員的程式員經常會調侃自己的技術能力：當年解決這種有時出、有時不出的Bug時，我常常在其前後都加幾條調試輸出，這招很管用很可能立刻就把它搞定了。結果多年後維護這代碼的人困惑了，還來問我，這句為啥不能去掉，看着也沒用啊，其實我也不知道，隻能說運氣和人品在程式裡也是很有影響力的。

這是管理人員的一種真實寫照，大家都知道，一旦走上管理崗位，那就和ppt越走越近，和代碼越走越遠了。雖然他仍然要跟蹤最新技術的動向，但他很可能已經無法深究很多技術細節了。

據說微軟這樣的公司推崇一個人要想走上管理崗位，那要先把自己的代碼用遠少于别人的時間寫好，省下來的時間才用來做管理工作。這很好，也不是完全不可能，但大多時候很難，需要很強大的天分，大多數人是做不到的。

主要原因是管理和技術所要處理的問題有根本上的差異。

管理者往往需要處理許多與人相關的事情，這導緻要處理的事情是碎片化的，如果堅持編碼，那麼每天的打斷往往會大幅降低寫代碼的效能，大家都知道編碼是需要專注的。

管理工作總是需要面對大量的瑣碎工作的，比如：老闆對項目不滿要趕緊去說明，免得發酵成大問題；人力缺了要趕緊協調，一是要能要到人，關鍵還得能要到合适的人；工具缺了，要趕緊購買；兄弟們有情緒了，要趕緊安撫；PPQA了有抱怨了，要趕緊改正。如果工作進一步泛化，還要涉及到預算、評估、職業路徑規劃等。

我們很難讓這些事情按照自己的節奏發生，如果管理人員做程式設計，最終這些都會變成一種對程式設計工作的随機性幹擾。是以一般來講很難把它們很好的與編碼結合在一起。想象一下，一個管理人員負責某個項目中影響關鍵路徑的某個子產品，接下來上面所列的意外發生了，那這個管理者怎麼辦？

唱歌的時候常說到Key或者調門這個詞。同樣是《花心》這首歌，周華健的用的Key和原本的沖繩民謠《花》的就不同，這導緻兩首歌聽起來差别就很大，完全不一個感覺。也許可以說管理也是一種技術，但管理和設計編碼這種技術的Key不一樣。做技術需要面對的是程式，程式是講道理的，Stack Overflow時它一定會崩潰；而做管理時需要考慮技術因素，但更需要面對的是各種人，人則隻在一定程度上講道理，是以管理不隻是一種技術。是以基本上可以認為管理和技術時完全不同的兩個方向。

如果大家細心觀察周圍，就會發現，做技術（編碼）的往往可以轉去做管理，但做管理的再轉回做技術（編碼）就難了。這意味着技術背景對做管理往是很有幫助的，而管理背景對做技術則幾乎沒用。

了解到這種差異後，要想做出自己的那份選擇，還需要考慮三件事情：一是既定環境下技術路徑究竟有多長，也就是說做技術有前途麼；一是個人的性格适不适合做管理工作；一是做管理工作可能會有什麼負面影響。這三點将在接下來的三個小節中分别進行探讨。

技術路徑長短對前途的影響

程式員往往自嘲自己是“碼農”，不知道這詞是那裡出來的，但聽起來“碼農”和“農民工”已經有點近似了。而“農民工”往往是收入低，工作時間長的代名詞。這就折射出了一個很尴尬的事實，在很多公司中，單純從收入的角度來看管理職位是要高于純粹的技術崗位的。

這并非是一個絕對規則，前文就曾經提到早在20年前，微軟的超級程式員就可以擁有比管理人員更高的工資，可以擁有多輛保時捷。但在技術路徑短的公司裡，管理人員收入偏高這事情卻具有必然性。

當一個公司的核心技術并沒有創生多大價值，而是需要靠人力規模、商業模式等來支撐業務的時候，那麼我們可以稱之為技術路徑短的公司。想象一下，如果一家公司專門承接本地化工作，那麼也許也會需要程式員編制某些工具，但對程式員而言技術路徑無疑是短的。

如果暫時把眼光從程式的世界移開，那麼事情就可以看得更清楚。

在蓋樓的時候，隻要達到基本的品質，一個人每天砌200塊磚，固然比砌100塊要好的多，但相對于大樓而言，多砌100塊磚，所多帶來的價值有限。再進一步由于砌每塊磚的價值是固定的，同時一個人每天所能砌的磚也是有限度的，這就會導緻砌磚勞工，不管多麼努力，其收入水準必然會被限制到某一個較低的水準，隻要他的工作還隻是砌磚。這種限度是由這一工作的内涵所決定的，倒不是誰遭到了歧視。

再類比到軟體行業裡，單純的在既定接口下實作已定義的業務邏輯就是技術路徑比較短的工作，是體力密集型的；而分析業務邏輯，控制整體架構或者去研究TTS的算法則是智力密集型的，技術路徑較長。

在選擇方向時關鍵要避免的是選擇了技術方向，但身處的現實中技術方向卻路徑較短，或者喜歡管理但跑到了純粹技術流的公司裡，這種選擇其内部所蘊含的沖突會給當事人的人生造成極大的困擾。比如說開發小型資訊管理系統時，其所需要的技術含量并不高，公司的主營如果是這個，單純的做技術可能會直接影響收入。這是一個需要考慮的很現實的事情。

什麼樣的程式員适合轉管理

《黑客帝國》的卡通片中有一集叫做“Matriculated”，在這一集裡有個機器人被逮住後，人類通過各種場景讓他相信自己是個人類，計劃看似成功了，但實際卻不是。這個動畫的啟示意義在于，先天帶來的很多東西，比如性格等實在很難改變，更多時候選擇順應自己的天性比選擇對抗更加明智。

從先天性格來看，确實有的人天生适合做管理多一點，有的人天生适合做技術多一點。

比如說：

有的程式員天生有點被動，不喜歡主動學習很多東西，不喜歡與人溝通，但對工作所直接關聯的領域研究較深，做事情兢兢業業，一絲不苟。

有的程式員非常聰明，了解東西很快，但不願意搭理别人，總感覺别人水準比較差，脾氣也比較暴躁。

有的程式員精力充沛，對技術狂熱，但并不僅局限于技術本身，有大局觀，有理想，能堅持。

單從性格而論前兩者都不太适合做管理工作的，一旦做了管理工作，接觸各種性格的人，容易造成人際關系緊張，反倒對自己形成一定的壓力，極端情形下就會精神失常。

單純的因為收入而選擇管理工作，并不總是明智的，你可能無法适應，反倒導緻事業出現起伏---不要低估這點的影響，現實中非常多的人因為這種錯位而使人生走入低谷，甚至生病。

在大五模型裡用五個因素來考察人格特質：

外傾性（extroversion):

外傾者者傾向于喜歡群居，善于社交和自我決斷。内傾者則比較内向，膽小害羞，安靜少語。

随和性（agreeableness）:

高随和性的人是合作的，熱情的和信賴他人的，低随和性的人是冷淡的，敵對的和不受歡迎的。

責任心(conscientiousness):

高責任心的人是負責的，有條不紊的，值得信賴的，持之以恒的。低責任心的人則容易精力分散，缺乏規劃性，且不可信賴。

情緒穩定性(emotional stability):

積極的情緒穩定性者傾向于平和，自信；而消極情緒穩定性者（神經質的人）傾向于緊張，焦慮，失望和缺乏安全感。

經驗開放性(Openness to experience):

開放性高的人富有創造性，凡事好奇，具有藝術的敏感性；開放性低的人則保守對熟悉的事物感到舒适和滿足。

總的來看，外傾性和經驗開放性好的人更适合走上管理崗位。

千萬不要忽視這種錯位的力量。金山的求伯君先生就直承自己不擅長做管理。他認為人的一生之中最關鍵的是對自己能夠有所了解，不是說自己什麼都能幹，是萬能的。在雷軍走後的4年裡，做CEO有些力不從心，快50歲的他精神壓力太大，多次想退休，請雷軍出山。最終求伯君先生在不到50歲的時候退出江湖，不知道是不是和這個有關。

當然很多人可能遠走不到求伯君先生的高度，但終究類似，可以打個比方形容錯位的中層管理者。上司和下屬員工像兩塊闆子，管理這門功夫沒練好的話，中層管理者就被搓球了：上司說，你做的這叫什麼事兒，腦子大大的壞了。下屬說：你瞎答應什麼，這事兒怎麼做，我不幹，要幹你自己幹，愛咋咋地。

管理這功夫練好了，情形就變了：上司尊重你的意見，下屬把你視為旗幟。一處天堂，一處地獄，核心差别其實不大，根本還在天生的人格特質。待管理人群的特質也很有影響，但這是運氣所管理的範疇。

是不是适合做管理者的簡明判斷方法

假設說團隊裡兩個兄弟吵起來來了，你願不願意去調解？

假如有一個人脾氣很壞你願不願意和他溝通，即使你不喜歡？

假如有一個人問題很多，你願不願意面對面批評他？

假如有一個人屢教不改，你願不願意采取直接的懲罰措施，那怕關系緊張？

這個清單還可以增長。一旦做管理工作，這類需要抛開個人視角，而從組織的視角去看待問題并行動的地方很多。

如果對這類問題的回答是否定的，那麼最好是不要往管理的方向上走。

上面這幾個問題，純走技術道路的還可以作壁上觀，但如果是發生在自己團隊裡，管理者卻保持逃避的态度，那麼管理者就失職了。

由于人的世界很複雜，是以期望壞的事情一件也不發生，那是不現實的。我個人感覺管理者面對這類事情的幾率是100%，差別是遇到多少件，而不是遇不遇得到。

其實故事到這裡還沒完，如果往深了考察，就會發現，即使一個人願意去搞定吵架中的兩個人，那還有你怎麼去搞定，搞不搞得定的問題。

搗糨糊、各打五十大闆這類簡單粗暴的方法往往隻能有效于一時，等價于埋下定時炸彈，長線來看不是什麼高明方法。但把這個展開就需要另外一本書，這裡就不進行展開了。

管理工作的負效應

從日常很多人發表的言論來看，管理工作似乎被無限美化了，很多人都認為管理工作似乎是一條徹底金光大道，但這并不完全正确。為了讓事情回歸本來面目，這裡說一點管理方所可能帶來的負效應。

同純技術工作相比，管理工作（特别是中層管理）的可流動性可能會非常低，形象來講很多公司并不會願意請外來的中層管理者來管理已有的員工，而更願意請技術上有專長的人來解決具體的問題。這是由管理工作的幾個特質所決定的：

管理工作和人打交道比較多，是以對人員的特質有很強的依賴性。如果一個團隊的人都非常像機器人，那麼在不同公司間管理技能是完全通用的---隻要有PMP，CMMI這類東西就夠了。但關鍵問題是人員的特性是多樣的，這導緻管理人員和被管理人員需要較多的磨合和适應。形象點講就是，如果無法搞定特定人群，你考5個PMP證書，該不管用還是不管用。

同時長時間在管理崗位的話，即使是做技術出身，技術能力也會退化，溝通技能、與上級的信任程度反倒會提高。而這些東西，到一家新公司後，一定會被歸零，，其價值并不明顯。反倒不如擅長算法，擅長某類業務的技術人員可流動性好。

這也就意味着，管理人員往往與公司的利益綁定的更緊。尤其是中層管理人員，達到一定年紀後（比如：40歲），很可能會失去流動的可能性，一旦所處的公司出現問題，那就可能會面臨非常尴尬的局面---直接講就是，如果你選擇了管理方向，卻缺乏相應的人脈，35歲之後基本不具備可流動性，換工作會很難，至少比純技術的高端人員難。

這點的一個旁證是各個初創期公司的人員構成。如果你用心觀察就會發現對于初創期的公司而言，它需要創始人把握方向和尋找資金，也需要工程師來完成具體事務，但不太需要中層管理人員。比如：Pinterest曾經公開了自己的資料，在2010年是2個創始人，1個工程師；2011是3個工程師；2012年是6個工程師；2013年是40個工程師。這種情況下，隻有到2013年後中層管理人員才有存在價值，而一般情形而言這種情況并不會社招，而是會從現有人員中選拔。這最終導緻純管理人員的可流動性并沒有想的那麼好。

當然什麼事情都有例外，如果你是成功運作幾個産品的産品經理，那麼也可不在流動性上受到限制。因為那些産品就是你最好的名片，他們使你在江湖裡有了一席之地。

小結

考慮上述三個方面，大多時候可以判明自己是應該做技術還是做管理。比如說：如果一個人日常很容易和人産生沖突，但腦子很好使，也能靜下心來鑽研技術。這種情形大緻上應該努力找一家技術路徑長的公司做技術，否則可能會人際關系緊張。而與此相反，一個人如果技術能做的還不錯，也願意與人溝通，同時已經身處一家技術路徑不是很長的公司，并不太能夠換工作，那麼就很可能需要盡早轉向管理方向。

總之，别太為了點錢過度難為自己，走不遠的話，最終還是吃虧。