IT外企那点儿事(转)

IT外企那点儿事(1)外企业就那么回事

 

外企，一个听起来似乎充满光环的名字，每年众多大学毕业生向往的地方。

说起外企，总能让人联想到很多令人心动的名词：高薪，人性化，浮动工作制，年假，完善的流程，各种福利如：旅游，室内乒乓球台，健身房，按摩椅，小食品，酸奶……

然而真正进入了外企，时间长了，也就发现，其实外企也就那么回事。

所谓高薪，严格意义上来讲是高起薪，也即刚毕业的时候每个企业公开的秘密，同学们总能够从师哥师姐那里打听到这个数字，有的企业甚至爆出较去年惊人的数字来做宣传。一个个光鲜的数字吸引着尚未毕业的大学生们，宣讲会的人数是基本和这个数字成正比的。然而由于大多数的外企，由于规模比较大，机构也相对的稳定，高起薪的背后是稳定的加薪，每年7%~10%是常道，20%则是皇恩浩荡了，除非你能够取得整个Team都认可的成就，然而如果不幸参与的项目是一个多年的产品，至多是修改一些Bug或者增加一些边边角角的功能，又有多少这样的机会呢？大约在下看到的是这样的，也许并不符合所有外企的情形。于是当毕业生中的佼佼者很幸运的加入大的外企的时候，不如你的同学只有默默的加入了不算太大的民企。这一直是你引以为豪的资本，并总在同学聚会的时候大说特说你们公司的薪水，福利，在你的同学抱怨民企的加班声中附和着，心中却莫名的产生了一种优越感。这种优越感使得你进一步沉浸在美好的外企生活中，却发现越来越没有那么优越了。三年，五年，你一次次的听说你的同学升职了，又升职了，而你还是一个普通的engineer，因为外企的升职基本是由严格的年限的，有时候多少有些按资排辈的味道。你一次一次听说你的同学加薪了，又加薪了，薪水直逼你当前的薪水，甚至在五年的关头超过你。你越来越发现你的同学逐渐的掌握了一个系统前前后后的模块，能够完整的负责起一个项目的时候，你却还是螺丝钉，每天接受外国人的指示，在yes, ok, no problem, i am 100% agree的声音中继续做你的螺丝钉般的小功能。我不知道十年后会如何，在参加了多次的开发者大会后，我发现几乎所有的外企的演讲者都是外国人，中国的演讲者则多来自本土的创业企业，当听着他们如数家珍的谈着自己的创业企业如何一步步做大，系统如何一步步改进，直到今天的架构，他们外企的同学能有这种机会吗？

所谓人性化，用外企的语言就是我们是很Open的。Open体现在很多方面，诸如高管的办公室的门始终是开着的，你可以在任何时刻走到任何的高官的办公室里发表自己的看法，只是你必须保证，当你满怀激情的走进高官的办公室，关上门，半个小时后同样满怀激情走出办公室，你的顶头上司对你没有看法，即便你确实没有说什么，仅仅谈论了一下午餐而已。所以除非高层主动安排和你谈话，尽量不要没事跑到高层那里，在你的顶头上司控制范围之外和他的上司进行私密的谈话，要知道有一种关系叫表面上支持，心中的隔阂。即便是高层主动要和你谈话，最好事先和你的顶头上司事先沟通，当然不用太正式，比如在闲聊的时间抱怨一下："今天下午又要被老大找去One on One，项目这么忙，不知道有啥事情可谈的"，呵呵，一些术而已，姑妄言之姑听之吧。对你最重要的永远是你的顶头上司，当高层听完你的建议，OK, I will take it into consideration之后，便和你没有啥关系了，绝不会存在当你的顶头上司决定给你涨薪7%的时候，高层会出来说一句，我觉得他表现还不错，涨10%吧。当然，按照公司的规定，你的顶头上司也会过一段时间和你来一次One on One，问问当前的情况，问问有啥意见等等，这可不是推心置腹的时候，需要把握火候，对当前的情况说的太满意，感觉不真诚，太不满意自然领导不爱听，说没意见显得对Team不够关心，说太多意见会让人感觉你不安全，所以总的原则是要多提改善性意见("code review预留的时间应该更长一些")，少提颠覆性意见("现在的项目流程有很大问题")，多提有证据的具体意见("我们有几十个Bug，可能一个星期确实做不完")，少提抽象型意见("Team之间的沟通有问题")，多说与项目相关的意见，少说与自己相关的意见(尤其不要太真实的说自己的人生规划)，多说在领导意料范围之内的意见(这样会给领导以对Team的控制感，比如说天天加班到10点，领导也看在眼中，可以提一下)，少说在领导意料之外的意见(即便有，请事先沟通，让领导在One on One之前就心里有数)。Open还体现来另外的方面，比如领导会和员工一起参加各种工作之外的活动，比如打球，比如年会表演，比如一起健身等等，而且在此过程中，往往是充满的欢声笑语的，但一定不要忘记领导就是领导，哪怕不在项目中，千万不要因为你曾经是学校的篮球高手，或是文艺主干，就能在此类的活动中充当领袖角色，在你的项目领导面前指手画脚，虽然在活动中他会夸你，没想到你还有这方面的才能，但是在领导面前充老大，这笔账是迟早要还的，比如在项目的后期不能够完成美国派来的任务的时候，你会被冠以虽然前一阵成功组织了活动，但是耽误了一些项目进度的罪名，从而影响你的绩效。如果你在健身房遇到领导，和你一起健身，你们可以边健身边聊的很开心，但是领导的心中的第一个想法一定是，这小子项目干完了吗，还有空工作时间健身？，并且会在以后的工作中反映出来，比如时常关心你的工作进度，加大你的工作量等。

所谓浮动工作制，很好听的名字，就是你早上可以推迟来，晚上可以早些走，只要能够完成任务，每天工作6个小时都可以。初入外企的时候，看到很多前辈可以早上十点，甚至十一点才到公司，认为浮动工作制太好了，于是拼命的工作，企图在6小时干完10个小时的活，然后有时间或学习或休息。然而最后发现，活是永远干不完的，资本家花钱请了你，会让你轻松应对？浮动工作制，其实就是加班不给加班费的另一种说法，也即合同中也许会写着"所有的加班费已经被计入了薪水中"。只要能够完成任务，每天工作12个小时也是应该的。晚上留下来很晚，或是早上很早被拉起来和老美开会，也是浮动的时间之中，你无话可说。为了改美国客户的一个Bug，深夜加班，你无话可说。在中国是休息日，但美国不是休息日的时候派去美国，并不补偿你的休息日，也不给三倍工资，你无话可说。

外企的年假是相对较多的，也是外企在校园宣讲中经常引以为豪的一点。然而年假又有多少真正能够落到实处呢？其时大部分是休不到的，项目不允许，领导不允许，外国人也不允许。不允许当然不是显式的，而是潜规则的。项目永远是紧的，即便不那么紧，也会被人们喊得使大家觉得很紧，如果一个Team有很多人休很多假，对领导来说，好像对上面不太好交代。如果Team中你单独休假，你会被提醒，现在大家都在赶进度，不要因为你这个模块把项目block了。如果Team中大家想一起休假，领导会说，大家都在这个时候休，连backup都没有，出了事情找不到人啊。如果你平时想休息一天，领导会说，有什么事情吗？没什么事情可以等项目闲了些集中休息一下，明天早上可以晚来些，可能这一阵确实太累了。如果你想连着长假一起休，领导会说，本来就有一个星期了，还另外请，不如平时累的时候休息一天，效果好。如果美国人放假(如圣诞)，中国不放假，美国人会在放假前有很多任务布置过来，要在这个期间赶上美国的进度。如果美国不放假，中国放假(如过年)，总不能让美国老板找不到人吧。当然以上借口只是在你提出请假的时候，以商量的口气被提及，如果你真想请假，领导还是会毫不犹豫的批准的，因为我们是Open的嘛。然而以上借口却会使得多数员工不太敢于请假，因为大家都明白，有一种关系叫表面上支持，心中的隔阂。当然即便假期被批准，还是有条件的，比如"没问题，好好休息，走之前把文档(报告，邮件，代码)发出来(提交到svn)就行了"。一般这个附加条件都会耗费一些时间的，一般是第二天休，前一天晚上至少九十点走，早上请，中午才能走，中午请，下午三点多才能走。

完善的流程。外企的流程是非常完善的，甚至是极度的完善，过分的完善。所以外企一般都会有会议室预定系统，会议室永远是被占着的，一天一天的总是开会，讨论。例会就有模块组的，开发组的(包含多个模块)，项目组的(开发和测试)，Group的(同一个大老板的多个项目)，all-hands的(整个公司)。写一篇文档要模块组review，开发组review，测试组review，和美国开会review，重新改了第二轮review。以及code review，bug review。每个项目组作了一个阶段后给整个项目组的demo，甚至给整个group及老外demo，说是增加visualbility。一般要到下午晚些时候才能够清净些写代码，晚餐后才是代码的高峰期。这也是为什么小公司半年作出来的东西，大公司要做几年。当然大公司这样做自然有它的道理，大公司稳定，不愁客户资源，不差钱，今年做出来或是明年做出来，客户别无选择，员工也养得起。这些小公司都做不到，必须尽快的满足客户的需要，必须在钱花完之前拉到下一个项目。然而这对程序员的职业生涯来说好么，我不敢评价。只是在和很多朋友讨论的时候，他们发现，自己一直在忙啊忙，当跳槽试图总结自己做了啥的时候，却发现就不多的东西，不多的技术，当他们去面创业公司的时候，经常会被问，你们这么长时间，怎么就做了这么个东西？大公司完善的流程还有一个特点，就是这个流程是完全为此公司定制的，当然公司大，自然可以有钱从头到尾弄自己的东西，既不用常用的，也不用开源的，无论是开发工具，测试工具，代码管理工具。这也导致了员工的粘性特别强，当走出这家公司，就像换了一片天地，原来会的别人用不到，别人常用的，却不怎么会，最后只好在公司养老，好在薪水也不错，福利也不错。

最后提及的是各种美好的设施，这是很有吸引力的。然而为了您的前途，虽不能说敬而远之，也要注意享用的时间，如中午，晚上。尽量不要在工作时间娱乐，甚至喧哗，人民的眼睛是雪亮的，领导的眼睛也是雪亮的，尤其是对于软件这种成果极难量化的产品，有时候表现和态度反而成了一种指标，不像销售一样，给公司带来的是真金白银，我无论怎么玩，能拿回单子就行，然而对于软件，你有绝对的证据证明成果超越别人吗？所以外企有个很有意思的现象，一个团队的座位，离食品的距离越近越好，离娱乐设备的距离越远越好。离食品近，取用方便，领导看到你拿吃的也不会说什么，然而离娱乐设备近，领导办公室的门都开着，有谁胆敢长时间玩耍啊。所以娱乐设备上面玩耍的人一般都是座位离得比较远的。

此篇就写到这里的，在外企多年，其实发生了很多有趣的事情和现象，当走过几个外企的时候，发现有很多相似的潜规则。

进入中国的外企，其实是有中国特色的外企。中华文化的强大，使得所有的东西一到中国就会中国化，甚至改变了味道。很多民族如满族，回族的很多人都失去了原来民族的特色。也只有在中国，才可能存在儒释道三教合一的说法，不知道释迦摩尼有何感想。上学的时候，一个我很佩服的大物老师，年纪很大，他是坚定的马克思主义者，但是他曾经说，上个星期我病的厉害，差点就去见马克思了。我笑道，马克思是唯物的，是不相信死后有鬼的，死后去见阎王是迷信，去见马克思就不是了？

等有空的时候，再接着给大家讲外企的故事。

 

IT外企那点儿事(2)：多种多样的外企

不是所有的外企都是一样的，外企也分多种，基本按照地域和文化的划分可以分为日韩外企，欧企，美企。

日韩企业是十分强调等级观念的，这可能和这两个民族的文化有关。上级在下级面前总是一副严肃或者装深沉的样子，虽然其在外面有可能花天酒地，什么都做。上层和下层很少有哪怕表面上的互动，比如开玩笑，打球，年会一起表演等，所以工作环境相对的压抑，安静。甚至在伴有生产性的企业中，中午的食堂都是按照等级来的，先是管理层，然后是办公室人员如IT，行政，HR等等，最后才是蓝领的工人阶级同志，不能不说到最后像样的饭菜都比较少了，虽然自己是较先吃饭的一部分，但是看到这种情形仍然不是滋味，毕竟我们的父辈也是普普通通的工人。员工的绩效是完全由上司指定的，甚至没有解释为什么，不知道别人是多少，也很少存在如欧美企业一样哪怕形式主义的反馈，其时只有默默接受，或者走人。员工的入职薪水在外企来讲相对是很低的，每年的加薪也少可怜，其解释也是振振有词：当你的水平和贡献没有提高，凭什么公司付给你更多的薪水？所以要想薪水有较大的改善，唯一的途径就是升职，用他们的话来讲就是能做更多的贡献。日韩企业中，级别与级别之间的薪水差距是比较大的，所以一旦能够做上去，拿到的薪水可能不比欧美企业差。这也就造成了一种现象，就是日韩企业中最底层是非常不稳定的，每年大批的毕业生几乎像换水一样，一批一批几乎都走了，留下的基本就是当年就升了职的，而中层是相对稳定的，所以公司的管理也不会出什么问题。无论在哪里，一旦有了很深的等级观念，伴随而来的是管理者相对比较累，所有的决定权都在上司的手里，所以其会忙的不可开交(所有的猴子都在他的身上，请参照《哈佛经典：谁背上了“猴子”？》)，甚至管理的蛮大的Team的时候，还可能亲自写一些代码，并对每一个细节都心中有数，不像欧美的项目经理一样只管流程就可以了，甚至做的时间长一些，技术都忘了很多了。这也难怪，当下属每年流水一样几乎全走了的时候，Team lead总要保证项目能够继续下去。这多少让我想起清朝的皇帝，由于对大臣们极度的不信任，最后不得不一个个殚精竭虑，连县一级的官员都亲自任命，而明朝的皇帝很多将政务抛给宰相后，就可以逍遥自在，过自己的无厘头的生活了。说到外企，一个不可回避的问题就是天花板问题，也即多高的职位还会属于本土的中国人。日韩企业的天花板是相对较低的，不太大的官就已经是日韩人士了，因为对中国人，这两个民族似乎总是不放心的，其民族文化中多少存在一些非我族类，其心必异的倾向，所以中国人在这些企业中做不到太高的位置。所以有一种说法是，和欧美企业不同，日韩企业不能算作真正意义的跨国公司，而是分派在不同国家很多分部的日韩公司，这些分支不能够很好的本地化，不能够融入本地文化，不能包容多元文化，不能实现真正的国际化，而仅仅是接受日韩总部的指令的分支机构而已。在这里还要提及的是台湾的企业，台湾是中国领土不可分割的一部分，但是很奇怪的是，在大陆登记的时候，台企是被登记为外资企业的，而且可能是台湾被日本统治了一段时间的原因，在台企中多少有一些日本企业的影子，如等级化，天花板等，同是炎黄子孙，台湾企业似乎也对大陆的人才不能够完全的信任，看了多少心中有些不舒服。

欧企是三者之中最人性化的一类企业，尤其是北欧企业，大概和这些地区的高福利，共产主义化有关。当然天花板肯定是有的，只是相对较高，中国区的总经理一般会是是外国人，好一点的还可能是美籍华人，香港人，甚至可以使中国国籍但在美国留过学的人，然而总监一级就可能是本土的中国人了。这样的组织架构既能够和外国人很好的交流，又能够很好的本地化，适应中国文化，和本地政府交流，何乐而不为呢？欧企的等级观念也是三者之中最不明显的，管理多个Team的line manager还会在旅游之中和我们最底层的员工打牌，娱乐。公司内部的相互称呼也是叫名字，hi jack，hi peter这样的叫，无论其是多么高的高层，不会称其为王总监，刘经理此类的。欧企的加班也是比较少的，他们强调work life balance。工资相对日韩企业比较高，但相对美企来讲要低，但是福利比较好，公司会经常有吃蛋糕，开Party，旅游等活动，如果赶上公司的经营状况很好，公司给的旅游的budget是比较多的，经常可以近郊旅游，每年还能有一次出国旅游。由于较好的福利，公司是非常稳定的，每年跳槽的人很少，有的人甚至放弃美企的高薪，因为那儿比较累，舍不得这里的福利，环境，以及较好的培训机制。一个欧洲人在培训中讲，美国人是喜欢跳槽的，并不是公司不好，而是他们喜欢挑战，如果五年待在一个地方，别人会问：what is wrong with you?，而在他们国家，人们是不怎么跳槽的，他在这家公司待了20多年，他的父亲就是在这家公司退休的。这多少让我想起了我们原来的国有企业的制度，父辈退休，孩子在这个岗位接着干。难道欧洲已经到了劳动已然成为一种需求的阶段？想必这种日子说的大家心驰神往，这的确是个养老的好地方，然而对于年轻人打拼来讲，却不一定好。在此类地方，系统已经是很大很稳定的，技术进步是不太快的，可能很长时间才能修改很小一部分代码，而由于人员稳定，向上升职也是比较慢的，这样你的竞争力其实是在一步一步的下降。当公司经营状况好的情况下，大家一好百好，彼此都很开心，但是一旦遇到金融危机，公司经营状况变差的情况下，福利会急剧下滑，资本家终究是资本家，哪怕披着绅士外衣，在欧洲，由于有健全的法律，高额的赔偿，强大的工会，公司一般是不怎么敢大幅度裁员的，而中国地区就成了他们开刀的地方。当大幅度裁员后，获得了比较可观，但其实比裁一个欧洲人少得多的赔偿金后，你会发现找工作比较难了，日韩和国企你已经不适应了，那里天天的打拼如同地狱，美企好一点的则需要比较强的技术，而可能你发现你的技术能力不如刚毕业的时候了，你还记得多少的算法，操作系统，计算机网络呢？

美企是三者之中薪水最高的企业，然而压力也相对比较大。在这里你会发现，美国人有时候会很拼的，很认真的，甚至很较真的。美国人总是会规定一个任务完成的时间点，然而却常常是非常紧的。而且由于流程又长又复杂，时常弄得你焦头烂额。美国人会一遍一遍拉着你和你reveiw文档，很认真的揪出其中任何不合理的地方，甚至拼写错误。在美企，加班是经常的事情，虽然第二天早上你可以来的比较晚。所以美企也会有和欧企一样的福利制度，然而真正享用的时间比例要小的多。美企的天花板和欧企差不多，相对于欧企，美国企业多少还是有些等级在里面的，只不过不是如日韩企业显而易见的在外面，等级之间平时说笑，娱乐的时候是几乎看不出来的。然而美企心中的等级是存在的，主要体现在两个方面：邮件和开会。如果一件事情所发出的第一批邮件就包括你，则说明你属于处理这件事情的主要人员，如果你被别人转发，则在这件事情中你属于辅助地位，哪怕你和他是同一个level的，因为先知情的他可以做很多的准备，更全面的信息。如果一件事情需要开会，你在第一次的邀请中，则你也属于处理这件事情的主要人员，如果这件事情分成了多个小部分，然后让你再拉上另外一些人另外开会讨论如何处理这个小部分，在这件事情上，你就是那些人的核心，哪怕他们和你都是同一个level。这两点所有的人都心知肚明。美企有时候是强调管理扁平化的，也即事情的参与者大家没有level的差别，在这件事情上可能你是lead，在另外一件事情上他是lead，然而如果你能够很好的处理和上司及同事的关系，较多的出现在第一批发出的邮件或者第一次召开的会议中，则恭喜你，你很快就能够升职了，很快就能够脱离现在的层次，融入到另一个层次的人员的邮件和开会的博弈中去了。先知情权如此的重要以至于可以当做政治斗争的手段，在美企，用level压人到哪里都是说不过去的，然而如果事先没有足够全面的信息用邮件发给你，在开会的时候即便临时叫上你，在没有任何思考，准备和证据的情况下，哪怕你level再高，又如何能够说服别人使用你的方案呢？你总不能说：我是高级工程师，你们都是普通工程师，你们要听我的吧。都说中国人是讲面子的，其实美国人也是讲面子的，在大庭广众之下，他们总是对你的项目一口一个good，一口一个great, impressive。然而在项目中，美国人可是不讲面子的，经常challenge你，作为被领导的中国一方，经常要做的一件事情就是寻找"证据"，确确实实的证据来保证自己不会被challenge。有很多人质疑，为什么外企总是那么喜欢写文档，一遍又一遍，写到十分的细节，为什么总是喜欢写邮件，哪怕两个人就挨着坐，开会要写meeting minutes，每天要写daily report，每周要写weekly report，测试完要cc all发送测试报告，功能实现完要cc all发送邮件报告，这些都是证据啊。当问题出现的时候，每个部门不是第一时间想着如何解决这个问题，而是首先寻找证据证明自己的清白，有时候来来回回很长很长的邮件，回复了n多人，才能解决问题。美国大老说了，销售那面反应，这个功能不好用，则开发部门首先应该回：我们的design document早就发出去了，而且都review过了，当时的会议记录就是决定这样做的啊。性能测试部门说：昨天测下来，性能突然变差了，某个部门昨天提交了代码，应该是他们的问题，那个部门马上回：我们后端在代码提交之前已经做过性能测试了，报告昨天就发出去了，性能没有变差，可能是前段的问题吧。后端发现前段发来的消息不能够解析，前端应该解释：昨天我们商量的通信协议，在邮件中都能够找到啊。当有成绩了，哪怕一点小的成绩就cc all来增加影响力，当有问题的时候cc all来证明自己的清白，实在是一道美丽的风景线。每天在开会，邮件，文档，扯皮中度过，也难怪开发效率相对民企要低的多了，好在大公司有钱，不怕时间长，不怕客户恼。而对于程序员来说，技术提高不了多少，情商却是大幅度提高了，也难怪《杜拉拉升职记》能够如此的畅销。

下一篇来讲外企的面试。

 

IT外企那点儿事(3)：奇怪的面试

外企的面试都面写啥？不同的企业也是不一样的，总的来说可以归结为以下几句话：

三类企业面实战，二类企业面基础，一类企业面算法。

在此声明，此处所谓的一二三类，绝没有轻视其他企业的意思，这里的一二三类基本上是按照本科毕业的时候起薪来划分的，一类企业指的是年薪15万以上的企业，二类企业指的是年薪10万左右的企业，三类企业指的是年薪5万左右的企业。当然按照上两次的描述大家可以知道，并不是起薪高的企业的程序员一定最好发展的最好，而进入创业企业的人最后可能后来居上，成为IT达人。当然此规律也不仅仅适用于外企。

三类企业

三类企业起薪不高，招聘的目的也相对的明确，是要找那种来了就能真枪实弹的把东西作出来的人。

他们多不太关心员工的培训和成长，不太关心员工是否对技术有浓厚的兴趣和深入的钻研，他们就是一个想法，他们要做一个东西，做这个东西需要某方面的技术，所以要找这会方面的人。

他们不知道，大多数的程序员其实喜欢做一些在自己能力以上20%的东西，也即研究研究可以做出来，但不是太熟练，而不喜欢做一些自己已经非常熟，毫无挑战的东西。

但是他们需要这样的人，所以在面试中，面试的问题比较具体，甚至具体到一个个的配置项，也有当场给你环境，让你搭一个框架，做一个东西的。他们希望，最好你以前做过的项目和他们现在的项目十分相似，来了就能够上手。

其实很多程序员跳槽，就是因为原来的工作已经没有了挑战，想找一个更有挑战的，有更多大牛的地方，如果原来的项目我干的不亦乐乎，还来你这里干什么？但是现在工作难找啊，所以他们总是能够找到需要的人，毕竟出来混，大家都是混口饭吃，不容易啊。

要想进入此类企业，一个最好的办法就是上手做，在学校里就可以找个实习的公司，哪怕不给钱也去(强烈谴责这种企业，剥夺劳动者的基本权利，也就在中国他们能干的出来，放到欧美罚不死他们)，先混些实践经验，做些边角料的活，然后跟着lead一步一步进入核心模块，相信只要认认真真的做过，面过这类企业应该不成问题。

此类企业的流动性相对较大，往往被用作程序员的跳板，跳到二类甚至一类的企业中去。所以不幸进入此类企业的兄弟们，在实战的过程中，别忘了多看看源码，多想想背后的原理，多补充一下计算机科学的基本知识，早日脱离苦海。

二类企业

二类企业其实薪水已经非常不错了，毕业就能进入此类企业的程序员也多是学校中的优秀分子。

此类企业注重程序员的基础，认为只要基础好，他们愿意培训并培养程序员，给你机会进行学习。

此类企业招聘的时候，职位有可能是不太确定的，可能是Java，可能是C++，可能是windows，可能是Linux，他们认为只要你基础好，语言不是问题，平台不是问题，培训一下上手会很快。

记得面试一家与通信有关的欧企，面试官开始问了很多C/C++的基础知识，后来问了很多操作系统和计算机网络的基础知识，最后说，他们是需要有通信背景的，然后连问我三个有关通信方面的问题，我都说不知道，最后只有坦然承认，通信我确实一点都不懂。后来我认为我是彻底没希望了，没想到后来竟收到了他们的offer，并在入职后进行了长达两个月的通信方面的培训，后来我问我的面试官怎么回事，他说，你的C/C++，操作系统，计算机网络的面试题几乎都对了，我觉得你的基础不错。

所以要进入此类的企业，有关基础方面的书还是要认认真真，仔仔细细的看，下面推荐一部分：

C： 《The c programming langage》
C++：《Thinking in C++》，《The c++ programming language》，《effective c++》，《more effective c++》，《exceptional c++》，《more exceptional c++》，《inside the c++ object model》
Java：《Thinking in java》，《Core Java》，《effective java》，《Java Puzzlers》，《Java Network Programming》，《java concurrency in practice》，《深入Java虚拟机》
windows：《Windows核心编程》，《Windows Internals》
linux：《Advanced Programming in the UNIX.Environment》，《Understanding Linux Network Internals》，《UNIX Network Programming》
network：《TCPIP Illustrated Volume I》，《The Linux Networking Architecture》

我没有在装B，也不是看过以上所有的书，不过上述书籍的确是程序员必藏书，我也只不过是在用到的时候翻开相关章节看看。

然而给大家的建议是，在做项目的时候，千万不能够做什么就只知道什么，与此相关基础知识也应该多看一些。面试的时候也经常遇到这种情况，就是面试者号称做过socket，问到tcp/ip拥塞控制却一无所知，会简单使用socket client端和server端几个简单函数人太多了，如何保证你能够脱颖而出呢？

其实很多事情我们觉得不可能，但是这个世界上就是有牛人确实做到了，比如英语六级能够考99分(满分100)，就是把答案全给我，就让我写作文，我也做不到啊，再如高考满分750分，山东的状元730+分，也就意味着数理化全对，语文140+，英语140+，我的天，也是把答案给我，就让我写语文和英语的作文，我也做不到啊。

然而读以上书籍却没有上面两个例子难的不可想象，我所知道的身边的人就有C, C++, linux, network这几个分支全读过的，而且不止一个。

能进入二类的企业，混个中层，也能过上满不错的生活了。

一类企业

一类企业薪水非常高，毕业就能进入的可以说是学校中的佼佼者了，一般会名校背景，名企实习，甚至有过获奖的才能够进入。

此类企业除了注重程序员的基础之外，更加重视程序员的思想，算法及聪明程度。

所以很多奇奇怪怪的面试题在网上都流传出来了，这些题目真可谓费尽心机。面试过程长达n轮，每轮都可能因为疏漏和状态不佳被刷掉，最后剩下的几近完美。在面试中，程序是要当场在黑板上写出来的，很短的时间，要求很强的健壮性，面试官还会在旁边施加心理压力，你确定吗？要注意XXX。

虽然问题是经常外流的，然而新的问题却是不断的会出，可能是因为工作中有些需要解决的问题，自己想了一天多才想出的解决方案，却抽象出来考别人，让别人在很短的时间作出来，这种心理开始很爽，后来觉得很罪恶，多少有些原来自己穷，受富人欺负，后来富了又欺负穷人的味道。

有些人会质疑，这些精巧的算法在工作中真的能够用到很多吗？答案当然不是。

这其实是一个供需的问题。马克思告诉我们，商品的价格是由价值量决定的，商品应该以价值量为基础，实行等价交换。西方经济学告诉我们商品的价格会随着供需关系的变化而变化。当供需矛盾相当大的时候，商品的价格就会远离价值量。

《经济学的思维方式》一书中写到，所有的稀缺品都需要以某种方式分配，必须建立某种规则和制度，对那些要求得到稀缺品的人加以甄别，决定谁该得到多少。价格只是最常用的一种方式。

想想我们的高考吧，那些千辛万苦考上清华的学子毕业后又有多少高中的知识留在脑子里呢？学到的东西又有多少是能够在实际中用到的呢？其实很少，高考分数不过是进入清华的一个价格而已，已经由于清华只有一所，考生却有千百万这样的供需差别远远的偏离了使用价值，毕竟能够轻松看懂教科书的人太多了，他们只能够不但要全会，还要全对。

进入一类企业也是同样的，能把我上述书籍都看完的人是大有人在的，仅仅基础知识已经不能够甄别想进入一类企业的人们，所以需要奇奇怪怪的算法题。

要进入一类企业，《算法导论》这本书必不可少，要前前后后仔细的看，而且应该不止一遍。《编程珠玑》也是一本不错的书，其中的例子可以常常的回味。《编程之美》也不错，更贴近面试，更实用一些。其实更重要的是Top coder，就是多看多练。

其实考入名校基本就是一种方法，多做题，以便在考场中看到题目就能够有思路，考场的时间仅仅用于保证正确率就可以了。

进入一类企业也是一样，要想很短的时间，在很大的压力下写出健壮的程序，其实只有一种方法，就是类似的题目遇到过，思路是马上就有的，在会议室的时间仅仅用于保证健壮性就可以了。

曾经一段时间，对精巧的算法十分的崇尚，甚至引以为豪，然而后来慢慢发现，天天沉浸在算法之中，沉浸在计算机的小天地里面，又对社会做了什么贡献呢？难道自己的才能，抱负就仅仅放在这些数字的技巧当中吗？我们不应该像孔乙己一样研究茴香豆有几种写法，而是应该如阿朱《走出软件作坊》中描述的一样，虽然方案不是完美和精巧，然而逢山开路，遇水搭桥，真正的解决一个个的问题，作出一些可以影响人们生活的软件。

先写到这里，下一章要开始写入职了。

 

IT外企那点儿事(4)：激动人心的入职演讲

当你千辛万苦熬过了重重难关，进入了外企的大家庭之后，第一步便是入职培训了。

入职培训非常重要，尤其是对于公司来讲。当然并不是说入职培训有多大的信息量，能够学到多少技术和流程。准确的来讲，这是从心理上拿下你的一步。

我们知道，心理学上有晕轮效应，所谓晕轮效应是指人们对他人的认知判断首先是根据个人的好恶得出的，然后再从这个判断推论出认知对象的其他品质的现象。如果认知对象被标明是"好"的，他就会被"好"的光圈笼罩着，并被赋予一切好的品质；如果认知对象被标明是"坏"的，他就会被"坏"的光圈笼罩着，他所有的品质都会被认为是坏的。

所以面试中，好的第一印象十分的重要。自然企业也想在与员工的第一次亲密接触的时候，在员工心目中留下美丽的光环。

和生产性企业不同，软件开发企业的工作量和工作成果比较难以衡量，即便有了软件工程的各种理论。所以说要想使得工程师们全心全意的工作，自然是攻心为上的。工程师们大多是很清纯的，有时候多少有些高傲，有些古代的士的气质。士可杀，不可辱，所以通过严苛的纪律逼工程师工作是行不通的，他们完全可以坐在电脑前面装作认认真真的写出bug不断的代码。然而士为知己者死，如果能够让工程师感觉到公司是他事业的摇篮，是他可以托付未来的地方，是可以"明朝携剑随君去，羽扇纶巾赴征尘"的刘备式主公(《卧龙吟》)，则工程师们自然会视公司为己任，加班加点也毫无怨言，为伊消得人憔悴。

入职演讲所要起到的，就是这个效果。这也是很多民企和外企相比，有很大差距的地方。外国的资本主义已经十分成熟了，他们已经从马克思所批判的资本主义初级阶段中走出来，摆脱了通过延长劳动时间和提高劳动强度来榨取剩余价值的方式，而使用更加人性化的手段(如股份制，各种激励机制等，有大批大批的管理学大师在研究这个)，让员工自愿自觉的劳动。而中国大多数的民企，还处在马克思所批判的那个时代，从我评it的差评榜的各种评价就可见一斑了。

为了完成上述任务，入职培训一般包括以下几个方面：老大的自我介绍，重要的位置，光明的前途，优秀的员工，企业的文化，良好的福利，学长的自白，快乐的互动。

老大的自我介绍

在入职培训的时候，老大一般是会出来露一面的，即便不是一把手，也至少是二把手，三把手。

一般老大总是很和蔼的，脸上总是露出笑容的，以显示自己的平易近人。

其实有一个规律，不仅是在职场中，即越是和你层次差别大的人，对你反而是越和蔼的，而对你凝眉瞪眼，怒目狰狞的人，也多是比你也强不了哪儿去的人。一方面可能是老大确有老大的气度，一方面层次差别大，你对他构不成什么威胁，谅你也翻不过天来。这可能是为什么我们敬爱的伟大领袖毛主席可能可以容忍一个兵叛逃再回来，却不能容忍彭老总给他拍桌子的原因吧。

老大的名字应该是在业界早就如雷贯耳的，即便不是，当其简历摆在我们面前的时候，也足够我们五体投地。

一旦使得你对他形成崇拜，这第一步的目的就达到了。

其实这是任何成功学讲座的开篇的必然套路，即一拉一打，或两者兼有，或只取其一。所谓拉，就是列举出自己的一长串的title，以及自己的一系列丰功伟业；所谓打，就是提出一系列你原来没有思考过的，或者认为是显而易见却被说成错的问题。这两者的共同目的就是对其形成崇拜。崇拜可以使人们的判断力大降低，从而会减少你对他之后说的话的辨别能力。想象进入演唱会的歌迷的情绪吧，他们是如此的呐喊，以至于听不到歌手的声音，没关系，此时的歌唱质量已经无关紧要，关键是这个歌是明星唱的就可以了。其实那些造星的公司们早就摸透了这些心态，正如《长尾理论》中说的那样，“他们已经发现了制造大热门的秘密：把魅力四射的年轻男人卖给年轻的女人。成功的要点无非就是帅气的外表和打造的个性，音乐本身被外包给一小组专家，几乎成了无关紧要的事。”

在一片清纯而又崇拜的目光下，老大可以进行对公司的介绍了。

重要的位置

入职培训的另一个重要目的就是要培养你对当前获得的职位的自豪感。也即使你觉得你在做一件将影响整个软件业的意义重大的事情，自然事后你会觉得十分可笑，但当时，扪心自问，你是认真的。

培养自豪感的逻辑过程是这样的：

首先强调公司在整个IT业中的位置。如果公司能够排在整个IT业的前十位，此点不必做任何修饰。如果公司不能够排整个IT业的前十位，则会划分细分市场，直到能够排到前十名为止。如果在细分市场中能够排到第一，或者并称为几大XXX，则不必再进行修饰。如果不能，则往往冠以"仅次于XXX的XX企业"，或者当已有并称为N大XXX的时候，称为"排名第N+1的XX企业"。通过此步，多能够建立员工对企业的自豪感，能够在外面理直气壮的说出企业的名称。

然后强调研发在公司中的位置。IT企业中研发自然重要，然而当你和公司的市场人员接触过以后，他们却不全这么认为。因为市场人员是挣钱的，研发人员是花钱的，自然应该是经济基础决定上层建筑。然而研发人员是几乎接触不到市场人员的，所以此步需要明确的是在程序员心目中要树立只有他们做出了优秀的软件，公司才能够生存的信念。说到这里程序员们不要不服气，除了创业家作为程序员出身做公司的老大之外，还有那些企业的一把手是研发人员呢？一个统计的结果是，企业的一把手多出自两个部门：销售和财务。

然后应该强调中国研发中心在整个世界所有的研发中心中的位置。由于中国有廉价的劳动力和广阔的市场，很多国际大公司还是喜欢把研发中心设到中国来的，当然是以被中国很多的优秀人才吸引的名义，而总部也是比较重视中国研发中心的。然而要说中国研发中心成为整个公司研发的核心，怕你很难相信吧。中国的研发中心自然不敢凌驾于美国的研发中心之上，所以一般的措辞是，整个世界的研发中心共有N个，而美国和中国，外加另外罗列的一个或者三个研发中心成为最重要的三大或者五大研发中心。这时候，老大也许会给你看一些公司的高层在各个场合赞誉中国研发中心的语句，所有的描述如同皇帝的谥号一样，只有正面的评价，虽然他们可能对印度研发中心也说过同样的话。但没有问题，这足以使出入职场的程序员们相信这是真的，直到在项目中，他们发现只能接受美国的指令，或者没有权限参与重要的设计的时候。

最后要强调的是此一批入职者在中国研发中心中的位置。此处多会强调，此次招聘是高层早就计划好的一个长远的人才计划的一部分，你们进来参与的是具有战略意义的项目，这些项目将对公司的发展起到至关重要的作用，并处于同行业的最前沿，你们做出的产品将影响整个软件业。

就这样，通过步步推理，层层递进，员工似乎瞬间觉得从一个乳臭未干的学生，俨然将变成在软件业举足轻重的团队中的一员。此时的员工，眼中充满激情，心中充满渴望，如果不在此时此处付出自己的青春和热血，开启自己的事业，更待何时！

光明的前途

描述光辉的现在重要，描绘光明的未来更为重要，因为年轻人大多是为希望而活着的。

况且当前的社会是相对浮躁的，人们总是希望有某个机遇，通过某种捷径比别人更快的成功。记得鲁豫有约采访郭德纲的时候，他是这样描述他的北漂生活的：最初来北京，就是想找个名师拜在门下，说不定一次什么样的演出，就能够红了。不得不承认，本人当初也有这种心态，认为加入了一个无比有前途的公司，自己的事业能够得到指数级的增长。奇迹没有发生在郭德纲身上，世界上没有救世主，也不存在神仙皇帝，当自己没能够真正站立起来的时候，是不会有人怜悯你，给你捷径的。于是郭德纲开始了他长达十年的闯荡和积累，直到他成为了顶天立地的相声大腕。我自认为没有郭德纲的天赋，也是到后来才发现，一个人绝不会因为加入了某个组织从而鸡犬升天，绝不会埋头做好公司给你的每一件事情(并不一定都是有技术含量的事)从而随着公司的成功而成功，虽然加入一个好的公司是人生的催化剂，然而自己的路还是要自己来规划，自己的技术还是要靠自己一点一滴的积累，公司不会为你的前途负责，哪怕各个公司都有职业规划的系统，唯一对你前途负责的应该是你自己，所以当你前进的路上遇到阻碍，也一定是你过去的所为造成的，片面的抱怨公司和社会，是对自己的不负责任。记得看一期《中国经营者》节目采访京东CEO刘强东，当问到：如果你的企业将来面临失败，您觉得可能是什么原因？他回答：可能是因为我。不能不说，我们需要学习这种精神。

不过对于公司来讲，在员工心目中画一个大大的饼，还是很重要的。所以此处大多会提及技术路线和管理路线，并强调两者同样的重要(真的吗？我们以后讨论)。也会提及公司有成熟的职业规划系统，你和你的lead会定时一同规划你的职业发展，只要你认认真真做了公司给你的每一件事，自然前途大大的。也会提及公司会全面或者局部的扩张，总会有新的团队，新的项目出现，你会有很大的成长空间。

总之会使得我们相信，只要老子拼了，就能够很快升职，迅速到达成功的彼岸。

优秀的员工

任何人都愿意和优秀的人一起工作，所以必须让大家认识到，你们是最优秀的。

此处多会提及你们是从多少份简历中，选出多少进入笔试，又选出多少进入面试，最后拿到offer的，这个数字之间的比例和差额会让你大吃一惊，似乎没有想到自己原来这么优秀，悠然而生了一种自豪感。

用余世维讲座中的话来讲，当准入制度越严格，越能够激发员工的尊严。

用《影响力》一书的第三章承诺和一致原理来解释就是：履行一个承诺所要付出的努力越多，这个承诺对许诺者的影响越大。与不费吹灰之力就能够得到的那些东西相比，人们更加珍惜那些来之不易的东西。书中举了原始部落严酷的成人仪式和兄弟会入会的"地狱周"都会使人们对于部落和兄弟会更加的忠诚，也明确的指出跨国企业强化进入公司过程的难度，从而使新员工一旦进入公司，会有更高的忠诚度和自豪感。

企业的文化

每个企业都有自己的文化，其实差别还是蛮大的，然而令人奇怪的是，正如高中学校的校训多包涵团结，勤奋，诚实等词一样，每个企业声称自己的文化也基本包括以下的词汇：激情，挑战，平等，开放/公开，卓越，责任，结果，创新，诚实，尊重，团队，客户。

虽然不同的企业可以用同样的词汇，然而他们的文化却可以大相径庭。

其实每次的入职演讲中提及企业文化，仅仅是此文化传播的第一步，却远远不够。企业文化不是知识，不是告诉你就完成了交接的，正如不是你学会了东北话，就成了东北人一样。文化需要载体，既包括死的制度，更重要的是活的人，会在员工的不断入职和离职中发生微妙的变化。文化需要传承，需要在人与人的相互作用中发扬，如果一个企业最初只有100个人，作为文化A的载体，每过1年来10个人，作为文化B的载体，这10个人足够在一年内被熏陶成文化A，再过20年，当企业变成300人的时候，仍然差不多秉承文化A，然而如果第二年一次来了200个人，作为文化B的载体，则20年后，企业可能就更接近于文化B。文化是可以推动的，如上面的例子，如果企业想一直贯彻文化A，则需要小心的干预，同过正向激励和反向激励来推动文化A。文化不是一元的，文化下面多少会有亚文化，这就是为什么同样的公司有的Team很活泼，有的Team很沉闷。

良好的福利

公司的福利是会提及的，或以大幅的图片展示，或以精彩的视频放映，甚至会带你到现场去看，无论哪种方式，都会使你激动不已。

其实不过吃喝玩乐四大项，所谓吃，或是小吃，或是自助；所谓喝，无非饮料，咖啡，茶，酸奶；所谓玩，即各种各样的室内设施和五花八门的社团活动；所谓乐，则要提到每年的旅游，年会。总之slides上的每个人都是充满的快乐的笑容，预示着你将来美好的生活。

这些活动永远应该是你在公司活动的一小部分(否则你就大错特错了，买椟还珠，捡了芝麻，丢了西瓜)，而这些福利真的对你的职业生涯一点都不重要。

学长的自白

当然仅老大一人的独白不足以有说服力，员工们多比较相信和他们年岁，经历差不多的人的话。

所以有时候，会请你的学长现身说法，描绘他在公司里的美好生活和光明前程。

人在屋檐下，不得不低头，屁股决定脑袋，人站的位置决定了他说的话，当老大还站在旁边以期待的眼神看着学长在新员工面前侃侃而谈的时候，学长说的话除了在老大的描述上锦上添花，也别无选择了。所以你尽可将学长的话打五折去听，如果想进一步了解，请留联系方式，你们可以私下交流，这样就可以打八折听了。人生其实就像一场杀人游戏，唯一大概可以相信的就是被杀后的跳警，如果想了解最真实的情况，私下去问离了职的学长，再和在职的学长的描述融合一下，就基本可以描述客观的情况了。

快乐的互动

入职培训还常有的一项就是新员工之间的互动，让你早日得融入集体，感受主人翁的精神。

在被设计好的游戏中好好和大家交流，交交朋友吧，一般同一批进来的人比较容易建立更深的感情，而且当后来你们被分到不同的组里后，就很难有这种机会相互交流了，这毕竟是你在此企业中积累人脉，增加影响力的第一步，朋友将是职业生涯中最宝贵的财富。想想谁能够在一家企业待很久呢？可曾听说过跳槽的时候：一等人才找朋友，二等人才找猎头，三等人才网上搜。

先写到这里吧，下一篇写啥还没想好。

 

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，使得组织也成为了一棵树装。