一位高级软件工程师的自述：这个职位到底要做什么工作？

本文作者 Joy Ebertz 接触过的几乎每一家软件公司都设有技术晋升与管理晋升两条职业道路，这意味着如果只走技术方向，技术人员也完全可以在不出任管理职务的前提下达到相同的高阶职级。但与此同时，Joy Ebertz 所参加的几乎所有职业演讲或讨论小组都充斥着管理人员。现在，Joy Ebertz 终于明白从宏观层面来看，管理者到底需要做什么、管理的晋升通道又是怎么一回事。

无论是在公司内还是公司外，管理晋升通道中的高层都有着更高的知名度。技术高管也是如此，但对于负责技术的中层管理人士，很多人可能就有点摸不清底细了。

在这里，我先给大家交个实底：在第一次接触软件行业时，如果大家问我 10 到 15 年之后想要做什么工作，我首先想到的答案无疑是软件架构师。我对管理岗位没有太大兴趣，而且我知道架构师是技术道路上最资深的人群。然而，那时的我并不清楚架构师到底需要做什么，当时想到这个答案的原因无非是野心与想证明自己的渴望。但恰巧，我后来的发展道路或多或少遵循了当初的心愿，只是现在的我更清楚担任高级技术管理者意味着什么。

工程技术角色汇总

我现在是一名高级软件工程师，但这究竟是干嘛的？虽然具体的头衔与职能划分取决于具体的企业，但根据我们利用谷歌搜索结果进行的建模，整个行业内的定位思路大体相似。我最初是一名软件工程师（简称 SWE），而后是高级软件工程师（Sr SWE），经历了短暂的管理适应周期后，我最终晋升为高级管理人员。在此之上，还有首席工程师与研究员等职位，不过据我所知我们公司好像还没有真正的研究员。另外让人有点犯迷糊的是，前两个阶段其实基本是统一的；这意味着即使工作内容相同，在高层管理者看来，不同员工之间仍然存在着巨大的差异。

根据与高级软件工程师的交流，对于较低职级，企业当然希望员工尽可能展现自己的技能与才华。我们希望每位晋升为高级软件工程师的员工都能在一切领域（例如技术技能、领导力、文化与价值观等）中充分展现自己的水平，在各项指标中至少达到标准要求，同时掌握高级工程师所必需的一切技能。

值得强调的是，各个职级的工作内容略有不同。正因为如此，虽然我们希望员工能够从高级软件工程师开始一步步成长上来，但技术人员也完全可以在接下来的职业生涯中出任同样的职务。如果有人就是喜欢做高级软件工程师，而对主管工程师没有兴趣，那我们也充分尊重这样的选择。

在我看来，随着时间的推移，对角色变化最简单的描述方式就是观察其在影响力层面的变化。具体来讲，我们可以通过如下几个角度来审视：要么就是能够产生更广泛的影响，要么就是能够产生更深远的影响。具体来说，我们可以影响很多团队，或者对单一团队产生重大影响。我们也可以用另一种方式来理解：以编写代码为例，我们可以编写一部分超级重要或者超级复杂的代码，从而影响某一特定业务区域的运作方式；也可以指导他人进行编码最佳实践，或者对多项设计提出意见或者影响其决策方式，从而产生更广泛的影响。

说到这里，我的阐述可能还是有点抽象和宽泛。下面继续深入聊聊高级软件工程师到底是什么的。

高级软件工程师的工作内容

我并不是说这是高级软件工程师的唯一日常，我只是开诚布公地告诉大家，我是如何工作以及如何看待这份工作的。我的工作内容主要分为两大类别：首先是实际战术，即日常任务内容；第二类不太明显，但同样非常重要，即我是如何考量以及处理这些任务的。

我花了点时间思考自己每天需要处理的具体事务，并把它们整理成一份图表。我肯定遗漏了一些内容，而且具体工作每周都会出现明显波动（因此这只是一份粗略的图表，仅供大家参考）。

我意识到，自己只花了大约一半的工作时间直接为 Scrum 团队完成任务。其中包括所有团队会议，我觉得这进一步突出了流程精简的重要意义。我承认，这部分工作跟我早年间的工作内容非常相似。虽然现在采取的具体方法有所变化，但在性质上并没有多大区别。具体包括编写设计文档、编写代码、进行代码审查以及测试所有代码等内容。

接下来的部分同样占据了相当比例的工作时间（大约 20%），这就是技术咨询（图表当中的绿色部分）。其中包括为各类设计方案——包括我自己的团队与其他团队提供咨询建议，回答技术问题以及在 API 标准委员会任职等。其中一部分与我的直接团队相关，但大多数是面向企业内的各个团队。有些问题还跟我个人有关，因为我虽然已经成为高级工程师，但当初入职时做的很多项目还在发挥作用，所以有时需要回答一些相关问题。随着所参与的项目数量不断增加，这方面工作内容也在持续增长。另外，虽然一直在回答问题，但我对于问题的考量方式与回答，或者说我提出的设计建议，也在随着时间推移而发生变化。

至于剩下的时间，基本上就是花在指导他人、建立更大的项目规划、技术品牌以及其他杂事身上。在指导当中，又分为正式指导与非正式指导。非正式指导一般就是一对一当面传授心得，正式指导自然是在众多同事面前通过演示文稿的形式讲解项目知识了，而且可能涉及一场甚至是多场会议。虽然正式指导看似有用，但我自己的感觉是它在我的指导内容当中只占很低的比例。相反，在大多数情况下，最好的方式往往是只立足一到两个问题围绕同一主题进行讲解。在非正式指导方面，我更倾向于称其为同伴指导或者相互指导。这并不是单纯的导师/学生那种关系，而是我会把我自己的问题与思路分享给同事，他们也同样向我分享。我们都能为对方提供见解与想法，并从其他人的不同观点当中受益。

大型项目规划包括与其他高级工程师及经理合作，为我的团队或者所在部门设定技术方向。其中还可能包括改善工程中的多样性与包容性等。基本上，这些都是涵盖多个团队的长期战略项目。随着时间的推移，我先后参与了众多不同的大型项目（包括我之前提到的那些）。有时候同事们会邀请我加入讨论，但一般来说我都能早一步发现问题并主动组织讨论。

接下来是技术品牌问题，我的主要工作就是帮助企业改善品牌形象。就个人而言，这主要涉及撰写博客文章，外加接受访谈或者帮助他人编辑文章内容。其中一些属于宣传性信息，但也有一些更侧重于学习与分享，旨在引导我们的工程师对于部门中正在研究的某些课题产生兴趣。

最后，我提到的杂项包含不太好归类的其他工作内容。其中囊括了各种各样的事务，包括接受采访、参加技术讨论或者参加公司内的黑客马拉松活动等。这些事情同样重要，但在时间占比上相对比较有限。

如果我在刚刚入职的时候就能读到这样一份清单，那么我的职业规划应该会更加明确。毕竟虽然这与初级工程师没啥关系，但以当时自己的能力而言，我已经完全可以胜任其中的大部分内容。不过我也承认，真正变化的并不完全是技能，而是我在处理这些任务时采取的方式以及在任务当中的关注重点。这种心态层面的变化，在重要性方面甚至不逊于工作技能。毕竟从时间占比来看，具体事务只占工作时长的一半左右。

原文链接：

《What a Senior Staff Software Engineer Actually Does》