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

还记得在读书的时候,就对程序员有种坐在电脑前疯狂敲代码的刻板印象。工作以后,逐渐理解了软件工程师的工作到底是怎么样的,可是写代码,作为软件工程师最重要的本职工作,还是占据了相当比重的时间。在面试别人的时候,也经常被问到这样的问题——“平均你每天有多少时间花在写代码上?”,这个问题看似简单,却能反映出一个问题,软件工程师,能否有足够的时间专注在最本职工作——写代码上。毫无疑问,我完全理解这样的问题,并且,我也一直以来想保持着自己一个 “纯粹” 程序员的身份。我觉得我的职业通道也是一条纯粹的技术人的道路,因而写代码,是一个如同每天吃饭喝水一样的基本操作。

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

团队的变化

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

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

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

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

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

我自己的变化

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

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

产品或特性的规划

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

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

技术架构

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

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

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

管理、沟通和协调

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

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

Mentoring

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

招聘

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

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

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

1,563 次阅读

Leave a Reply

Your email address will not be published.

back to top