程序员生存定律[三] 管理向左，技术向右

【软件这个行当的根本特征】

规律是必须顺应而不能改变的，但除此之外现实中还有一些事实也是无法改变的，这两者都很像程序中的常量，想提高人生的高度则需要同时驾驭这两者，而不能试图为两者赋值。下面我们就一起来看一下，软件世界中只能顺应，而不能试图改变的特质有那些。

技术更迭偏快

在学校里，动力机械类专业往往会学习一门叫工程热力学的课程，如果耐心翻阅就会发现虽然封皮换了，但这门课程现在的教科书和五几年的教科书其实差别不大，热力学第一定律还是那个热力学第一定律。

与之相对应《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年后中层管理人员才有存在价值，而一般情形而言这种情况并不会社招，而是会从现有人员中选拔。这最终导致纯管理人员的可流动性并没有想的那么好。

当然什么事情都有例外，如果你是成功运作几个产品的产品经理，那么也可不在流动性上受到限制。因为那些产品就是你最好的名片，他们使你在江湖里有了一席之地。

 

小结

考虑上述三个方面，大多时候可以判明自己是应该做技术还是做管理。比如说：如果一个人日常很容易和人产生冲突，但脑子很好使，也能静下心来钻研技术。这种情形大致上应该努力找一家技术路径长的公司做技术，否则可能会人际关系紧张。而与此相反，一个人如果技术能做的还不错，也愿意与人沟通，同时已经身处一家技术路径不是很长的公司，并不太能够换工作，那么就很可能需要尽早转向管理方向。

总之，别太为了点钱过度难为自己，走不远的话，最终还是吃亏。