秦皇岛百度网站排名,品牌策划与管理,wordpress调查问卷插件,互联网推广seoIT外企那些事 外企#xff0c;一个听起来似乎充满光环的名字#xff0c;每年众多大学毕业生向往的地方。 说起外企#xff0c;总能让人联想到很多令人心动的名词#xff1a;高薪#xff0c;人性化#xff0c;浮动工作制#xff0c;年假#xff0c;完善的流程#xff… IT外企那些事 外企一个听起来似乎充满光环的名字每年众多大学毕业生向往的地方。 说起外企总能让人联想到很多令人心动的名词高薪人性化浮动工作制年假完善的流程各种福利如旅游室内乒乓球台健身房按摩椅小食品酸奶…… 然而真正进入了外企时间长了也就发现其实外企也就那么回事。 高薪所谓高薪严格意义上来讲是高起薪也即刚毕业的时候每个企业公开的秘密同学们总能够从师哥师姐那里打听到这个数字有的企业甚至爆出较去年惊人的数字来做宣传。一个个光鲜的数字吸引着尚未毕业的大学生们宣讲会的人数是基本和这个数字成正比的。 然而由于大多数的外企由于规模比较大机构也相对的稳定高起薪的背后是稳定的加薪每年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 reviewbug review。 每个项目组作了一个阶段后给整个项目组的demo甚至给整个group及老外demo说是增加visualbility。 一般要到下午晚些时候才能够清净些写代码晚餐后才是代码的高峰期。 这也是为什么小公司半年作出来的东西大公司要做几年。当然大公司这样做自然有它的道理大公司稳定不愁客户资源不差钱今年做出来或是明年做出来客户别无选择员工也养得起。这些小公司都做不到必须尽快的满足客户的需要必须在钱花完之前拉到下一个项目。 然而这对程序员的职业生涯来说好么我不敢评价。只是在和很多朋友讨论的时候他们发现自己一直在忙啊忙当跳槽试图总结自己做了啥的时候却发现就不多的东西不多的技术当他们去面创业公司的时候经常会被问你们这么长时间怎么就做了这么个东西 大公司完善的流程还有一个特点就是这个流程是完全为此公司定制的当然公司大自然可以有钱从头到尾弄自己的东西既不用常用的也不用开源的 无论是开发工具测试工具代码管理工具。这也导致了员工的粘性特别强当走出这家公司就像换了一片天地原来会的别人用不到别人常用的却不怎么 会最后只好在公司养老好在薪水也不错福利也不错。 设施最后提及的是各种美好的设施这是很有吸引力的。然而为了您的前途虽不能说敬而远之也要注意享用的时间如中午晚上。 尽量不要在工作时间娱乐甚至喧哗人民的眼睛是雪亮的领导的眼睛也是雪亮的尤其是对于软件这种成果极难量化的产品有时候表现和态度反而成了 一种指标不像销售一样给公司带来的是真金白银我无论怎么玩能拿回单子就行然而对于软件你有绝对的证据证明成果超越别人吗 所以外企有个很有意思的现象一个团队的座位离食品的距离越近越好离娱乐设备的距离越远越好。离食品近取用方便领导看到你拿吃的也不会说什么然而离娱乐设备近领导办公室的门都开着有谁胆敢长时间玩耍啊。所以娱乐设备上面玩耍的人一般都是座位离得比较远的。 此篇就写到这里的在外企多年其实发生了很多有趣的事情和现象当走过几个外企的时候发现有很多相似的潜规则。 进入中国的外企其实是有中国特色的外企。中华文化的强大使得所有的东西一到中国就会中国化甚至改变了味道。很多民族如满族回族的很多人都失 去了原来民族的特色。也只有在中国才可能存在儒释道三教合一的说法不知道释迦摩尼有何感想。上学的时候一个我很佩服的大物老师年纪很大他是坚定 的马克思主义者但是他曾经说上个星期我病的厉害差点就去见马克思了。我笑道马克思是唯物的是不相信死后有鬼的死后去见阎王是迷信去见马克思 就不是了 等有空的时候再接着给大家讲外企的故事。 ######################################################## 不是所有的外企都是一样的外企也分多种基本按照地域和文化的划分可以分为日韩外企欧企美企。 日韩企业日韩企业是十分强调等级观念的这可能和这两个民族的文化有关。 上级在下级面前总是一副严肃或者装深沉的样子虽然其在外面有可能花天酒地什么都做。 上层和下层很少有哪怕表面上的互动比如开玩笑打球年会一起表演等所以工作环境相对的压抑安静。 甚至在伴有生产性的企业中中午的食堂都是按照等级来的先是管理层然后是办公室人员如IT行政HR等等最后才是蓝领的工人阶级同志不能 不说到最后像样的饭菜都比较少了虽然自己是较先吃饭的一部分但是看到这种情形仍然不是滋味毕竟我们的父辈也是普普通通的工人。 员工的绩效是完全由上司指定的甚至没有解释为什么不知道别人是多少也很少存在如欧美企业一样哪怕形式主义的反馈其时只有默默接受或者走人。 员工的入职薪水在外企来讲相对是很低的每年的加薪也少可怜其解释也是振振有词当你的水平和贡献没有提高凭什么公司付给你更多的薪水所以要想薪水有较大的改善唯一的途径就是升职用他们的话来讲就是能做更多的贡献。 日韩企业中级别与级别之间的薪水差距是比较大的所以一旦能够做上去拿到的薪水可能不比欧美企业差。这也就造成了一种现象就是日韩企业中最底 层是非常不稳定的每年大批的毕业生几乎像换水一样一批一批几乎都走了留下的基本就是当年就升了职的而中层是相对稳定的所以公司的管理也不会出什 么问题。 无论在哪里一旦有了很深的等级观念伴随而来的是管理者相对比较累所有的决定权都在上司的手里所以其会忙的不可开交(所有的猴子都在他的身 上请参照《哈佛经典谁背上了“猴子”》)甚至管理的蛮大的Team的时候还可能亲自写一些代码并对每一个细节都心中有数不像欧美的项目经理 一样只管流程就可以了甚至做的时间长一些技术都忘了很多了。 这也难怪当下属每年流水一样几乎全走了的时候Team lead总要保证项目能够继续下去。这多少让我想起清朝的皇帝由于对大臣们极度的不信任最后不得不一个个殚精竭虑连县一级的官员都亲自任命而明朝 的皇帝很多将政务抛给宰相后就可以逍遥自在过自己的无厘头的生活了。 说到外企一个不可回避的问题就是天花板问题也即多高的职位还会属于本土的中国人。 日韩企业的天花板是相对较低的不太大的官就已经是日韩人士了因为对中国人这两个民族似乎总是不放心的其民族文化中多少存在一些非我族类其心必异的倾向所以中国人在这些企业中做不到太高的位置。 所以有一种说法是和欧美企业不同日韩企业不能算作真正意义的跨国公司而是分派在不同国家很多分部的日韩公司这些分支不能够很好的本地化不能够融入本地文化不能包容多元文化不能实现真正的国际化而仅仅是接受日韩总部的指令的分支机构而已。 在这里还要提及的是台湾的企业台湾是中国领土不可分割的一部分但是很奇怪的是在大陆登记的时候台企是被登记为外资企业的而且可能是台湾被 日本统治了一段时间的原因在台企中多少有一些日本企业的影子如等级化天花板等同是炎黄子孙台湾企业似乎也对大陆的人才不能够完全的信任看了多 少心中有些不舒服。 欧企欧企是三者之中最人性化的一类企业尤其是北欧企业大概和这些地区的高福利共产主义化有关。 当然天花板肯定是有的只是相对较高中国区的总经理一般会是是外国人好一点的还可能是美籍华人香港人甚至可以使中国国籍但在美国留过学的 人然而总监一级就可能是本土的中国人了。这样的组织架构既能够和外国人很好的交流又能够很好的本地化适应中国文化和本地政府交流何乐而不为呢 欧企的等级观念也是三者之中最不明显的管理多个Team的line manager还会在旅游之中和我们最底层的员工打牌娱乐。公司内部的相互称呼也是叫名字hi jackhi 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来证明自己的清白实在是一道美丽的风景线。每天在开会邮件文档扯皮中度过也难怪开发效率相对民企要低的多了好在大公司有钱不怕时间 长不怕客户恼。而对于程序员来说技术提高不了多少情商却是大幅度提高了也难怪《杜拉拉升职记》能够如此的畅销。 下一篇来讲外企的面试。 ################################################################# 外企的面试都面写啥不同的企业也是不一样的总的来说可以归结为以下几句话 三类企业面实战二类企业面基础一类企业面算法。在此声明此处所谓的一二三类绝没有轻视其他企业的意思这里的一二三类基本上是按照 本科毕业的时候起薪来划分的一类企业指的是年薪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。 虽然问题是经常外流的然而新的问题却是不断的会出可能是因为工作中有些需要解决的问题自己想了一天多才想出的解决方案却抽象出来考别人让别人在很短的时间作出来这种心理开始很爽后来觉得很罪恶多少有些原来自己穷受富人欺负后来富了又欺负穷人的味道。 有些人会质疑这些精巧的算法在工作中真的能够用到很多吗答案当然不是。 这其实是一个供需的问题。马X克X思告诉我们商品的价格是由价值量决定的商品应该以价值量为基础实行等价交换。西方经济学告诉我们商品的价格会随着供需关系的变化而变化。当供需矛盾相当大的时候商品的价格就会远离价值量。 《经济学的思维方式》一书中写到所有的稀缺品都需要以某种方式分配必须建立某种规则和制度对那些要求得到稀缺品的人加以甄别决定谁该得到多少。价格只是最常用的一种方式。 想想我们的高考吧那些千辛万苦考上清华的学子毕业后又有多少高中的知识留在脑子里呢学到的东西又有多少是能够在实际中用到的呢其实很少高考 分数不过是进入清华的一个价格而已已经由于清华只有一所考生却有千百万这样的供需差别远远的偏离了使用价值毕竟能够轻松看懂教科书的人太多了他们 只能够不但要全会还要全对。 进入一类企业也是同样的能把我上述书籍都看完的人是大有人在的仅仅基础知识已经不能够甄别想进入一类企业的人们所以需要奇奇怪怪的算法题。 要进入一类企业《算法导论》这本书必不可少要前前后后仔细的看而且应该不止一遍。《编程珠玑》也是一本不错的书其中的例子可以常常的回味。《编程之美》也不错更贴近面试更实用一些。其实更重要的是Top coder就是多看多练。 其实考入名校基本就是一种方法多做题以便在考场中看到题目就能够有思路考场的时间仅仅用于保证正确率就可以了。 进入一类企业也是一样要想很短的时间在很大的压力下写出健壮的程序其实只有一种方法就是类似的题目遇到过思路是马上就有的在会议室的时间仅仅用于保证健壮性就可以了。 曾经一段时间对精巧的算法十分的崇尚甚至引以为豪然而后来慢慢发现天天沉浸在算法之中沉浸在计算机的小天地里面又对社会做了什么贡献呢难道自己的才能抱负就仅仅放在这些数字的技巧当中吗 我们不应该像孔乙己一样研究茴香豆有几种写法而是应该如阿朱《走出软件作坊》中描述的一样虽然方案不是完美和精巧然而逢山开路遇水搭桥真正的解决一个个的问题作出一些可以影响人们生活的软件。 先写到这里下一章要开始写入职了。 ########################################################### 当你千辛万苦熬过了重重难关进入了外企的大家庭之后第一步便是入职培训了。 入职培训非常重要尤其是对于公司来讲。当然并不是说入职培训有多大的信息量能够学到多少技术和流程。准确的来讲这是从心理上拿下你的一步。 我们知道心理学上有晕轮效应所谓晕轮效应是指人们对他人的认知判断首先是根据个人的好恶得出的然后再从这个判断推论出认知对象的其他品质的现 象。如果认知对象被标明是好的他就会被好的光圈笼罩着并被赋予一切好的品质如果认知对象被标明是坏的他就会被坏的光圈笼罩着他 所有的品质都会被认为是坏的。 所以面试中好的第一印象十分的重要。自然企业也想在与员工的第一次亲密接触的时候在员工心目中留下美丽的光环。 和生产性企业不同软件开发企业的工作量和工作成果比较难以衡量即便有了软件工程的各种理论。所以说要想使得工程师们全心全意的工作自然是攻心 为上的。工程师们大多是很清纯的有时候多少有些高傲有些古代的士的气质。士可杀不可辱所以通过严苛的纪律逼工程师工作是行不通的他们完全可以坐 在电脑前面装作认认真真的写出bug不断的代码。然而士为知己者死如果能够让工程师感觉到公司是他事业的摇篮是他可以托付未来的地方是可以明朝携 剑随君去羽扇纶巾赴征尘的刘备式主公(《卧龙吟》)则工程师们自然会视公司为己任加班加点也毫无怨言为伊消得人憔悴。 入职演讲所要起到的就是这个效果。这也是很多民企和外企相比有很大差距的地方。外国的资本主义已经十分成熟了他们已经从马克思所批判的资本主 义初级阶段中走出来摆脱了通过延长劳动时间和提高劳动强度来榨取剩余价值的方式而使用更加人性化的手段(如股份制各种激励机制等有大批大批的管理 学大师在研究这个)让员工自愿自觉的劳动。而中国大多数的民企还处在马克思所批判的那个时代从我评it的差评榜的各种评价就可见一斑了。 为了完成上述任务入职培训一般包括以下几个方面老大的自我介绍重要的位置光明的前途优秀的员工企业的文化良好的福利学长的自白快乐的互动。 老大的自我介绍在入职培训的时候老大一般是会出来露一面的即便不是一把手也至少是二把手三把手。 一般老大总是很和蔼的脸上总是露出笑容的以显示自己的平易近人。 其实有一个规律不仅是在职场中即越是和你层次差别大的人对你反而是越和蔼的而对你凝眉瞪眼怒目狰狞的人也多是比你也强不了哪儿去的人。 一方面可能是老大确有老大的气度一方面层次差别大你对他构不成什么威胁谅你也翻不过天来。这可能是为什么我们敬爱的伟大领袖毛主席可能可以容忍一个 兵叛逃再回来却不能容忍彭老总给他拍桌子的原因吧。 老大的名字应该是在业界早就如雷贯耳的即便不是当其简历摆在我们面前的时候也足够我们五体投地。 一旦使得你对他形成崇拜这第一步的目的就达到了。 其实这是任何成功学讲座的开篇的必然套路即一拉一打或两者兼有或只取其一。所谓拉就是列举出自己的一长串的title以及自己的一系列丰 功伟业所谓打就是提出一系列你原来没有思考过的或者认为是显而易见却被说成错的问题。这两者的共同目的就是对其形成崇拜。崇拜可以使人们的判断力大 降低从而会减少你对他之后说的话的辨别能力。想象进入演唱会的歌迷的情绪吧他们是如此的呐喊以至于听不到歌手的声音没关系此时的歌唱质量已经无 关紧要关键是这个歌是明星唱的就可以了。其实那些造星的公司们早就摸透了这些心态正如《长尾理论》中说的那样“他们已经发现了制造大热门的秘密把 魅力四射的年轻男人卖给年轻的女人。成功的要点无非就是帅气的外表和打造的个性音乐本身被外包给一小组专家几乎成了无关紧要的事。” 在一片清纯而又崇拜的目光下老大可以进行对公司的介绍了。 重要的位置入职培训的另一个重要目的就是要培养你对当前获得的职位的自豪感。也即使你觉得你在做一件将影响整个软件业的意义重大的事情自然事后你会觉得十分可笑但当时扪心自问你是认真的。 培养自豪感的逻辑过程是这样的 首先强调公司在整个IT业中的位置。如果公司能够排在整个IT业的前十位此点不必做任何修饰。如果公司不能够排整个IT业的前十位则会划分细分 市场直到能够排到前十名为止。如果在细分市场中能够排到第一或者并称为几大XXX则不必再进行修饰。如果不能则往往冠以仅次于XXX的XX企 业或者当已有并称为N大XXX的时候称为排名第N1的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上的每个人都是充满的快乐的笑容预示着你将来美好的生活。 这些活动永远应该是你在公司活动的一小部分(否则你就大错特错了买椟还珠捡了芝麻丢了西瓜)而这些福利真的对你的职业生涯一点都不重要。 学长的自白当然仅老大一人的独白不足以有说服力员工们多比较相信和他们年岁经历差不多的人的话。 所以有时候会请你的学长现身说法描绘他在公司里的美好生活和光明前程。 人在屋檐下不得不低头屁股决定脑袋人站的位置决定了他说的话当老大还站在旁边以期待的眼神看着学长在新员工面前侃侃而谈的时候学长说的话 除了在老大的描述上锦上添花也别无选择了。所以你尽可将学长的话打五折去听如果想进一步了解请留联系方式你们可以私下交流这样就可以打八折听 了。人生其实就像一场杀人游戏唯一大概可以相信的就是被杀后的跳警如果想了解最真实的情况私下去问离了职的学长再和在职的学长的描述融合一下就 基本可以描述客观的情况了。 快乐的互动入职培训还常有的一项就是新员工之间的互动让你早日得融入集体感受主人翁的精神。 在被设计好的游戏中好好和大家交流交交朋友吧一般同一批进来的人比较容易建立更深的感情而且当后来你们被分到不同的组里后就很难有这种机会 相互交流了这毕竟是你在此企业中积累人脉增加影响力的第一步朋友将是职业生涯中最宝贵的财富。想想谁能够在一家企业待很久呢可曾听说过跳槽的时 候一等人才找朋友二等人才找猎头三等人才网上搜。 先写到这里吧下一篇写啥还没想好。 ############################################################ 进行完入职培训便开启了你在外企中的程序人生了需要说明的是此文章不仅限外企。 如果待足够长的时间你将从程序员高级程序员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 sharingcode 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业的技术变化太快弄的技术人员疲于奔命。年轻人可以每天晚上几个小时的看新技术的书籍而年纪偏大的你上有老下有小做饭洗衣陪老 婆照顾老人小孩逛超市每天能有一个小时的学习时间十分不易了。如果是你已经很熟悉的领域你自然可以用较少的时间就能达到年轻人较长时间看完的东西 (理想状态下)然而公司的项目所用的技术方向可不是随你心愿的。如果你是一个Java高手碰巧公司买的一个第三方的库是用C写的需要对其进行封 装如此艰巨的任务工程师中你的薪水最高你不入地狱谁入地狱啊。你总不能说我只负责Java的部分C的别来找我吧。 也许你经常听领导说“编程主要靠思想语言和平台无所谓”。然而如果你跳槽的时候却经常听到面试官这样说“好像你没有太多这方面的经验嘛” 你却不能以我很有编程的思想来回答。此矛盾之处着实使人困惑许久。技术路线还是分很多的方向的正如武林有很多的门派。语言操作系统等属于内功然而只 有内功却不足以行走江湖必须还要有一定的套路如Debug toolprofile 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其三Id 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的时候你是否给过真诚的赞誉帮其增加上述的影响力 当同事帮助你解决了问题或者提出了优秀的方案你是否公开表示感谢让群众和领导都知晓 当领导问及你做的模块的时候你是否有意隐瞒了他人的功劳而突出自己的贡献 当会议的时候你是否会处心积虑的故意反对竞争对手的方案虽然你觉得其实这真的是个好方案 当发现其他人的BugCode reivew的时候发现他人的设计缺陷你是否幸灾乐祸的大声疾呼唯恐他人和领导不知 你是否在同事领导HR的面前非议他人嘲笑他人的设计褒贬他人的缺陷鄙视他人的技术虽然的确你是此方面的大拿 当你有幸获得一份荣誉的时候你是否先谢国家(公司)再谢政府(团队)再谢领导再谢同事 给别人光环吧别人也会给你光环。 一个只顾自己头上光环的人以及一个别人给了光环而不知回报的人最终都会孤立无援难以开展工作是涸泽而渔的做法。 我们必须承认的一点是每个人都有自己的长处也有自己的短处每个模块都有优美的地方也有不尽人意的地方你有你擅长的技术别人也有别人擅长 的方向。如果大家互相向别人的头上套光环则外人和领导看到的会多数是光环从而大家精诚合作团队蒸蒸日上。如果大家全部互相揭疮疤则外人和领导则看 到的会多数是负面的从而大家互相猜忌整个团队都没有希望。 历朝历代都有权臣权臣之间必有党争派别之间多知道对方的优势也掌握了对方的把柄如果派系之间相互合作则大家都会壮大皇帝则不会知道下面的暗流涌动然而英明的皇帝多挑拨派系之间的关系使他们互相揭露对方的把柄从而下情上达从中制衡。 我们也会经常看到当一家公司的高管离开他的老东家而投奔新东家的时候公开场合下此高管多会十分赞誉在老东家中工作过的时光赞誉工作过的团 队赞誉老东家的产品和项目赞誉自己在老东家取得的进步而老东家也多会给与此高管十分积极的评价肯定其作出的贡献其为公司带来的价值其培养出的 团队。其实如果两者之间如此的默契如此的互相满意就不会发生跳槽的事件了既然选择分道扬镳则其中必有隔阂只不过互相心知肚明各不言明罢了。这 样无论对公司的发展还是对此高管的职业生涯都有好处。试想此高管必然是清清楚楚公司的优势劣势公司也明明白白高管的功过是非就像一对生活了很久的 夫妻既知道你能言善辩也知道你鼾声震天既知道你玉树临风也知道你不爱洗澡如果在公开场合互相指责甚至谩骂岂不家丑外扬 (7) Daily report和weekly report很重要 很多程序员宁愿多写程序也不愿意写report觉得十分麻烦而又无聊。 但是Daily reportweekly 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的情况下你才能做到充实自己努力学习才能了解上司的言语——让上司轻松你才能够做到对自己的业务主动提出改善计划——让上司进步。 转载于:https://www.cnblogs.com/liuzhuqing/p/7480308.html
