IT外企那点儿事(5-7)

IT外企那点儿事(5)：像系统一样升级
进行完入职培训，便开启了你在外企中的程序人生了，需要说明的是，此文章不仅限外企。

如果待足够长的时间，你将从程序员，高级程序员，team lead，一直到manager，甚至director。

我们姑且宏观审视一下此过程，然后再品味一个个细节。

然而审视的过程猛然发现，所谓程序员就是把自己作为程序的人。

《道德经》第四十二章：道生一，一生二，二生三，三生万物。

此句大概说明的是宇宙万物发展变化的过程，而道则为宇宙万物运行的规律。

万事万物都有自身的规律，万有引力是规律，相对论是规律，而天天陪伴在我们程序员身边的算法，操作系统，计算机组成等，也可以看成大自然众多规律中的一小部分，也只有掌握好这些规律，我们才能掌控好计算机的运行。

系统的开发，程序员的升级又何尝不是经历了这样一个过程呢？

一、认识规律：道
做一个系统，首先要掌握此项目所需要的技术，如果相关技术没有使用过，则此项技术就是一门尚未认知的规律。在项目开始之前，必须要系统性的认知相关的技术，否则面临较大的风险。

做一个程序员，首先要掌握计算机方面的知识，对知识的掌握，同样需要系统性，否则职业生涯也会面临很大的困难。

系统性在此阶段至关重要。

如果在项目中，对相关的技术没有系统性的认识，则会造成以下后果：

设计出的系统不具有扩展性
应用了笨拙的方式设计程序
出现Bug时无所适从
不知道大家是否参加过这样的项目开发过程，由于时间紧任务重，项目组在没有一个人系统了解某项技术的时候就进行了开发，大家只好从网上下载一些Sample code来通过复制粘贴来拼凑程序，甚至连每一项配置或每一行代码都没搞清楚，就照猫画虎的拿过来用了，这样不但到了后期，系统几乎没有任何扩展性，并且任何不同于Sample code的灵活的改动都是一件十分痛苦的事情，项目组就像眉头苍蝇一样四处乱改乱闯，但并不清楚每一次改动的真正后果，这样要进行大量的尝试和返工，最后整的整个项目组很累，还没有效果，这个过程我称之为“盲试”，也即在不明白原理的情况下靠反复的体力劳动，逐一遍历所有自己认为可能的修改。

“盲试”是初入职场的程序员经常犯的错误，初入职场，信心百倍，情绪高涨，急于出成果是多数时候的心态，当一个任务下达到手中的时候，并不是系统的阅读文档，进行方案评估以及框架设计(这些其实都是磨刀不误砍柴工的事情)，而是急着上手来做，可能在项目的早期，能够很快的出效果，但是随着项目的进行，维护成本越来越大，经常加班，而效果甚微。而对有经验的程序员来讲，前期进行了良好的设计，后期添加模块，需求的灵活变动是相对轻松的事情。

其实也可以理解这种状况的出现，毕竟老板都是心狠手辣的，才不会给你那么多事件做调研，程序员总是有一种被皮鞭赶着走的感觉，从而根本无法系统性的掌握技术和框架设计。这也是面试了很多程序员，每每都号称做过A,B,C项目，分别应用了a,b,c的技术，然而往深入问的时候发现，他们对技术a,b,c的了解也就仅限于A,B,C项目中，对其他一无所知了。

没有系统性的认识技术，则可能写出很多笨拙的程序，丑陋的实现。因为你只知其一，不知其二，只知其然，不知其所以然，本来人家框架中有高效的现成的技术实现这一方面的功能，你不知道，于是根据自己了解的片面技术勉强拼凑成功能，自然也实现了效果，然而当自己开始看这方面的经典书籍的时候，不禁感慨：“咳，原来能够很简单搞定的，当时竟然笨笨的写N多的代码。”

没有系统性的认识技术，出现Bug的时候比添加新模块更痛苦，因为不明白原理，所以只能从表面现象去猜，然后又是进行“盲试”的过程。

因而对技术的系统性认识，实在是不但对项目负责，更是对自己负责的一件事情。如果老板是技术型的，在估计项目时间的时候，应该劝说其将这方面考虑进去，如果老板是非技术型的，则程序员也应该自己留下缓冲时间。不然你辛辛苦苦白天八小时给老板了，晚上再加班几个小时又给老板了，你自己如何进步呢？

如果对于程序员，对计算机方面的技术没有系统性的认识，同样存在上述的问题。

你的职业生涯同样没有扩展性。如果不能够系统的掌握算法，数据结构，操作系统，计算机网络，计算机组成等基础知识，在程序员的初期可能不明显，随便培训培训也能写出不错的程序，然而当转换方向或者平台的时候，会面临很大的痛苦。而我们能够看到的身边的优秀程序员们，无论让他们做C,C++还是Java，无论是linux还是windows，他们都能够很快的上手，是因为基础好的缘故。

项目和程序员认识规律的方式，其实也无非读书，文档，及原型开发(对于程序员来说，实习阶段相当于Prototyping)。

总结：项目或程序员的第一阶段：悟道，关键词：“系统性”

二、道生一
当掌握了项目相关的道，也即技术的时候，就要真正的进入项目开发了。

当前的项目，仍然由一个进程组成的系统比较少了，由于数据量的增大，基本都会开发多节点的分布式系统，然而再复杂的系统，也基本是从单节点系统开始做的，也即所谓道生一的过程。

当掌握了计算机相关技术的时候，你就可以成为一个真正的程序员了。当然不可能让你一开始就管理一个项目组，此时唯一要管理好的，是你自己。

开放性和扎实性是此阶段的重中之重。

对于项目来讲，一个好的单节点系统，所谓开放，就是即便设计单节点的系统，也要站在设计多节点的系统的角度来考虑，使做出来的系统更加容易被扩展成多节点的系统。所谓扎实，就是单节点系统要麻雀虽小，五脏俱全，扎扎实实的实现大部分功能，并有相当量的测试用例来保证功能的正确。

否则会造成以下后果：

当做多节点系统时候，发现单节点系统需要大量修改，甚至等于白做，重新开始。
单节点不稳定，以至于多节点时Bug丛生，但不知道是因为错误出在多节点实现部分，还是单节点部分，较难定位。
没有足够的测试用例，当为了多节点进行修改的时候，不能保证的功能实现仍然行为正确。
假设做一个100个节点的项目，要100天时间的话，并非每个节点要1天的时间，而是第一个节点就需要30天的时间，当第一个节点做好之后，扩展后面是很自然的事情，然而如果第一个节点做不好，每天都做一个节点，每天都把昨天做的设计推翻然后重做，怕是100天也完不成100个节点。这个例子比较极端，然而在我们周围没有发生过吗？

对于程序员来讲，做一个好的螺丝钉，同样需要开放和扎实。

所谓开放，就是我们虽然仅仅是最最低级的员工，可能整个系统的架构根本轮不到我们，但是这并不表明我们只盯着自己的一亩三分地，完成功能了事，而是要经常站在整个项目的角度考虑问题。不想当将军的士兵不是好士兵，建议做一下几件事情：

在项目的各种会议上，经常站在项目经理和架构师的角度考虑问题，要是自己会如何设计，前辈们为何这样设计，然后多问前辈问题。虽然最初的想法比较幼稚，但可以不说出来，但是长时间这样思考，会发现自己的设计水平会突飞猛进的，慢慢的，你会发现你能够在会议中给出一些建议，然后你会发现能够发现前辈设计中的一些缺陷，然后你会发现你能够对当前的设计提供恰当的改进方案，终于有一天你发现你不再是一个单节点的普通程序员了。
除了完成自己的功能外，多看一看前辈们实现过的代码，用自己的方式手绘一些他们的架构图，记下不太明白的部分及觉得很优秀可以借鉴的部分。
尝试在自己的模块中(可能最初是很小很小的模块)尝试使用学到架构。
可以重读或新读一些经典书籍，争取能够用业界内公认的理论来解释自己接触到的设计及架构，使得从感性认识上升到理性认识。比如原来前辈们写这些类，用的是这种设计模式，它还有以下的优点和缺点，适合设计怎么样的系统。这样不但有利于我们在以后的项目中恰当的使用已掌握的设计，而且也有利于向他人准确的描述项目。试想在面试中，一个专业术语要比杂七杂八的列一大筐类更显水平吧。
可以在餐桌上，向自己的同学，朋友描述一下学到的架构，让你的朋友往细节里问，不确定的回去再下功夫，争取做到虽然你只是项目中的一个螺丝钉，但是好像你从头到尾设计了这个系统一样。
这里要提醒一下大家，并不是所有的上司都喜欢要当将军的士兵和老问问题的员工，适当把握火候吧。

所谓扎实，就是指对接触到的知识，都应该根据实践，结合理论，由点到面的掌握。在这个阶段，信息量是很大，要学的东西很多，往往对各种技术都接触一下，又对各种技术都浅尝辄止，最后形成样样通，样样松的局面，阻碍了自己的发展。面试的时候也经常发现一些应试者，掌握的东西仅仅局限于他做过的那个点上，相关知识的掌握非常弱，这自然会影响他从一个单节点程序员向多节点发展。因而每当在项目中接触到一方面的东西，除了上班完成项目外，下班后多看一些有关此方面的书，博客等，使得从知识点变成知识面，知其然，还要知其所以然，并了解存在的问题。当白天在MFC中拖完控件后，总应该读一些《深入浅出MFC》来了解其机制，读一下《windows核心编程》了解一下windows API及一些原理，最好读一下《windows internals》了解一下原理背后的故事，不然面试的时候如何向别人开口做过windows下的程序设计呢？总不能够创建过socket对象就声称会socket编程吧，至少看一下《UNIX Network Programming》。用过NFS怎么不把linux的filesystem的机制了解一下呢？

当然这样是很累很费时间的，然而刚毕业的我们，没有经验，没有人脉，没有资金，有的不就是时间吗？

珍惜刚毕业的这几年多多打实一下基础，等年纪大了，精力没这么旺盛了，很多事情要照顾了，还要靠这时候的老本啊。

总结：项目或程序员的第二阶段：道生一，关键词：“开放性”“扎实性”

三、一生二
对于项目来讲，当单节点系统足够稳定的时候，是应该向client/server或者master/slave结果扩展的时候了，也即一生二的过程。

对于程序员来讲，当你已经足够胜任个人工作的时候，是可以带一个实习生或者初级程序员了。

此步的关键即"communication"，沟通。

对于系统来讲，主要考虑的应该是节点之间如何通信，如何协作，采取何种协议。

通信可以是面向连接的，也可以是不面向连接的。可以是同步的，也可以是异步的。
通信是分层次的，不同的情况应用不同层次的协议，heartbeat用何种协议，内部数据块传输用何种协议，发布成service向外提供服务用何种协议，都是应该考虑的。
数据的内部结构就想接口一样是要通过沟通商定的，便于解析又易于扩展，rpc? serialized object? xml? json? protocol buffer? 还是自己定义的格式？
对于要经常访问的客户端，连接池是必须的，每次建立连接是很耗时的
服务器端应该有对连接总数的限制，以及请求的分发，拥塞控制(并不一定是网络拥塞，而是某个阶段的处理相对较慢)
通信模块在项目中不应该是任何两个需要通信的模块都要开发的，而是应该作为基础性模块，经过大量的测试后达到稳定，使得需要应用通信模块的人员能够集中精力在本身的逻辑上，当模块间协作出现故障的时候，不用担心是通信模块传错了的问题。
对于程序员来讲，同样要考虑和实习生或初级程序员之间的通信协议问题。

有的代码自己觉得写的很清楚，但是让新手上手的时候，如何能够准确的描述你的思路，想法，设计，遇到的困难呢？如何根据对方的反馈确认对方真实了解了你所表达的信息呢？有很多有经验的程序员，由于天天面对着电脑而疏于和人的沟通，可能会一肚子能耐却说不出来，非常可惜；而对于新人，他的回馈是懂了可并不一定代表他真的懂了，也可能是不懂又不敢说。

重要的问题的沟通应该是同步的，也即面对面沟通，这样除了语言上的反馈，还能通过表情得到一定的反馈。任何问题都要事先划分为若干阶段，最好脑子中有张拓扑图，后一阶段的理解会依赖于前一阶段的理解，一股脑把所有的信息放在对方面前，任何人都会晕。每经历一个阶段，都要收集一次反馈，作为信息的发送方，可以通过事先准备一些关键点的问题来检测对方是否真正了解，作为接收方，可以通过"你的意思是说。。。"等以自己的方式重复对方的表达来进行反馈。
注意拥塞控制，每一次的讨论争取一个小时内完成，再长效果会下降，接受者感觉信息被塞了满满一脑子，没有头绪，难有清晰的思路了。
每次沟通都应该至少有会议记录和部分结论，不然讨论等于白讨论，否则会发生团队经常开会，但是总在讨论同样一些问题，感觉上好像每次都在头脑风暴，其实效率很差。
对于重要的结论应该是面向连接的，也即书面(邮件，文档，wiki)告知，并有书面回复(ok, I am following the bug XXX)。
可以建立一些连接池，也即沟通的特定上下文。经过一定时间的团队磨合，可以下意识的创造或达成共识的一些词汇来代替一定的上下文，可以提高沟通效率。比如"明天甲系统出report"，则程序员明白要有单元测试覆盖率报告，QA明白要有当前bug的报告，性能测试组应该有甲系统性能测试报告。
沟通也是分层次的，最容易犯的错误的无论针对谁，写的文档，发的邮件都是一样的。其实针对不同层次的人，应该提供的信息不同，对于本团队人员，原理，架构，设计，测试，每步怎么做，结果如何，具体数据都应该说明，而对于其他团队的人员，具体的数据和每步怎么做就不需要了，对于项目经理，仅仅说明原理，架构，结论就可以了，对于高层来视察工作，原理加结果就行了。这也是为什么一篇文档有abstract,  summary, overview, concepts, detail, appendix等等部分，其实是对不同的人员看的。
总结：项目或程序员的第三阶段：一生二，关键词：“沟通”

四、二生三
对于项目来讲，当Client/Server或者Master/Slave已经运行稳定，是应该开发一个Master多个Slave的时候了，即二生三的过程。

对于程序员来讲，当你能够很好的带一个实习生或者初级程序员的时候，是可以成为一个小的Team lead了。

此步的关键是load balance，平衡。

对于系统来讲，负载均衡最重要的是两个目的：

高可靠性：当一个服务器crash的时候，不至于影响对外提供服务。
高性能：多台服务器可以并行的做事情，提供服务，加快相应时间。
其实说到底，负载均衡采用的是Data partitioning(数据分块)或Data replication(数据复制)的方法。数据分块即按照某种策略，将某类请求全部指向某个服务器，比如说按照时间分块，例如邮件备份系统，可以将某个时间段的邮件全部放在一个服务器内，对这个时间段的查询全部指向此服务器；再比如按照地区分块，例如地图信息管理系统，将某个地区的数据全部放在一个服务器内。数据复制即将同样一部分数据复制多份，放在不同的服务器上，既保证高可靠性，又能将请求平均的分配给多个服务器，例如Google File system中将数据复制三份，大型网站的服务器也一般会将同一内容放在不同的服务器上。

对于程序员来讲，沟通同样重要，但是不再是局限于一对一的沟通了，不再是能把问题表达清楚就可以了，而是要在团队内部保持平衡。无论是工作压力，项目有趣程度，培训机会，成长机会都应该平衡。

也无非是两个目的：

高可靠性：项目不会因为一个人的生病，休假，离职而影响项目的进度。
高性能：整个团队的力量发挥出来，不至于一个人成为了瓶颈。
所采用的不过也是数据分块和数据复制的方式。

所谓数据分块，即不同的人负责不同的模块，比如一个负责前端，一个负责后端，或者一个负责开发，一个负责测试等，这能够带来高性能，因为每个人的专业化和经验会使得效率提高，但是同时带来的问题是高可靠性，如果转负责这个模块的人离开，换一个人将大大降低效率。工作压力也不能很好的平衡，往往一个系统的初期阶段，后端的开发十分忙，而前端相对较闲，而到了后期，前端开发非常忙，而后端已经稳定，因而较闲。况且，人不是机器，是有边际效应的，当负责一个模块时间一长，兴趣会大大降低，觉得没有成就感，成长也少了。因而数据复制的方式也是必要的，也即通过伙伴开发，Knowledge sharing，code review等方式，让不同模块的人之间相互了解对方的模块，从而带来高可靠性，也即一个人不在，其他的人可以较快的跟上，也可以在一个模块压力大的时候，其他人帮忙做一些辅助的东西，比如各种tool，测试用例，性能测试，甚至改一些优先级较低的bug，不仅平衡了工作压力，而且接触新的模块会使得员工有较大成长，也是工作更加有趣。

总结：项目或程序员的第四阶段：二生三，关键词：“平衡”

五、三生万物
如果道生一，一生二，二生三是质变的过程，则三生万物是量变的过程。

对于计算机系统来讲，如果一个master能够很好的平衡两三个slave，则可以很好的扩展到十个甚至百个，千个。但是原理是理想的，现实却是，当master管理的slave的数量达到一定的数目的时候，master就是一个瓶颈，master的高性能和高可靠性又成了问题，这时候可以用多个master进行数据复制从而负载平衡，也可以使得多个master每个管理一个group的slave，这时候就应该有master的master了，也即系统出现了分层。Hadoop的Multirack cluster就是这样的一棵树。

对于团队的管理也是同样的，每个人的直接管理精力在10个人左右，多于这些人，往往会有很多疏漏的地方，或者疲惫不堪，因而，当一个团队成长的一定的程度的时候，也是需要分层的。当团队增长的15至20人的时候，应该考虑从现有的人员中选出master，也即team lead或者至少是coordinator，使得组织也成为了一棵树装。

总结：项目或程序人生的第五阶段：三生万物，关键词：“分层”

 

IT外企那点儿事(6)：管理路线和技术路线
技术路线和管理路线始终是每个程序员纠结的问题，也是各大论坛经常被辩论的问题。

然而一个有趣的现象是，在现实生活中，人们多愿意承认自己不精通某项技术，却很少有人愿意承认自己不能做管理。技术方面有问题多能够校正自我，而管理方面有了问题却总认为是对方的错，总之领导怨员工，员工怨领导，闹得不可开交。

在中国传统的官本位的思想中，不能不说管理路线占了绝对性的优势，尤其是在稳定的外企，管好管坏极难衡量的情况下。

做技术苦啊，相比于管理路线，有如下的弱势：

首先，IT业的技术变化太快，弄的技术人员疲于奔命。年轻人可以每天晚上几个小时的看新技术的书籍，而年纪偏大的你上有老下有小，做饭，洗衣，陪老婆，照顾老人小孩，逛超市，每天能有一个小时的学习时间十分不易了。如果是你已经很熟悉的领域，你自然可以用较少的时间就能达到年轻人较长时间看完的东西(理想状态下)，然而公司的项目所用的技术方向可不是随你心愿的。如果你是一个Java高手，碰巧公司买的一个第三方的库是用C++写的，需要对其进行封装，如此艰巨的任务，工程师中你的薪水最高，你不入地狱谁入地狱啊。你总不能说：我只负责Java的部分，C++的别来找我吧。

也许你经常听领导说：“编程主要靠思想，语言和平台无所谓”。然而如果你跳槽的时候，却经常听到面试官这样说：“好像你没有太多这方面的经验嘛”，你却不能以我很有编程的思想来回答。此矛盾之处着实使人困惑许久。技术路线还是分很多的方向的，正如武林有很多的门派。语言，操作系统等属于内功，然而只有内功却不足以行走江湖，必须还要有一定的套路，如Debug tool，profile tool，出现问题后的分析办法，编程时候的各种习惯，一些非常管用的技巧等，都是因语言和平台不同而不同。虽然对于初级的工程师来说，这些不是很重要，然而工作三年五年之后，是否能够熟练运用这些套路来准确的定位问题和解决问题，却是区别你是初级工程师，还是高级工程师的一个标志。当然当你在上升到项目经理的时候，又可以只谈编程思想的时候了。一句实话，一个要饭的不要因为听富人说吃青菜养生就见肉也不吃。周易中，同样在乾卦，同样元亨利贞，初九则应潜龙勿用，九五则可飞龙在天了，不同的位，同样的话，意义不同。

其次，没有优先知情权。当任务到来的时候，美国那面的老大一般是先发邮件给项目经理的。项目经理会进行一系列统筹考虑后再选择发给那些人。作为同项目经理同一级别的技术人员，是否提前或同时，甚至晚于与其他技术人员收到邮件，取决于你技术外的能力(你的reputation, 你和项目经理的关系等)。上面的文章也说过了，在外企，邮件是一门很大的学问，也决定了从属关系。把本来你擅长的任务先发邮件给他人，从而变成了他人的任务，也不是不可能的事情。当然当美国老板过来的时候，陪同和展示成果的，也多是管理人员的事情，虽然里面全是你的心血。

其三，没有资源支配权。项目经理一般可以支配多种资源的，如买硬件，Team building的经费，培训的机会等。但是相同级别的技术人员却没有。

其四，没有绩效评定权。任何员工的绩效都是基本由其report得顶头上司起决定作用的。相同级别的技术人员可能会有一些评价做参考，但是你不会知道和你平级甚至下级的薪水和绩效。

最后，没有人事任免权。一个员工是否能够进某个项目组，也基本是项目经理起决定作用的。一般的外企都会有推荐的制度，而通常会发现一般状况下(被推荐人不是明显的差)，管理路线的人推荐到其他组的人比较容易录取(同组推荐没有推荐费啊)。大家总要多少照顾个面子嘛，万一哪天要向对方的组推荐自己的人呢？

基于上述几点，经济基础决定上层建筑，你也就怪不得基层员工对你仅仅是因为技术而产生的尊敬，而对manager则是因为既威且信而产生的敬畏了。也许其实是你的建议是正确的，大家却都同意按照manager的来做；也许你一把年纪还要和年轻人因一个小小的设计争得面红耳赤，而他在manager面前总是yes, ok, i am 100% agree；也许你因一项新技术不很精通而被新人鄙视；也许就没有也许。

当前的中国是浮躁的，以上的原因造成大批大批的人涌入管理路线的独木桥，也造成了一些不合格的管理者走上了管理岗位。也许有这样的现象，明明在国外仅够做高级工程师的在中国做了Team lead，却在和普通工程师争功劳；在国外仅够做Team lead的，在中国做了manager，却不能很好的领导多层化的组织结构。

这种情况是悲剧的，却不仅仅在软件业，包括高校(系主任更容易拿项目)，包括医院(院长更容易申请经费)，包括研究所。

这也是为什么总有转管理，转售前，转销售，甚至转其他行业的论调的原因了。

其实技术路线也有它的好处，你可以埋头认认真真研究自己感兴趣的技术，两耳不闻窗外事。而由于一直没有放下技术，跳槽也相对容易的多，毕竟在中国，号称会管理一个团队的一抓一大把，而真的很有经验的技术人员却不是很多。

作为软件工程师，我们应该找到一条属于我们自己的路。

 

让我们来看上述三条曲线，是随着时间的推移，收入的变化。

很不幸，技术人员的收入曲线基本成C曲线状，也即刚开始收人较高，也能较快增加，后面随着时间的推移，收人增长略显平缓。

这主要是技术更新迅速的结果，设想从工作开始，就接触某项技术和某项框架，逐渐的掌握直到精通，到了十年的时候，正是规模效应开始体现的时候，可惜，此框架已经不流行了，已经淘汰了，行业中已经使用另一种语言或者框架了。也许你会说，以我十年的经验，对于新的框架也会更好的掌握。是的，我承认，然而由于框架的更新，你所谓的更好的程度，相对于刚接触新框架两三年的人来讲，公司不足以付给你另外7年经验所应给的薪水，毕竟，你也不是很熟。所以C曲线的形态显示出来了，由于技术的更新，你所得到的薪水增长远远低于你的经验所应该带来的薪水增长。

原因就在于：不易积累。

积累，尤其是对我们普通人来讲，是非常重要的，是最后成功的重要途径。当我们看《大家》栏目的时候，其实我们可以看出，这些成功人士基本上分两种，一种是天才，很年轻就能够取得很伟大的成就，当然我们不可能是这种人。另一种是泰斗，即靠多年的积累而取得的最后的成就，比如2008年获中国国家最高科学技术奖的吴征镒院士，被称为中国植物的“活词典”。虽然我们不期望能够成为大家，但是他们的精神和经验却能给我们启迪。像植物，或者是医生，是相对比较容易积累的行业，吴老可以在90高龄，如数家珍的说着自己年轻的时候积累下来的各种植物的知识。而工作十年的软件工程师，却难以启齿十年前的语言和框架，那已经out了。

这也是为什么很多销售的同学最后薪水会越做增长越快的原因。比如他们培养一个客户能得来收入1000元，随着客户的不断积累，手中有20个客户就有20000元。而软件工程师，看了10本fortran的书，得到一份1000元的工作，后来又读了10本Java的书，再加上经验，可能得到1500元的工作。

所以，我们也要学会积累，争取从C曲线变成B曲线，使得我们积累的经验能够带来相应的薪水。所以本人窃以为(仅供参考，自己的路还是要自己走)，有至于从事技术的软件工程师，尽量选择一些可以积累，相对稳定的方向，如Linxu内核，windows driver等，相信一个做了10年的Linux kernel工程师，绝不是一个可以读几本书就能够赶上的人。而很多流行的上层框架，如SSH等，如果你熟悉了它们的每一行代码，当Web开发开始使用其他框架的时候，岂不悲剧。(没别的以上，也希望SSH青春常在)

然而如果在事业的后期，想成就A曲线，就不是容易的事了。

当你想以较少的经验积累获得较高的收入，则必须要有放大器的作用，这种放大器我们经常能够接触的到，即营销。

很多研发人员十分鄙视管理和销售，营销。然而我认为，我们可以不从事管理和销售工作，然而我们最好了解一些人与人之间的交流规则，而非天天埋头于人与机器的交流规则。

可以举几个例子，比如我们卖烤鸭，当我们做的不好吃的时候(技术不好)，一只烤鸭卖5块钱，慢慢的我们有经验了，能烤出好吃的烤鸭了，也就能够卖10块钱，再加上好吃的调料，良好的环境，最多也就一只20元，到头了。而全聚德的烤鸭198元一只。

再比如，普通包子铺的包子5毛一个，你如果能够做的好吃1块一个，也就差不多了，而天津狗不理包子一个10多块，20多块。

这就是营销的作用，这就是品牌的力量。

也就可以理解为什么李开复要给大学生写信了，从而创新工厂即便比原来薪水少，即便每周工作60小时，也有大批程序员欣然而往。也就可以理解各个公司的老总总是不定时的出现在电视上，不断重复着自己成功的故事。

程序员不应该老待在自己的圈子里面，埋头做着自己的事情，而是要想办法扩大自己的影响力，多交朋友，多参加技术会议，多参加各种聚会。

有很多人抱怨，刚毕业就要工作经验，诸葛亮没有工作经验，不也成功就业了吗？《三国演义》中是这样描述诸葛亮的"或驾小舟游于江湖之中，或访僧道于山岭之上，或寻朋友于村落之间，或乐琴棋于洞府之内，往来莫测，不知去所"。这那是隐居啊，不出茅庐而名声在外，工作也是至交徐庶鼎力推荐的，卧龙先生可不仅仅是束发读史书啊。

总而言之，窃以为，做一个程序员，一要钻下去，积累技术，二要跳出来，影响世界(虽然只是一点点)。

 

IT外企那点儿事(7)：做一个优秀的基层

千里之行，始于足下，无论你有多么的豪情万丈，总要从最基础的东西做起。

然而要做一个好的基层工作人员，并不是低头认认真真写好代码就可以的，其中可大有学问。

按照余世维所论，一个好的下属应该：

主动向上司汇报你的工作进度——让上司知道！
对上司的询问，有问必答，而且清楚——让上司放心！
充实自己，努力学习，才能了解上司的言语——让上司轻松！
接受批评，不犯两次过错——让上司省事！
不忙的时候，主动帮助他人——让上司有效!
毫无怨言的接受任务——让上司圆满!
对自己的业务，主动提出改善计划——让上司进步！
我也总结了如下几点，欢迎大家补充。

(1) 做得快还是做得好？
当前的项目管理中，多是强调结果的，号称结果导向或者结果驱动。

作为一个基层，做人重要，做事更重要，除了良好的沟通能力，能拿得出真金白银的成果，更是每个项目经理愿意看到的事情。

然而怎么叫好的结果呢？

一九五八年党的八大二次会议上，提出多快好省的建设社会主义。多快好省四个字即体现了前辈革命家的理想壮志，也成为后来中国管理者心中的梦。所以我们时常听到如下的话："这些功能下个月一定要出来"，"代码质量要高，要有详细的注释，测试用例，code review"，"最好提前一周至少三天，可以准备demo"，"项目现在经费相对比较紧张，希望大家克服一下"。

然而现代的项目管理给我们画出了如下的三角形：

 

范围，预算，时间三者相互制约，牵一发而动全身。欲范围大(多)，就应该增加项目预算(不省)，如增加人手，增加资源，买第三方成品，或者应该延长时间(不快)，如推迟release的时间等。欲按期完成(快)，则可以增加预算(不省)，或者减少功能(不多)。

然而现实中，老板可不这样想，预算是早就做好了的，时间也是确定了的，功能缺一不可，作为基层的程序员我们唯一可以影响的就是用加班换来更多的时间，当然还有中间的一个圆圈——项目的质量。

到底是尽快的做出一个实现基本功能但设计稍有缺陷，测试不太完备，有少量的Bug的版本出来然后慢慢改进呢，还是经过慢慢的精心设计，做出有完备的测试用例，经过严格测试少有Bug的版本呢？

这个问题如果你问程序员，大部分人会选择后者。尤其对于初涉职场，充满激情的程序员们，往往满脑设计模式，满口软件工程，几乎见不得注释中的错别字和没有覆盖到的测试边界，似乎一个不完美的方案就有辱于软件工程师的名号了，我们称之"技术洁癖"。

如果你问项目经理，也会告诉你后者，而且最好以后者的形式用前者的时间(多少有些多快好省的味道)。然而很少有项目经理会直接看你的代码，更不关心你用的何种设计模式，也不会一个个看你的测试用例来思考是否覆盖所有的边界，更不会看你写的注释了。

所以很不幸，除了少数精通技术，熟悉细节，了解程序员苦衷的项目经理外(这可是大多数程序员都翘首以待的领导啊)，大部分喜欢前者。

因为精心的设计，良好的文档是需要大量的时间，完备的测试用例的代码量几倍于实现本身，功能测试，性能测试以及Bug的修改更是难以估计时间的，所以总的时间将几倍于前者的时间，在此过程中，你献给项目经理的，除了等待，还是等待。

人是不喜欢等待的，尤其是很少反馈的等待，当我们用windows的时候，往往会出现估计时间相当不准确的进度条，然而我们还是喜欢看着进度条一直走到底，同样项目经理也是。

总是能够很快的做出项目经理能够看到的版本，便容易给人一种能力很强的感觉，至少大部分人会这样认为。

也许你会说：我做的版本Bug很少，后期维护成本低，QA一测不就能够看出孰优孰劣来了吗？

仍然很不幸，在大多数人看来，你一个月做了一个稳定的版本被认为是做了一件事情，而别人两个星期做了一个不稳定的版本，后两个星期改了三个Bug是做了四件事情，而且其每次的会议总有进度可以说，成绩斐然。

而且一个人身上所挂着的Bug的个数，实在不是一件值得羞愧的事情，反而是一件令人感到荣耀的事情，这说明了你重担在身，举足轻重。

如果你做了一个模块，用了一个月，后来半年都不曾出过Bug，而另一个人做一个模块两个星期，出过多个Bug，并且后来兼任其他模块的时候还在改Bug，还是很不幸，你会被认为所做的模块相对简单，不容易出Bug，并随着项目的进行而被淡忘，会被这样提及："他在半年前做过一个项目"，而另一个人却会被认为所做的很复杂，有很多疑难杂症，而且后来会被认为身兼数职，会这样被提及："随着能力的提升，同时维护并负责多个模块，有并行工作的能力，有很强的解决问题的能力"。

也许你觉得我说的太极端，那就举一个历史上的例子吧，有兴趣大家可以看李亚平的《前清秘史——入主中原之路》，其中是这样描写当时并称“南戚北李”的两位将军的：

李成梁屡立大功，受封为伯爵，跻身于帝国贵族行列。在当时，他的地位、名望等，很有可能已在戚继光之上。有一种看法，包括《明史》的作者们认为，恰恰因为戚继光威名太盛，坐镇蓟门十六年，使敌人从来不敢来犯(没有Bug啊)，于是转道入侵辽东，才给了李成梁屡立战功的机会。张居正死后，新政被废，受到张居正支持重用的戚继光被迅速边缘化，在郁郁寡欢中死去(可能明朝认为蓟门这个模块不需要再维护了)。而李成梁，他同样受到过张居正的支持和倚重，然而，可能由于下面的三个原因：其一，远离京师，与张居正没有过多的私人交往；其二，赫赫战功给万历皇帝留下了深刻印象(每次总有进度可说)；其三，动荡不安的辽东局势离不开这位骁将(辽东模块还需要维护啊)。从而，李成梁避免了池鱼之灾。

当前社会中，不是如此吗？是修了坚固的河堤的市长感动中国，还是和民众一起抗洪抢险的市长感动中国呢？是治理的地方路不拾遗的公安局长应该升职，还是让黑社会猖狂十年然后一举击溃的公安局长会升职呢？

如果你觉得你的项目经理英明过于历史甚至当朝首辅，那么恭喜你。

(2) 有问题要尽早喊
当一个模块或者一个任务交给你的时候，可能存在各种各样的困难，会出现各种各样的问题，需要各种各样的资源，这一切都应该慎重考虑后尽早提出。

问题的尽早提出，其实是风险控制的一种手段。

调配资源，排除干扰，风险控制是一个项目经理的重要责任之一，然而不要认为项目经理会英明神武到知道一切细节，也不要认为这是项目经理的事情，与你无关。其实一个模块，真正了解细节的是你。

所以对团队来讲，事先问题没有提出，到时候出现是你的甚至你的团队的责任，问题及早提出了，项目经理向相关人员请求资源，到时候没有解决就不是你的责任，甚至也不是你们团队的责任了。这个样子既帮助你的项目经理控制风险，又能够在外国人面前撇清责任，是每一个项目经理都欢迎的事情。

对你个人来讲，问题及早提出了，以后或有Bug，或有delay，都不会给人一种突然的感觉，也给项目经理一种对你，也对整个项目可控的感觉。

从心理学上来讲，人们多惯于先听坏消息，再听好消息，而不愿意先听好消息，再听坏消息，这就是我们常说的冷热水效应：一杯温水，保持温度不变，另有一杯冷水，一杯热水。当先将手放在冷水中，再放到温水中，会感到温水热；当先将手放在热水中，再放到温水中，会感到温水凉。

一个经常举得例子是：某汽车销售公司的老李，每月都能卖出30辆以上汽车，深得公司经理的赏识。由于种种原因，老李预计到这个月只能卖出10辆车。深懂人性奥妙的老李对经理说：“由于银根紧缩，市场萧条，我估计这个月顶多卖出5辆车。”经理点了点头，对他的看法表示赞成。没想到一个月过后，老李竟然卖了12辆汽车，公司经理对他大大夸奖一番。假若老李说本月可以卖15辆或者事先对此不说，结果只卖了12辆，公司经理会怎么认为呢？他会强烈地感受到老李失败了，不但不会夸奖，反而可能指责。在这个事例中，老李把最糟糕情况――顶多卖5辆车，报告给经理，使得经理心中的“秤砣”变小，因此当月绩出来以后，对老李的评价不但不会降低，反而提高了。

(3) 用Bug来说不
不知从何时开始《致加西亚的信》以及《没有任何借口》此类的书开始畅销，从而以执行力的名义把责任全部推到被领导的一方，用军队的方式来要求自己的员工，不讲条件，没有借口，从不说不，来完成领导所给的任务。真不知道资本家有什么资格这样要求自己的员工，作为军人为祖国献身后至少能够成为烈士，家人受到抚慰，而资本家在员工连跳九人的情况下却在论证这个数字其实低于全国平均自杀率的。

然而大多数的领导的的确确喜欢没有借口的下属，也不喜欢听到说不。所以当一个任务下达的时候，或者一种方案被指定的时候，不要直接说不。

领导毕竟是领导，能做到现在的位置，毕竟有强于你的地方；领导毕竟也是人，提出的方案也可能是拍脑袋拍出来的，也许会有不合理性。

然而需要记住的一点是：上情下达可以拍脑袋，下情上达则要用证据。

当你认为领导给的任务或者方案有问题的时候，除了上面提到的喊难在前之外，一定要加一句，"我试试看"。

当你经过实验测试，有数据或者日志足以证明你的结论的时候，可以尝试说，"我觉得可能有些问题"。

然而有时候简单的测试并不能够证明的时候，或者领导再次坚持的时候，那就上手做吧，只是别忘了做的有扩展性一些，能在多种方案之间较容易的切换，并将领导坚持的方案暴露出来。当测试人员发现问题的时候，将比你说不有效果的多。这时候领导关心的便是如何Bug进行修复，不在纠结到底应该采用你的方案还是他的方案了，当然此时你千万不要得意洋洋的指出领导原来方案的不合理性，你不指出，领导其实是从心里认可了你的方案的，并且为你记了一功，如果你指出来，就适得其反了，大部分领导绝不会表面承认自己的错误的，可能会再次坚持自己的方案的合理性，并把因此带来的项目失败或者delay记在你的头上。也许大家清晰的记得曹操不承认"鸡肋"的退兵禁令而杀杨修的故事吧。如果你觉得你的领导气度大于曹操，那么再次恭喜你。

也许你会说：这不是浪费了一个过程吗？其实不然，你先做了领导的方案，然后改Bug的时候应用了自己的方案，在领导眼中，你是一个好的下属，好的执行者，你是做了两件事情的。

如果你坚持做了自己的方案而没有优先用领导的方案，则会有以下风险：

你永远失去了证明你的方案优于领导的方案的机会
你会被认为固执，难于沟通，执行力差
一旦你的方案出现问题，你将单独的承担责任，甚至整个项目delay的责任。如果你优先采用了领导的方案出现问题的时候，一般合格的领导会勇于承担起责任，替你说好话："我们采取的方案是相对较优的，也是经过测试的，Bug是难免的"，相反，如果你固执己见，则没有人会替你说话，反而会说："要是用原来的方案就不会出现这个问题" 。
领导的方案一般是由一定原理上合理性的，你的方案可能是比较符合你的实际需要，然而当时过境迁，context不在的时候，你百口难辨。
所以，毫无怨言的接受任务——让上司圆满，如果有问题，让Bug来说。

(4) 该干什么的时候干什么
在外企，一个常说的词叫"professional"，何为职业化，一个通俗的说法就是，该干什么的时候就干什么，当然无论干什么，永远不要忘记，你是一个程序员，一个基层的程序员。

前面说过，除了写程序，外企的生活是丰富多彩的，健身，按摩，小食品，饮料，旅游，年会，各种协会等等不一而足，而且外企的氛围是相对宽松的，你可以在任何时间尽情享用，没有人会有意见，当然是在你完成了工作的基础之上的。

然而永远需要记住的是，写程序才是你的天职，而多彩的生活是公司对员工的福利，是一种施舍，说的不好听一点，公司花钱请你来是写软件的，不是让你来娱乐的，公司让你娱乐是给你脸，你总不能给脸不要脸吧。话说的难听一点，但细想想，话糙理不糙，试想如果项目经理每次来巡查的时候都看到你或大声的说笑，或尽情的饮食，或玩桌上足球的时候，其内心不会有上面的想法？只不过是一种优雅的方式表达出来罢了。比如走到你的面前，微笑着问："你的feature做的如何了？"，"Bug XXX有没有结果？"，顺便强调一下你所做的模块的难度和重要性："你做的这部分比较有难度，是对你能力的挑战"，并在最后来一句："慢慢做，不着急"。你可知晓此彬彬有礼下面的深意？经理两次到你这里来说"不着急"的间隔越短，其实是说明这件事情越着急的。

所以说在办公室的大部分时间，你都应该低头写程序，谈话也要讨论技术问题，娱乐要适度，除非你想被人觉得工作量太少，不努力，或者你有足够的信心自己负责的模块不会出问题。

另外在开会的时候，你由于任务太多，总是盯着自己的笔记本默默写自己的代码吗？不要这样，这样会让组织会议的人感到不被尊重，会让领导觉得你对项目组不够关心，不够投入，甚至不够忠诚。开会的时候，就要像开会的样子。你可以提前阅读材料来准备几个问题；你可以支持，补充或建议组织者的方案；你可以在外国人面前举出证据来维护中国团队的利益；实在没招，你至少可以记会议记录，会后发meeting minutes。这样你给人的印象永远是你是有想法的，你是有贡献的，你是关心项目的，你是热爱团队的。

一个Team出去吃饭，或者出去旅游的时候，你是得意忘形的放开手脚去玩吗？甚至脱离团队和要好的朋友去逛吗？不要这个样子。余世维在《经理人常犯的11个错误》的演讲中曾经说过，出去Team building，对于员工来说是休息，而对于经理来说是工作。的确，你要清楚资本家为什么会出钱让员工去做这些和工作看起来无关的事情？为什么要大家一起出去而不是每人发钱自己去玩？当然是要增加团队的凝聚力和归属感，为共同合作奠定基础。既然对于经理来讲是工作，难道你不应该有责任辅助你的经理做好工作吗？在大家一起吃饭的时候，如果冷场，积极的起一个话题吧；在经理提出玩一个团队游戏的时候，率先支持，主动去做吧；在外出旅游的时候，帮助你的经理订餐馆，清点人数，摄影照相吧；当爬到山峰，或者年会表演节目的时候，喊出增加团队凝聚力和影响力的口号吧；在活动结束后，整理资料，相片，发出email来进一步增加活动的效果吧。这样你就是有组织能力的，辅助经理成功的，有良好影响力的，也是热爱团队的。

这里提到了团队聚餐中的话题问题，这里顺便提一下，当然根据不同的Team的氛围以及当时的情况而定，话题的优先级依次如下：

项目话题：如进度，难点，后面还会提到，学会喊累，喊忙，这是一个比较好的机会。当然此话题比较适合加班或者中午时的团队聚餐，不太适合旅游时候的团队聚餐。此话题可表明你对项目的关心。
技术话题：比如语言排名，那家公司被收购了，平台之间的差异等等。此话题可说明你对技术无限热爱。
员工生活话题：比如周末干什么了，介绍女朋友，结婚，孩子教育等，当然以当事人意愿为准，不要太当真。此话题可说明你关心同事。
娱乐话题：比如看什么电影，娱乐圈出来什么事情等，这是万能话题，也是最保险的话题。
员工敏感话题：比如非议其他Team，或者美国团队等，此类话题最好不要涉及，背后议人不太好。
公司敏感话题：如有的Team裁员，减薪，福利下降等，此话题千万不要提及，这是领导层想尽力遮盖的问题，甚至不在项目经理的权利范围之内。涉及此类话题将给人以你是一个不可托付大任的人。
最后，如果你在学校中是演艺明星或者体育明星，那么年会的表演以及团队之间的比赛也不是你表现英雄主义的地方，而是体现团队意识的地方，也是交流沟通的好机会。所以不妨在节目中介绍一下自己团队的产品；不妨在角色设定的时候劝说core team的人加入扮演一个牛人角色(欢乐可以一定程度上冲淡马屁味道)；不妨申请印有团队logo的运动衣；不妨在运功过后和高层一同边走边聊(比平时冲到高层办公室里面好的多的机会)；不妨去敬HR一杯酒，被她们多灌几杯(HR的办公室是个敏感区，平时很难交流感情啊)；不妨去维护机房的团队那里敬酒以感谢他们的工作，去前台那里敬酒以夸赞她们的服装，发型等(他们对你来说真的很重要，想想几百人的团队，前台和运维都只有两三个人，还是那就话，当供需相差很大的时候，价格都会越来越高)。这将使你成为一个受欢迎的人。

(5) 适当的增加影响力
做一个好的基层程序员，除了完成自己的本职工作以外，也需不断增加自己的影响力，这既是你的品牌，也是日后加薪升职不可缺少的因素。

增加影响力主要有以下几种方式：

在工作中，如果完成了一定的功能，或者测试有了详细的报告，可发邮件给领导并cc整个Team，让领导知道你的付出，和同事分享你的喜悦，让众人知道你的亮点。邮件或者报告要在开头做精炼的总结，使得大部分人能够尽快的了解结果，具体细节可放在后面，供同模块的员工详细查阅。千万不要默认你的上司和其他人都显而易见的知道你完成了什么，这也可能是很多人觉得怀才不遇，难遇明主的原因吧。台湾作家黄明坚有一个形象的比喻：“做完蛋糕要记得裱花。有很多做好的蛋糕，因为看起来不够漂亮，所以卖不出去。但是在上面涂满奶油，裱上美丽的花朵，人们自然就会喜欢来买。”
在各类的会议中，如上面所说，事先准备问题，合理提出建议，适时提供证据，都是在同事，领导，以及外国人面前展现自己的机会。
有时候美国有或管理或技术的老大来中国，都会召开all hands，这是一个不可多得的在整个公司面前展现自己的机会。而在外企，程序员的竞争力大约包括对产品的把握，对技术的把握和对英语的把握等能力。all handls也是展现这三种能力的好地方。也许你会发现这样的事实，在all hands上英语流利的提问者们，提出问题的目的也许并不是为了想弄明白什么，而是为了展现什么。他们大多是这样问的："As what you side A, but actually what we did in our project is B, so how/what/when C"，你会发现，A和B会说的很具体，而C很抽象，显然A是为了展现产品把握能力(你讲的我都听懂了)，B是为了展现技术把握的能力(我们采取了什么样的技术)，整篇都用英语表达自然展现了英语的能力，最后问一个很Open的问题C，总不能问老大个很难的问题吧。
tech talk：当有了一定的技术积累，tech talk是一个很好的展现技术实力的平台，毕竟程序员是吃技术这碗饭的，所以良好的技术口碑对最初的升职至关重要。tech talk所讲的对象一般不是同项目的员工，因而难度要适当的把握，太简单则不足以体现你的技术实力，太难则大家会听的云里雾里，不能真正了解你的价值。在做tech talk的时候，最好一开始有一个整体的流程或者框架的介绍，以使得听众不会在途中迷路。一般有一个规律，就是在最前面几个slides的问题是最多的，大家总能够提出各种各样的问题，所以开始的几页，一定要是你最最熟悉的，最最有价值的，然而随着信息量的增大，后面就几乎提不出什么问题来了，到演讲最后，一般也就只能提出一些open question了，一般可以通过三个阶段轻松回答，其一，that is a good question，其二，it really depends，其三，I'd like to give an example。
demo：在很多施行迭代开发的项目管理的公司里，一个阶段是会有一个demo的。很多程序员重代码，而轻demo，明明实现的非常优雅的功能，却懒得花时间生动的demo出来，中国有句古话：六十四拜都拜了，就差最后一哆嗦，多对不起你前面没黑没夜的工作啊。demo是应该好好准备的，应该有一个详细的demo流程，先录入什么数据，然后如何操作，最后应该看到什么等等。然而demo是容易失败的，似乎成为一个难以规避的定律，即无论原来demo如何准备，临阵总会有意想不到的结果，大概因为看demo的人可能会提出奇怪的尝试需求，而可能正是程序员没有考虑过的边界。所以demo中，应该事先将良好的过程录制下来，以防止真实demo过程中有差错，造成功亏一篑，至少可以证明原来是好的。在demo中一定要用近似真实的数据，如输入人名，就用真实身边的员工姓名，输入日期就用当天的真实日期，千万不要用aaa, bbb, 123456此类的数据，既不美观，也容易出问题。而且在demo的过程中，应该严格按照已经准备好的流程走，当完全走完流程后，方才可以处理现场提出的各种尝试，可保证能够完成demo任务。
帮助他人：在不耽误自己工作的情况下帮助他人解决技术难题，是比tech talk和demo更能够体现技术实力的地方，并会积累下人脉，当众望所归的时候，你的升职也就仅仅是时间和名额问题了。举个相似的例子，tech talk好比是保健医生，只不过是给你宣扬养生之道，而解决技术难题就如同主治医师，可以使你药到病除。很显然，如果一个人如果能够很好的按照保健医生的养生之道去做，就很少会去找主治医师去看病了。然而主治医师却比保健医生更受欢迎，一方面因为相对重要的事情，人们多会更重视紧急的事情，一方面可能因为只有在逆境，出现问题的时候，人们才会虚心接受他人的意见。试想听tech talk的人们，就如同6000点的股市中的股民，多抱有"你懂，我可能比你还懂"的想法，而出现了问题的人们，便如跌至2000点股市的股民，才会虚心向专家请教，并对给出的方案五体投地了。而且此点满足，不忙的时候，主动帮助他人——让上司有效!
培训新人：有时候公司会招来一些学校来的实习生，一年一度也会招很多应届毕业生。当然一般公司都会有各种的培训，然而一旦进入团队的时候，如何更快的上手项目，仍然需要一个过程，如果能有老员工指导一二，将会轻松很多。在项目比较紧的情况下，很多老员工不愿意培训新人，万事开头难，起步总是相对缓慢的，害怕因此而耽误进度。当然，以耽误自己的工作换来对新人的培训我也是不赞成的，这也是后面所说的要给自己留buffer的原因所在。但我需要指出的是，给一个饥饿的人一个烧饼要比其成为千万富翁后给一百万更加让人感恩。人的眼光应该长远一些，无论如何都不要轻视一个年轻人，因为你不知道其将来会是什么样子。有的人，年纪大，level高，但是基本可以看出其一辈子的轨迹了，有的人年纪轻，level低，却可能前途无量，你永远不能把握将来谁会是你的贵人。
在增加的影响力的前面，我加了一个形容词——适当。要有和你的level相匹配的影响力，小心功高盖主啊。外国人有时候会强调leadership without authority，然而如果你果真这样做了，多半会招来同事的敌意(你凭什么指手画脚的啊)，也可能会招来你的lead心中的隔阂(没有authority你都能够lead啦，给你authoriy还不反了天了，你lead，那我干嘛)，所以还是不在其位，不谋其政的好。

(6) 给别人光环
当同事完成一项功能或修改完一个Bug的时候，你是否给过真诚的赞誉，帮其增加上述的影响力？

当同事帮助你解决了问题或者提出了优秀的方案，你是否公开表示感谢，让群众和领导都知晓？

当领导问及你做的模块的时候，你是否有意隐瞒了他人的功劳而突出自己的贡献？

当会议的时候，你是否会处心积虑的故意反对竞争对手的方案，虽然你觉得其实这真的是个好方案？

当发现其他人的Bug，Code reivew的时候发现他人的设计缺陷，你是否幸灾乐祸的大声疾呼，唯恐他人和领导不知？

你是否在同事，领导，HR的面前非议他人，嘲笑他人的设计，褒贬他人的缺陷，鄙视他人的技术，虽然的确你是此方面的大拿？

当你有幸获得一份荣誉的时候，你是否先谢国家(公司)，再谢政府(团队)，再谢领导，再谢同事？

给别人光环吧，别人也会给你光环。

一个只顾自己头上光环的人，以及一个别人给了光环而不知回报的人，最终都会孤立无援，难以开展工作，是涸泽而渔的做法。

我们必须承认的一点是，每个人都有自己的长处，也有自己的短处，每个模块都有优美的地方，也有不尽人意的地方，你有你擅长的技术，别人也有别人擅长的方向。如果大家互相向别人的头上套光环，则外人和领导看到的会多数是光环，从而大家精诚合作，团队蒸蒸日上。如果大家全部互相揭疮疤，则外人和领导则看到的会多数是负面的，从而大家互相猜忌，整个团队都没有希望。

历朝历代都有权臣，权臣之间必有党争，派别之间多知道对方的优势，也掌握了对方的把柄，如果派系之间相互合作，则大家都会壮大，皇帝则不会知道下面的暗流涌动，然而英明的皇帝多挑拨派系之间的关系，使他们互相揭露对方的把柄，从而下情上达，从中制衡。

我们也会经常看到，当一家公司的高管离开他的老东家而投奔新东家的时候，公开场合下，此高管多会十分赞誉在老东家中工作过的时光，赞誉工作过的团队，赞誉老东家的产品和项目，赞誉自己在老东家取得的进步，而老东家也多会给与此高管十分积极的评价，肯定其作出的贡献，其为公司带来的价值，其培养出的团队。其实如果两者之间如此的默契，如此的互相满意，就不会发生跳槽的事件了，既然选择分道扬镳，则其中必有隔阂，只不过互相心知肚明，各不言明罢了。这样无论对公司的发展，还是对此高管的职业生涯都有好处。试想，此高管必然是清清楚楚公司的优势劣势，公司也明明白白高管的功过是非，就像一对生活了很久的夫妻，既知道你能言善辩，也知道你鼾声震天，既知道你玉树临风，也知道你不爱洗澡，如果在公开场合互相指责，甚至谩骂，岂不家丑外扬？

(7) Daily report和weekly report很重要
很多程序员宁愿多写程序，也不愿意写report，觉得十分麻烦，而又无聊。

但是Daily report，weekly report真的非常的重要。

首先report可以帮助你管理自己的时间。在时间管理中，我们知道，人总是有重要而紧急的事情，重要而不紧急的事情，不重要而紧急的事情，不重要而不紧急的事情之分。你是否总结和思考过自己真的总是做了重要而紧急的事情么？人们总是忙啊忙，从早忙到晚，天天加班，其实每天都在处理各种各样的突发紧急的事件，使得计划一拖再拖，而忽略了对自己很重要的事情。试想想吧，你原来计划过要读的书有多少是真正去读了的？你在朋友面前畅谈的宏图大志有多少是真正实践过的？你还记得儿时的梦想吗？你是一直向着自己想要的方向在不断的进步吗？时间管理的原则告诉我们，每个人应该有一张思考的床，不要穷忙、瞎忙、无心的忙。写daily report和weekly report不完全是应付上司的，也是自己思考总结的过程啊。我还记得最初每周定计划的情况，当一周过去进行回顾的时候，我当时吓了自己一跳，我原以为自己一直过的非常的充实，却发现计划做得事情真的只做了大概三分之一，照此下去，如何进步啊。有兴趣大家可是试着制定一下计划，越详细越好，工作方面的可以写给上司看，学习，社交等方面的可以自己写给自己，有时候多少有些身在江湖，身不由己的感觉。

其二report可以帮助你总结自己的进步。当天做的事情一般人还是记得的，一个星期做的事情，大概就模糊了，半年前做的事情，则很多细节都忘记了。很多的时候，当我们每年对自己进行年终总结以期待明年加薪的时候，当我们想要跳槽来总结自己忙碌了几年的成果的时候，往往会发现，report到用时方恨少啊。面试的时候，对于有经验的人，往往会将项目经验问的很细很细，当时你为什么选择这种方案呢？系统的速度如何一步步改进提高的？你发现你可能说不清楚了。平时尽量多详细的记录一下自己每天的进步吧，这可是影响到你薪水的闪光点啊，对方的公司正等着一个牛人来提高他们的性能呢，你明明取得很不错的结果，只是忘记了自己做了哪些改进，岂不可惜啊。

其三report可以帮助你增加自己的影响力。如上面所述，report不但可以让自己知道自己做了什么，也可以让上司知道你完成了什么，如果写到wiki上，还能让更多的人知道你的成绩。

其四report可以作为维护权利的证据。这一点前面也说过，作为初入职场的基层，作为相对美国来说弱势的中方，证据是非常重要的。当项目delay的时候，你如何证明你是提前schedule完成的？当性能遇到瓶颈，你如何证明你曾经高效且没有做过改动？在写程序的时候，我们知道，当context不在的时候，唯一能够定位问题的，就是log了，report就是你工作的log。

其五report可以使你的上司对你放心。很多初入职场的基层，埋怨上司过多的干预自己的工作，总是有事没事的过来问，做的如何了？有什么困难？这段时间在做什么？有时候这种询问会打断你的思路，着实让人困扰。其实情有可原，你刚来，不放心是可以理解的。如何做到你办事，他放心是你的责任。当有阶段性成果的时候实时报告自己的状态，每天写daily report报告自己的进度都是让上司放心的办法。一个有意思的现象是，当你一天一封daily report向他汇报的时候，他却不怎么过来干预你的工作了，甚至到最后daily report他也不怎么看了。

做到此一点，方能主动向上司汇报你的工作进度——让上司知道，对上司的询问，有问必答，而且清楚——让上司放心！

(8) 给自己留buffer，学会喊累，学会喊忙
初入职场，激情高涨，多喜欢将自己满负荷运作，无论是需求来自领导还是来自同事，都不好意思拒绝，最后弄得自己疲于奔命，焦头烂额。

其实工作中，是应该给自己留有一定的buffer的，一方面，可以在项目有了突发事件的时候，不至于临阵慌乱，尚有调整和处理的时间，不至于第二天demo，当天晚上代码才完成。另一方面，要做好以上所述的事情，还都是需要buffer的，绝不能够低头干个不停。

另外，公司是要对项目负责的，而自己的职业前途，却只有自己负责。除了每天忙于项目之外，总要有一定的时间进行自我进步，从而提升自己的价值。前面也说过，有的人面试的时候，仅仅知道项目中用到的知识点，而相关的却很少知道，从而使自己的职业生涯既不广，也不深。所以日常工作中，留有一定的buffer来将知识点变成知识面是很重要的。

所以如果你真的很忙，真的很累，要勇于喊出来，而不要默默的承受着，当然这不是让你装忙装累，而是向周围散发出一种信息，就是你已经负荷较满了。这样你的领导在安排任务的时候，会综合考虑，你的同事在向你提出需求的时候，也拒绝的合情合理。当然你不能总是喊忙，总是不出成果，如第一点中所说，result永远是最重要的。而总是喊忙，总是能出成果，确是一种工作努力的表现。有的人认为，只有相互说话才叫沟通，其实不然，殊不知自言自语，凝重的表情，同样是沟通的手段。

也只有在有buffer的情况下，你才能做到充实自己，努力学习，才能了解上司的言语——让上司轻松，你才能够做到对自己的业务，主动提出改善计划——让上司进步。