言传而身教，求知并实践

在我第一份实习工作里，我跟着老板学习并进入了软件开发行业；从我第一份全职工作那，我看到了工程师的不同职业路。在现在的公司里，我也获得了很多身边同事们的指导和帮助，看到了更多在行业和领域中的佼佼者。学习他们写的代码，观察他们设计的架构，与他们交流，甚至只是看着他们工作，都让我发现新的领域，加深流程理解，提速知识学习。他们让我了解到了工程师在不同阶段所作出的贡献大不相同。更可贵的是他们总是愿意抽出他们宝贵的时间给我指导，帮助我变成像他们那样杰出的工程师。

现在的公司员工数比以往的公司要多几十几百倍，所以很难像以前那样找到几个经典人物来表述，也因为公司庞大所以有着更明确的职称(Title)，所以此篇文章里我将对“位”分别描述，回顾并感谢每位同事带给我的提携和指导。

（文章比较长，主要讲述在我身边工作的Senior Engineer，Manager和Staff Engineer让我感受到的执行力(Execution)、领导力(Leadership)、主动性(Initiative)这些能力特性，也让朝着他们的方向不断的去学习获取这些能力。）

• Senior Engineer – Execution
• Engineer Manager – Leadership
• Staff Engineer – Initiative
• Title ≠ Ability – Study

Senior Engineer – Execution

以前我知道工程师会有分级，但一直不确定怎样才能算是Senior Engineer：工作很长时间？会很多种开发语言？做过很多产品？这些似乎都是评价的标准，但似乎又不足够。直到接触了组里这些真正Senior的工程师们，我才有了直观的体会。

当刚我加入Android Platform组时，我算是组里唯一的Junior工程师，Z被分配做我的入职导师，当我有任何关于公司代码的问题，都可以从他那里得到相关的解答，在最初的几个月里也由他发布工作给我，但都是些简单的修复任务。在老板眼里Z就是“Monster”，因为什么任务交给Z都能很好的完成，老板也不需要对任务做太多的解释，因为Z自己可以找出需求和难点并一一攻克。也因此老板最放心把难搞的任务交给Z。在Z的护佑下，我的工作也能变得很顺利，因为有时候我还在思考怎么解决任务的时候，他已经把代码写好提交上去了。

大概三个月后，我们组加入了另一位新同事V。他是以Senior加入的，所以我还是最低级，不过在Android方面的知识V却还是新手。虽然他也是刚加入公司，但很明显的在很短的时间里V就可以自己去找任务并从头到尾的完成下去。V对我最大的启发就是当他在工作中遇到问题时，总会到交流群或者通过邮件向整个Android组的人提出他的问题，所以就会更容易找到知道相关内容的人给出答案，有时候还能获得更多的惊喜和故事。在我遇到问题时往往偏向埋头在网上寻找答案或者自己去分析和理解，缺少交流。由于加入时间相近年龄相仿的原因，我跟V有很多话题可以交流，也经常一起打炉石，他也教我怎么制作Latte Art。

Senior Engineer的人数在公司里相对于其它级别是最多，所以这个级别的工程师的能力幅度也是最大。所以就有了像Z这样已然接近下一个级别的非常强的工程师，也有V那样刚刚升到Senior的新人。但无论是Z还是V，他们让我看到都是他们的执行力(Execution)，可以将交代的任务独立完成，并在遇到阻碍时通过交流来寻求到帮助。虽然Junior的工程师也可以完成分配的任务，但是往往需要被告知更多的任务细节，在遇到困难时也需要更多的技术指导和支持，所以执行时可能会由于时间、能力、知识面的限制而打了折扣。

Engineer Manager – Leadership

在公司里当达到了Senior Engineer的时候就可以考虑转型到Engineer Manager的方向，之后的职业道路就完全不一样了。Engineer还是专注于技术和开发方面，Manager则注重在管理和组织上。

招我进组的Manager是J，后来因为组的扩张，我们分出小组得到了另外一个Manager K，后来K转回去做Engineer，我们从外部招了新的Manager M。这三个Manager在管理上给我不同的感触，但都对我的成长和规划提供了极大的帮助。

J在行业里的时间也很有丰富的管理经验，她还有软件工程管理方面的学位，她手下的也多是工作经验丰富的Senior/Staff Engineers。她带队的方式像是开放式的散养，因为她可以很信任地把任务目标告诉我们，让我们自己去达成，不会强迫进度只让大家每周汇报一下，不会追问细节留给我们最大的自由发挥，不会担心质量因为大家的工作都很高效。因为组员太多，所以她只能每两周跟每个人进行一次1：1的会议，但即使这样也足以让我感觉到被重视。因为在这样的聊天里，J会告诉我们她对我们的期望，我们也可以向她询问组和公司的计划方向，不会变得盲目不知方向；她也会关心我们对任务的看法和意见并作出更好的决策。而我以前的公司就缺少这样的单独交流，有也是在我即将离职的时候而那时的关心和改变已经太晚了。

作为Engineer Manager，J让我看到她的工作不仅是分配任务让组员去完成公司的目标，更是要让组里人互相了解变得团结，并在愉快的气氛中工作。所以即使公司里提供午餐，我们还是会时而不时的到外边餐馆吃饭坐在一起畅谈。当然即使平时，组里也会坐在一起吃饭，聊些生活讲讲娱乐新闻。J也会在饭桌上跟我分享与工作无关的事情，比如她的小孩又做得什么滑稽的事情，最近再看那部电视剧，那本书值得阅读等等。

很多琐碎的事情J都需要去处理并能让大家都满意，我常想这要是让我去做我肯定会觉得好烦还不如让我专心敲代码。除了工作和休闲，J还要帮助组里的人规划职业，当然每个人的路怎么走是要自己决定，她更多的是指出不足和缺陷，然后用她的经验和资源帮助我们弥补。比如组里有Senior想争取Staff，她就会专门找机会留给他们一些富有挑战性和影响力的大项目；有些人需要培养带队能力，就为他们找实习生让他们去指导，或者分出一个小组给他们去带领。J对我也有期许希望我达到Senior，她对我的代码能力没有疑虑也会放心把任务交给我。但J也中肯地告诉我说我需要提高交流向更多的人展现我的工作和能力；要成为某个项目模块的拥有者(owner)，当出现问题时需要解决时就要找我；要影响和帮助更多不同的工作组；也要多参加技术讨论向其他Senior的组员提出自己的意见和方案。她不能先把我推到Senior的位置然后等我弥补不足，只有等我已经是Senior时才能升我到那个位置。

K加入公司时是Senior Engineer，做了两年开始往Manager方向转型，所以在他的管理下，我获得了更多在技术上的帮助。与K的1：1是每周一次，因此有更多机会反馈在项目上的进度已经遇到的困难。而且K不仅跟我们一样做Android的客户端，也参与过服务器方面的维护，所以从前往后都有非常全面的了解，因此我也从他那里对公司的整个系统结构有了大致的了解，而不像以前那样局限在Android的客户端应用程序上。

面对J，我总会保持着一定的畏惧感，一来她的职位比较高，二来是看她特别的忙怕打扰到她。而对K就显得更近一些，会向他提出一些请求甚至拒绝某些任务，当然都是在合情合理的范围。而且他在公司里大部分时间都是从事技术方面，所以向他寻求更多技术上的帮助，或者通过他找到其他能够给予解答的人。

另外K在任务管理上也非常的细致，会把每项任务都分门别类，再依据类别排列有限度，然后指定一个人去完成特定的类别的任务。这样当任务被创建时就不会找不到责任人。对于很多已经完成的任务，我们很多时候也没有做后序跟进，也有很多任务因为不太明确或者时间久远而被放任不管。K都会将他们一一选出来，该关闭的关闭，能解决的解决，要放弃的放弃。让每人在一定时间里的任务尽量不超过一定数量，这样就可以专心完成那些事情。所以查看他创建的任务版，即使不是我们组的人也能一目了然我们在做什么。虽然说管理和分类这些任务需要花一些额外的时间，但是这大大提高的完成任务的目的性和效率。

后来K去了另一个组做了那边的技术领队(Tech Lead)，我和其他人又回到了J的手下。但不久我们从公司外部招来了M做我们的Manager，虽然M可能不像J和K那样了解公司的产品和技术，但是她也在行业里工作了很长的时间，给管理注入新鲜的理念。

M不能告诉我Android怎么开发，但是她会告诉产品应该怎么开发，她会把她多年的经验分享给我指示我下一步应该怎么进行。我跟她的1：1会议也是每周一次，我会向她汇报任务进度和困难。我并不会从M那里直接得到问题的答案，但是她总能启示我去自己找到问题的解决方案。她会问我是否尝试过这样那样的方式，有没有问过设计师那边是什么想法，把任务拆分一下会不会更容易解决。

M最大的特点是不喜欢把项目停留在开发的某个阶段。比如我们工程师常常会对新功能加控制器(Feature Switcher)放在试验(Experiment)中，然后就忘记了。M会了解我们都在做什么任务，然后督促我们观察试验结果，尽快决定是将代码发布到产品线上，还是放弃该功能把代码删除。这样就可以减少代码库的复杂度，也减少遗留问题引发副作用的机会。

无论哪个Engineer Manager，他们在公司里是Leader而不是Boss，就像下边这张图体现的一样，他们带领着我们前进：他们强调公司的发展，也重视员工的发展；他们注意工作与生活平衡，带动起团队的效率。

我的Manager们不仅愿意帮我解决工作中的问题，他们也分享他们在生活中的经验解答我生活中的烦恼。比如J和M都有孩子，平时也会比较早下班去接孩子。将来我也会为人父，但还在职业发展初期的我总会担心孩子会影响工作，所以会问她们孩子对她们带来什么的影响。她们让我知道孩子会让你的时间不再能够自由支配，但也不会影响到工作，因为工作还是会有高的优先度，失去的则是看电影的时间，打游戏的时间，发呆的时间，出去吃饭的时间，本来被浪费的时间。而这些时间有些可能更愿意被占用到意义的事情上。孩子让她们变得忙碌，也让她们在做事情的时候变得更加的专注，因为她们需要更加合理有效地去安排时间。

Staff Engineer – Initiative

之前就说过公司里人数最多的Senior Engineer，因为只要能出色的完成公司的任务目标这一基本目标让公司持续发展下去，也就足够在公司胜任职位了。而下一级Staff Engineer就不只是做事，他们还要会主动找事。他们会发现对公司有利益和价值的项目，自己寻找完成项目所需要的人力和资源，然后达成目标，此外还会指导其他员工如何加入或利用他们的项目对公司做出更多的贡献。

在我们组里有不少的Staff Engineer，虽然他们都有上边说的特性，但他们的专长和特点又各有不同。如果说跟Senior Engineer我还能插几句我自己的想法，那么跟Staff Engineer聊天我更愿意做一个认真的聆听者，不仅因为他们的话题高度我还难以企及更因为听他们讲我能获益更多。

在我刚进组里的时候，M还是Senior，当然他早已有Staff的能力，所以在Manager安排他完成了几个杰出的项目后自然提升到了Staff的高度。一开始我跟M还不在一个项目组里所以没有直接的工作交集，只是平时大家都是一起吃饭聊天。在Manager K离开Manager M还没出现的那段时期，M作为临时Leader对我在做的任务给及了很多指导。比如指示我写设计文档并给文档提示了很多意见和修改方案，通过书写文档我也更明确我需要去实现什么样的效果而不是一团麻的在脑子里，同时文档也帮助对我做代码审核(Code Review)的同事了解我的设计意图，以后别人修改代码的时候也有有据可循。虽然写文档挺费精力，但是换回的效率却十分值得，这也让我大大体会到了写文档的好处。

后来不管我的直接Manager是谁，M都会保持跟我每周一次1：1的讨论，解答我在任务上的疑问，通过他升Staff的经验帮助我达到Senior。有时还会分享他看过的美剧和小说给我帮助我提高交流能力，所以后来我也能在餐桌上与大家聊聊《权力游戏(Game of Throne)》最期待新的一季能看到什么。

在公司发生意外事件时，M让我了解到了公司和产品的区别：公司和其运营的产品并没有绝对的相互依赖性，当一家公司走下坡或者被收购，它的产品可能依然非常有市场价值因此会一直存在下去；而公司的产品不行的时候，公司也不一定会因此倒闭，它可以放弃该项产品并寻求转型。M对产品依然保有期望，市场需要其存在，所以他愿意继续留在公司为产品做出他的贡献。当然也有很多的前车之鉴让我们看到产品的失败导致公司的崩溃，也有公司的失误导致产品的流失。

G在我们组只有几个月，在这短暂的时间里坐在G的旁边就让我感受到了高效工作的光环，也更加明确我该往技术树上添加哪些天赋。G加入我们组之后，首先明确了工作了任务目标：提升用户界面(User Interface)。接着他与设计师讨论什么样的界面是我们应该呈现给用户的，再将设计图交给我们去开发出原型，然后再转给设计师征求反馈意见。他搭建了工程师和设计师之间桥梁让我们直接的工作更加流畅。G对公司产品也有更大更广的理解，他怎会想到我们没有注意过的细节问题。比如一个简单的增加文字行距的修改，G也会强烈反对，因为他说：当间距增加屏幕一次能够显示的内容就会减少，用户查看内容就需要滚动更多次带来降低了用户体验，广告内容也可能无法完整呈现进而影响公司效益。所以虽然我们做的界面修改对产品很有意义，但是因为对用户体验冲击太大，G会控制项目一步步向外发布，并不断征求意见回来做相应的修改，这样用户就不会因为变化太大无法适应而选择放弃使用产品。

如果说Manger们告诉我“What-该做什么”，那么G就是用实际行动教授我“How-该怎么做”，以及“When-何时去做”和“Who-向谁去做”。比如Manager会让我向同事展示我做的工作成果，虽然我能懵懂的知道应该去做这件事情，但是我总不能天天在别人面前说这个那个效果是我做的吧，这样的炫耀显然是不合适的。G让我知道可以发送邮件到相关的群组告知新内容的加入，让大家留意差异的存在并寻求反馈，这样不仅让别人知道我们在做什么，也能获得更多额外的在测试和体验方面的支持。这样的邮件和展示也要在合适的时机发出，首先要保证项目本身的质量过硬，这样不会让别人看到太多的问题存在反而会得到得到负面的评价；另外也该向相关的人发送，比如Android独享功能就不要牵扯到iOS的人，设计相关就应该把设计师们都加进来，否则只会是打扰了别人的垃圾邮件。还有要把功劳分给共同完成任务的同事而非独享成果。G在很多方面都对我有指点，而且很多都是非常细节的地方，但又十分得到位，纠正了我没有意识到的却又一直犯的错误。比如对于一些我发的邮件，他会单独回复我告诉我哪些英语语法和用词我用得不对应该怎么改，这跟工作其实完全没有关系但是对我个人却获益极大。

在我们的组里其实还有很多Staff Engineers，只是我没有跟他们直接参与到同一个项目中，但跟他们简单聊上半个小时也足够让我去思考一天发现更多有趣的内容。达到了这个级别的他们，对所用知识的掌握非常的精通。J是工具组的组长，在他带领的团队为我们提供了个方面的开发工具，让协作开发变得更加的有序。每次Android Studio升级，J总会在最快时间内修复升级引起问题，让我们尽早体验到最新版本带来的便利。我们一直都对Gradle和Groovy有诸多抱怨，但是J却是这方面的专家，所以每次有关这方面的问题，我去问J远比我自己在网上搜索答案来得更快。C为公司代码的重构竭尽所能，虽说在他最开始是从事.Net开发，最近几年才转到Android使用Java，但是他对Java的精通，让我体会到了什么才是Java高级开发，而我现在会的只不过是基础语法。C对代码的维护性和重用性有非常高的要求，他写的代码干净利落，是该继承还是分类调理清晰。C在审核别人的代码时会强制要求使用Android Annotation，也给了我素材写了《Java的注解》；在代码中看到他竟然能把Android视图(View)定义成泛型(Generic)类，实现了不同类型的重用，促使我开始认真阅读和学习《Java Generics FAQs》。

Title ≠ Ability – Study

执行力(Execution)、领导力(Leadership)、主动性(Initiative)，这些就是我从身边同事身上总结出来成为杰出工程师所应该具有的特性。虽然上边我将这些特性分到了不同的级别上，但其实每个级别都需要所有这些特性：Senior Engineer也需要Leadership去带领Junior Engineer，需要Initiative去发现任务中的缺陷；Manager需要Initiative去关怀组员的发展，需要Execution去实现长期目标；Staff Engineer需要Execution去完成设计的方案，需要Leadership去带领导组件的团队。

职称(Title)并不能代表一个人的实际能力。一来每种Title下每个人的实力差距有可能会很大，不足以完全体现一个人；二来术业亦有专攻，软件行业又细分各个方向，各个方向的提升标准也不同；三来每个公司的Title都有自己的分类，有些公司只是不同的数字，再者公司之间的Title也不会等价兑换。而且公司给一个人什么Title，除了看该人的能力，更看他对公司的贡献，公司给什么样的Title，就会有什么样的预期。比如我们公司对Senior的要求就非常高，期望其能做出的贡献也要很多，若是一段时间发现其贡献不足以匹配该Title还有可能遭遇失业之灾。跳槽时不愿意匹配Title也是如此，原来公司有更高的Title只因为在原来公司里做出了很多贡献，而新加入进来不能保证能同样可以在这里做出一样的贡献。

高Title确实意味着更高的薪资和荣誉，但它更多的代表一个人在特定公司里已具有相应的能力。Title是死的，它不能被带走，但是能力是活的，会一直跟着到任何地方。因此追求Title时，我们更应该去追求该Title所对应的能力，而获得能力的方法就是不断地学习。我看到过有些同事从其他公司虽然是降级过来的，而且使用的工具和开发语言跟原先都很不一样，但是他们依然可以在半年一年里获得更高的Title。他们已经具有了上边的三种特性，他们更知道怎么去学习来保持这这三种特性。

 

其实公司里还有很多人都在方方面面给了我很多指点和帮助，他们每个人都有很强专业能力，同时又乐于将知识分享给别人让大家一起成长。我想这就是所谓的企业文化(Company Culture)。
与这么好的Managers和Teammates共事之后，我也深深体会到一个好的Team对个人的成长是多么的重要。就好像小时候不知道长大是什么滋味总在扮大人，直到真正长大了才能明白那时是多么幼稚。他们用言语指导和实际表现让我对我的职业有了更清晰的追求，也让我在今后再出现选择组的机会有了高的标准。当然在他们的熏陶之下，以及在这条职业道路上走得更远后，我相信我也具有一定的像他们这样的Leadership去指导别人应该怎么做。