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

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

CSDN资讯

1994人浏览 · 2018-11-12 11:06:10

CSDN资讯 · 2018-11-12 11:06:10 发布

640?wx_fmt=gif

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

640?wx_fmt=jpeg

以下为译文：

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管理）。