除了写代码，还能如何晋升为高级工程师？

每位工程师都是从初入行的小白一枚逐渐成长为独当一面的高级工程师，那么本文我们就来看看，高级工程师的工作内容和责任边界是什么？

以下为译文：

Adaptive Capacity Labs，LLC联合创始人、前Etsy首席技术官John Allspaw曾经写过一篇标题为《论一名高级工程师》（On Being A Senior Engineer）（https://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/）的文章。我第一次读到这篇文章是在4年前，当时我刚进入现在的公司，这篇文章确实影响了我对自己未来发展的看法。

4年后重读这篇文章，我对文中提到的一点十分感兴趣：帮助你的团队取得成功是作为高级工程师的重要职责。这句话当然没错！

但是从今天的立场来看，我认识的大多数（乃至全部）高级工程师除了承担自己的编程工作以外，还需要承担大量帮助他人的工作。如今我和我的同事面临的挑战并不是“什么？我需要去跟别人交谈？不可思议。”或者说“等一下，我怎样才能在所有的领导工作和自己的本职编程工作之间寻得平衡呢？我需要花费多少时间在各项工作上呢？”

因此，在本文中我不想讨论Allspaw的文章中提到的高级工程师的“特质”（我完全同意），我只想谈谈高级工程究竟需要承担哪些工作。

本文的主要内容：

“高级工程师承担的工作”是一个很大的话题，我无法通过一篇小文章做到面面俱到。请您在阅读本文时，记得以下几点：

• 本文讨论的“高级工程师”承担的工作内容只是一种可能性。工作的方式很多，我们并没有标准答案。

• 我基本上只在一家公司工作过，而这篇文章描述的也只是我的经验，所以我的观点可能有些狭隘。

• “高级工程师”都各有千秋。本文讨论的是Mozilla ladder（https://twitter.com/Gankro/status/1046438955439271936）中描述的P3/P4水平，也就是高级工程师和主管工程师，可能更倾向于主管工程师。

属于高级工程师的工作内容

下列工作在我看来主要是高级工程师的工作，而不像是经理的工作。虽然管理人员肯定会承担其中一些，尤其是创建新项目和将项目与业务优先级相关联等。

所有项目的工作归根结底还是要靠技术：帮助别人解决棘手的项目显然是人为的互动，但通常，我们共同努力的问题还是有关计算机的问题！（“如果我们简化设计的话，也许可以早点做完工作！”）

• 写代码。

• 代码审查。

• 编写和审查设计文档。我认为“审查设计文档”与其他审查任务一样，就是“让别人看看设计，帮忙改进设计”。

• 当团队成员遇到困难时给予帮助。有时人们会被一个项目难倒，给予他们支持很重要！我认为这不是“神兵天降，将你的法术传授给他人”，更像是“共同努力去理解他们试图解决的问题，看看三个臭皮匠能不能赛过一个诸葛亮”。这也意味着你要与他们一起解决问题，而不是替他们解决问题。

• 保证项目的高质量标准。对于不同的人来说，“质量”意味着不同的事情（对我的团队来说，这意味着可靠性/安全性/可用性）。通常我不赞同某人做出的决定时，我就知道要么是因为我知道他们不知道的事情，要么是有什么事是他们知道而我不知道的！所以，不应该对人家说：“你错了，应该这么这么做”，我会试着提供一些他们不知道却很重要的额外信息。而且我发现常常是我忽略了一些东西，实际上他们的决定是完全合理的！过去我偶尔会看到有些高级工程师为了强制执行质量标准，大吼大叫并不断重复他们的意见，因为他们认为他们的意见是正确的，而我个人觉得这些方法并没有用。

• 创建新项目。软件工程团队不是零和博弈！我认识的优秀的工程师都不会将最有意思的工作留给自己，他们会创造新的有趣且重要的工作，并给他人机会让他们承担这些工作。例如，我们团队中有人带头重写了我们的部署系统，结果非常成功，如今我们整个团队都在研究新功能，在重写部署系统后做新功能就更加容易了！

• 计划项目的工作。即整理与传达正在进行的项目的蓝图，并确保团队成员可以理解你的计划。

• 主动沟通项目的风险。这项工作的要点在于：及时发现项目进行中的问题，与其他工程师或经理进行沟通，并找出解决方案。

• 沟通是成功的必经之路！

• 做有利于团队或公司的副项目。我看到许多高级工程师偶尔会做一些小型影响力很高的项目（比如构建开发工具/帮助设置策略等），最终可以帮助很多人更好地完成他们的工作。

• 了解项目与业务优先级的关系。

• 决定何时停止做项目。弄清楚什么时候停止某项工作是非常困难的。

我把“写代码”放在第一位，是因为我觉得大家很容易在不经意间就忽略写代码:)

有一件事我没有提到，那就是“做估算”。我还不太擅长做估算，所以我对此了解的不太多，但我认为将来一定要在这方面多花点时间。

如果你想一下子做好上面所有的事情，那么会觉得好多，而且会让你倍感疲惫。我认为一般来说，找出其中一部分工作，然后告诉自己“现在我要专注地做好X Y Z，如果我同事尝试做A B C的话，我的脑袋会爆炸。”

不属于高级工程师的工作内容

这部分有点棘手。

我不是说这些不是高级工程师的工作，我也不是说“我才不会帮助我的团队创造一个良好的工作环境，这跟我有一毛钱关系吗？”。我认识的大多数高级工程师都花了很多时间思考这些问题，并且还做了很多研究。

我之所以认为有必要在此画条界限，是因为我的同事都对团队和公司有很强的归属感与责任感（他们通常都会说：“这是我们要做的工作是吧？那好，我来做吧！ “）而且我认为让大家主动承担需要完成的工作往往会导致他们不堪重负、过度劳累、无法在他们的核心工作中做出真正的技术贡献。因此，如果针对我们的职位创建一些界限，那么在大家忙成一团的时候，更容易决定应该寻求怎样的帮助。实际上你画的这个界限取决于你和你的团队:)

这些工作中的大多数都是经理的工作。注意：管理人员的工作远不止这里列出的事项（例如“创建新项目”），而在有些公司里，有些事情实际上可能是高级工程师的工作（例如sprint管理）。

• 确保每个团队成员的工作得到认可；

• 确保以公平的方式分配工作；

• 确保团队成员相处融洽；

• 建立团队凝聚力；

• 与团队中的每个人进行一对一的谈话；

• 培训新的管理人员，帮助他们了解他们的职责（尽管我认为实际上往往高级IC最终会承担部分工作？）

• 承担你没有参与的项目的管理工作（在我们公司，这是领导项目的工程师的工作）

• 做产品经理；

• Sprint管理，将每个人的工作融入项目程碑，组织每周一次的团队会议。

明确的责任边界很重要

我曾遇到过一个有趣的状况。我跟一名经理谈起我作为工程师，哪些任务不是我的工作，然后发现我们对这个问题的期待完全不同！我们谈了很久，现在这个问题应该解决了，但它让我认识到，一致的期待非常重要。

我开始做工程师时，我的工作很直接——写代码，完成项目，就足够了。我的经理很清楚我的工作内容，并且会保证我的工作不会太复杂。但现在情况不一样了！所以我认为，现在定义工作内容的责任更多在我自己：

• 我能做什么——即适合我的工作；

• 我想做什么——即我喜欢的，并且与我个人目标一致的工作；

• 什么对团队或组织有价值。

至于工作的具体情况，每个人各不相同（并非每个人都有同样的能力和兴趣，例如我实际上不太擅长代码审查！），所以我觉得沟通期望就更重要了。

不要承诺你无法完成或不想做的工作

我认为，从长期来看，拒绝我不能胜任的工作或者会让我不愉快的工作是非常重要的！我发现，我似乎很容易同意或接受一堆我知道我不喜欢的工作（“哦，这对团队有好处呀！”，或者“嗯……反正总得有人做！”）。虽然我有时会被迫接受一些不得不做的工作，但我觉得，让团队成员做合适的、喜欢的工作对于团队的健康很有好处。

所以，我会接受不得不做的小任务，但我觉得敢于说出自己的心声很重要的。 :) 比如说：“可以，我会花许多时间做这件我不擅长或不喜欢的工作，但没问题。” 而且，如果必须“有人”做，那么可能意味着我们需要雇佣或者培训新人来填补这个空白 :)

我还有许多要学习的东西！

虽然我觉得我对“高级工程师”有自己的见解（我已经有7年经验了），但我仍然觉得我还有许多要学习，我也愿意听听别人如何定义工作的界限！

原文：https://jvns.ca/blog/senior-engineer/

作者：Julia Evans，Stripe的软件开发。

译者：弯月，责编：郭芮

推荐阅读：