程序员这一职业拥有极高的流动性，常常可以看到新面孔的加入和老面孔的离去，这其中既有主动辞职的，也有被动离职的情况。

与以往相比，近几年的行业竞争愈发激烈，工作任务不断增加，但收获似乎并没有相应提升，互联网行业的诱惑似乎减弱了。

在这样的人来人往、变动不居的环境中，我早已习惯了。

作为一名打工人，提升专业技能和核心竞争力是我唯一的出路，这样无论环境如何变化，无论身处何地，我都能维持生计。

今天，我想分享一个关于一位在腾讯工作四年的大佬的故事，他是通过校园招聘入职，最终选择离开。至于他离开的原因，我也并不知晓，可能是因为遇到了更好的机会，或者是觉得当前的工作对个人成长的帮助不大。

研究生毕业后，我在腾讯工作，时间转眼已过四年。虽然我个人并没有总结的习惯，但在这段时间里，我只顾着向前奔跑，忘了停下来进行反思。记得看过一份职业规划文档，提到三年一个阶段，五年一个阶段，现在正好是我的四年，也是我从腾讯离开的时机，正是总结的好时机。

首先，我想对这四年做一个简单的自评：我认为这四年并没有完全浪费或辜负。为什么这么说呢？因为与他人相比，似乎意义并不大，混得比我好的人很多，混得差的人也不少。归根结底，我不过是一个普通人，毫不惊人，技艺也不算顶尖，我接受自己的平凡，然后关注自己所做的事情是否让我感到满意。

接下来，我想具体谈谈关于工作、绩效、EPC、嫡系文化的看法，最后总结一下我的收获。

工作情况

在腾讯，我没有转岗，但参与了多个丰富的项目，包括：BUGLY、分布式调用链（Huskie）、众包系统（SOHO）和EPC度量系统。其中一些项目是对外的，一些则是内部系统，或许很多人并不熟悉。对于这些项目经历，我感到非常感激，因为它们让我在纯业务系统和偏框架系统中积累了丰富的知识。

下面简单介绍每个项目，毕竟每一个项目都凝聚了大量心血：

  • BUGLY：这是一个终端崩溃联网报告系统，许多应用程序都接入了该系统。
  • Huskie：这是一个基于Zipkin构建的分布式调用链跟踪项目。
  • SOHO：众包系统，主要将数据标准和语音采集任务众包出去。
  • EPC度量系统：研发效能度量系统，主要用于评估研发效能情况。

谈到业务开发，许多人可能与我起初一样，心中会有疑惑，整天做业务开发如何能够成长？换句话说，整天做CRUD（创建、读取、更新、删除），如何实现自我提升？我当初也曾如此疑惑，后来我的观念发生了转变。

我认为系统的复杂度可以大致分为技术复杂度和业务复杂度。对于业务系统，其业务复杂度较高，而框架系统则表现出较高的技术复杂度。这两种复杂度的解决都具有很大的挑战性。

我参与的众包系统涉及到复杂的业务逻辑，我们在这个过程中探讨并实践了领域驱动设计（DDD），这确实帮助我们简化了系统的复杂性。同时，我也体会到了DDD对后续项目的系统划分、设计以及开发的帮助。

当然，DDD并不是万能的，我并不是在夸大其功效，只是在了解它后，有时我在设计和开发时能够换一种思维方式。实际上，在业务开发中做到出色并非易事，如果能够多进行探索和实践，将一些良好的方法、思想或架构引入到工作中，对个人和业务都会有益处。

绩效情况

在腾讯的四年中，我经历了八次绩效考核，回想这四年的绩效情况为：三星、三星、五星、三星、五星、四星、四星、三星。统计下来，四星和五星的占比恰好一半。至于奖杯，这还是个不错的回忆，毕竟腾讯现在似乎已经不再发放了。

让我印象深刻的两次五星获得经历。第一次五星是在工作的第二年，那一年我负责众包项目，项目本身难度不大，因此我将部分精力投入到团队基础建设中，帮助团队搭建Java和Golang的项目脚手架，并进行了几次中心技术分享，最终得到了Leader的肯定并获得了五星奖励。看来，主动出击不仅有益于自己，也能为团队带来好处，最终也能收获回报。

第二次五星则与EPC有关。事情颇为搞笑，项目初期，总监在汇报时向老板演示系统，加载指标时耗费了很长时间，令总监很尴尬地表示正在优化。过了一段时间再次汇报时，情况依旧，总监无奈地称仍在优化。我没想到自己曾让总监如此尴尬。结果是，我自己写了一个查询引擎替代了Mondrian，之后再也没有出现那种尴尬的情况，由此我也获得了优秀绩效的鼓励。参与EPC度量项目的过程中，我感受到自己的成长，比如抗压能力，尤其是当你从零到一构建一个系统时，必然要经历承受压力与后期优化的过程。此外，若项目与数据相关，任何小问题都有可能让我紧绷神经，因此我必须尽力降低风险和故障。另一个不同的感受是，以往的项目中我大多是开发者，而在这个系统中我是Owner，作为负责人，我必须时刻对系统负责，思考系统的规划与方向，合理分配需求并掌控进度，这种角色体验与过去截然不同。

谈谈EPC

很多人对EPC提出批评或嘲笑，作为度量平台的核心开发者之一，我想分享一下我的客观看法。

EPC的初衷是非常好的，旨在通过全面多维度的研发效能指标来评估各环节的质量，从而反推业务，提升研发效能。然而，在实践过程中，我们发现客观条件并不支持（工具尚未建设好），而且一味追求指标数据，反而使得一些人想方设法美化指标，最终违背了EPC的初衷。

如果你仔细了解EPC，就会发现它是一套相当完善且先进的指标度量体系，覆盖了需求、代码、缺陷、测试、持续集成、运营与部署等各个环节。

在这一过程中，尽管部分人和业务可能存在舞弊现象，但绝大多数业务还是做出了改变，例如微视的反馈曾指出，之前的代码质量非常糟糕，实施EPC后，代码质量有了显著改善。尽管微视最终的命运并不理想，但在公司面临危机时，EPC并不能为其解救，失败也绝对不能归咎于EPC。

谈谈嫡系文化

许多人都说在腾讯，嫡系文化盛行。但实际上我觉得这种现象在许多公司都普遍存在。这也是事物发展的一种基本规律，人们通常只会信任自己熟悉且信任的人。作为领导者，难道会将重要的事情交给一个不熟悉的人吗？

我并不确定自己是否属于嫡系。曾有人在脉脉上提问“如何判断自己算不算嫡系”，其中一个回答让我印象深刻：“如果你不知道自己是否嫡系，那么你就不是。”由此看来，我或许并非嫡系。

然而，另一方面，我后期负责了团队内非常重要的事情，甚至在中心内都算是重要的项目，我独自负责一个方向，直接向总监汇报，这似乎又有些像了。

网络上还有一种观点很直接，判断是否嫡系的关键是看钱是否到位，这说法也有其道理。七级时，我获得了股票，感觉还不错。当时我以为如果没有意外，我的未来发展会顺风顺水，但不久后EPC没有达到预期，部门总经理和总监都被替换，新总监的到来又让我不得不重新建立信任。

之后，是否嫡系已不再重要，因为大环境不佳，加上裁员，大家主动或被动地几乎都离开了。

总结来说，嫡系的存在其实有其合理性。那如何才能成为嫡系呢？我自己并不清楚。不过，我认为与其思考如何成为嫡系，不如关注如何展现自己的价值与能力。当他人发现了你的价值与能力，自然会给予你更多的机会，抓住机会后，便能收获更多的福利。

再谈收获

谈到收获，个人觉得任何外在的物质、技能、职级，或是内在的感悟和认知，都可以算作是收获。

首先，我想提到一些可量化的收获：

  • 级别：我升到九级，高级工程师。尽管大家都在说腾讯的职级缩水，但我心里明白我是否具备高工的能力。通过多年的努力，我认为自己达到了当初对高工的要求。
  • 绩效：自我评价，我并不是一个特别拼命的人，或许说我不会为了拼而拼。然而，一旦我认定某项工作，我的Owner意识和责任感就会促使我做好。最终在腾讯的四年绩效也相对不错。

再谈一些其他的软技能收获：

  1. 文档能力：作为一名程序员，文档能力其实非常重要。虽然我不觉得自己的文档能力特别出色，但前后两位总监都认为我的文档质量不错，这也说明我在这一方面的能力可能高于平均水平。

  2. 明确方向：最后，我想谈一个更抽象但我认为极具价值的收获：我逐渐明确了未来的方向和目标，那就是专注于数据开发。

实际上，找到并确定一个目标并不容易，身边能明确目标的人寥寥无几，大多数人仍然处于迷茫状态。

不久前，我和人聊天时提到职业规划，可以从两个角度来思考：

  • 选择一个业务方向，例如电商或广告，不断积累该领域的知识和相关技能，最终成为专家。
  • 深入一个技术领域，钻研底层技术知识，成为该技术的专家。坦白说，虽然我深入研究和实践过领域驱动设计，并用于建模和解决复杂业务问题，但我内心更喜欢钻研技术，并对大数据领域充满兴趣。因此，我决定将未来的方向定为数据相关的工作。

在腾讯的四年，是我职业生涯的第一份工作，结识了许多优秀的人，获得了丰富的知识。最终我选择主动离开，也算是体面的告别（尽管失去了丰厚的离职礼包），我依旧心怀感激。