转载

哎，写代码的时间真的越来越少了……

可是，随着职业生涯的进展，特别是近半年来的一系列变化，我已经明显感受到，这已经发生了变化，曾经的理所应当不再是理所应当。这个变化会带来什么，除去不断的思考，时间会告诉我更多。

团队的变化

在建立初期，OCI 更偏向于招纳更有经验的工程师，因为那个时候 “打地基”、“搭框架” 的工作潜在的影响力，和犯错的可能更为巨大，这样的工作不只是云服务本身的建设，还包括团队和流程体系的打磨。但是逐渐地，随着团队的扩张，招人的策略也发生了明显的变化：

更多的初级职位，更多地吸纳经验较少的工程师，特别是毕业生；
对于高级别的职位，需求量减少，要求的标准相对而言可能有所提高。

其实这也没有什么难以理解的，现在无论是技术人还是管理人，不管是 IC（Individual Contributor）岗还是 M（Manager）岗，大家都对级别和对应的能力和贡献的期望愈发清晰。换言之，就是很明确什么样的工作，交给什么样能力的人去做。这样一来，大多数团队对具备不同能力和经验的软件工程师的需求，也变成了塔状，即经验较少的工程师占较大（60% 以上）的比重。于是，在能够达成目的的基础上，使用这样的模式，可以更好地控制团队的薪酬成本，同时，不同的工程师也可以得到相对合适的挑战。

另一方面，团队负责的项目的规模还在逐渐扩大。团队重新划分过几次，如今我们也肯定是一个全栈式团队（对全栈式团队有疑惑的可以参见我在专栏中的解读），而团队拥有的产品里面，既有数据中心的数据服务，有分布式工作流引擎，还有内部使用的可视化工具网站，并且可以说是既有平台，又有业务。因此对于大部分计算机相关专业毕业的软件工程师，都可以在我们团队找到感兴趣的方向。（题外话，目前由于新冠病毒造成的影响，OCI 的招聘暂停，但是预计在数周后会逐步恢复，对我们团队感兴趣的可以和我联系，不过工作地点只有西雅图。）

这三个产品可以说每一个所对应的最大挑战都不相同，但是配合起来，大的目标是一致的，就是为数据中心，特别是新建数据中心服务，既包括流程自动化，又包括数据存取和展示。

我自己的变化

回想工作最初的几年，特性和功能开发是时间花费最主要的地方，也是最多的 “写代码” 的原因。如今，这件事情肯定已经跌出前三了。

这半年来，我自身的角色也发生了比较大的变化，现在除去一如既往地负责单个产品本身的主要项目，还需要牵线那些各个产品负责的子团队协作来完成的工作。而在项目和团队中实际做的事情，也有了明显变化。总的来说，下面这些事情，时间占用出现了大幅度的上升：

产品或特性的规划

早些年我的理解，对于产品或特性的规划，应该是 TPM 或者产品经理这样的角色来完成的，但是其实这是不准确的。事实上，一方面，有很多工作确实是需要有足够技术背景的人去完成；而另一方面，本身对于多数项目来说这样的角色已经很模糊了，一个不深入理解业务和产品的 IC？不可能的。

对于我们团队来说，TPM 能够提供这样三个方面的帮助：业务、项目和客户。但是，有许多产品或特性的规划，基本上这三个都不相关，完全是工程师的活儿。比如说分布式工作流引擎，业务线和技术线是可以分得比较清楚的：下面的平台本身是业务无关的，而在其之上跑着的的业务工作流却相反。因此，对于其中技术层面的规划设计，也包括将业务怎样落地梳理清楚，只有工程师才能完成。

技术架构

这部分其实接近于我在读书时期对于架构师狭隘的理解。

事实上，我了解到，对于很多真正参与这方面工作的人来说，真正的纯技术架构工作，占比并不会非常大。这一方面是由于，并没有那么多产品长期处于 “初创期” 或者 “转型期”，需要大量的架构工作；另一方面，则是因为一切的技术架构都是建立在业务和需求清晰的基础之上，而做到这一基础已经需要巨大的时间精力投入了。

值得一提的是，这样的工作需要一些考察和探索，比如做技术选型和快速原型。有时候也会涉及一部分编码。总的来说，这其实是我比较喜欢的事情。

管理、沟通和协调

这部分我描述得很笼统，并且有一点像管理岗的工作了。或多或少，这是一个 IC 不可避免的职责。理想状况下研发经理理应承担更多这方面的工作，但是我们的团队人手方面，这样的角色数量不足够，因而 IC 需要更多地承担这方面的工作。当然，即便能做到理想状况，沟通和协调于我而言，依然会占据相当的比重。

对于我们团队而言，偏重技术方面的需求比较多，因此需要软件工程师更多的参与。事实上，我们每一个产品/子团队都有 lead，他们都会主导或重度参与每一个 Sprint 的任务规划。这也再一次印证了，对于 IC 来说，随着职业生涯的发展，角色定位就是会越来越 “模糊”。

Mentoring

在我们团队，目前工作经验较少的工程师比较多，因此 mentoring 是一件比较重要的事情（除此之外，这个状况也是对于 dev manager 需求比较强烈的原因之一）。当然，这部分时间开销，也可以归纳到上面的 “管理、沟通和协调” 当中去。

招聘

上面说的是团队内的时间开销，而在跨团队的 OCI 层面，有这样两项内容花费了显著的时间：一个是设计评审，另一个就是招聘。而对工程师来说，这件事基本围绕面试展开。对于这个话题，鉴于之前已经说过几次了（比如这一篇和这一篇），在此就不展开了。

对于角色上的变化，我依然在逐步适应中，寻找最适合自己的方式。而对于写代码这个事情，时间确实是越来越少了，不知道一个合适的解决方法是什么？当然，我并不想去狭隘和片面地追求编码时间，但是我知道，编码是一件常练常新的基本功。在工作中，到底应该怎样更有效地分配时间，平衡包括编码在内的各种各样的事情，希望我可以很快把这个问题考虑清楚……

原文 https://www.raychase.net/6099

正文到此结束