论如何成为一名高级工程师

17611538698

webmaster@21cto.com

登录注册

论如何成为一名高级工程师

万能的大雄

技术人生 0 165 2024-09-25 02:11:36

导读：本文中作者与etsy首席技术官的观点综合，来讲述什么样的人才是高级软件工程师。

我认为我们这个领域有很多“制度性”知识，尤其是关于如何成为一名高效的（软件）工程师。

尽管管理领域有很多关于非技术个人贡献者的“专家”角色和责任的书籍，但我没有看到太多现代书籍或帖子可以直接阐明如何成为一名优秀的高级软件工程师。

不过，我完全同意朋友 Theo 在他的Web运维（O'Reilly 出版社）中所说的：

X 世代是追求即时满足的文化。

我曾与为数众多的工程师共过事，他们期望“职业道路”能在 5 年内将他们带入工程团队的最高职位，仅仅因为他们很聪明。

在我目睹的以往数字中，这根本是不可能的。不是每个人都能成为高级工程师。

如果五年后你成为高级工程师，那么你就处于职业生涯的巅峰了吗？再过五年，你难道不会积累更多宝贵的经验吗？那会怎样？“超级工程师”？再过五年？“超级工程师”。我将这种痛苦归咎于我们这个行业的年轻。

事实上，很少有工程师在运维领域工作了 15 年。鉴于我们行业的动态，许多人选择继续担任管理职位，或者冒险开始创业。

他说得非常对，网络运维领域还很年轻。因此，当那些拥有“高级”头衔的人表现出不成熟的行为（无论是技术方面还是非技术方面）时，我们并不感到惊讶。

那么在这个领域，“资深”究竟意味着什么？

鉴于我以往负责招聘、支持和留住资深的工程师经验，我对它的含义有自己的一些看法。在职业发展方面有一个门槛，这个观点很好，但我还想补充一点，这些标准是存在于一个范围内的，而不是简单的复选框列表。你不会在某一天醒来，发现自己是“资深”的，仅仅因为你的头衔反映了晋升。高级工程师并非无所不知。他们的技术知识并不完美，但他们对此并不介意。

为了不将标题与模糊的期望相混淆，有时我会参考工程成熟度。我的核心意思是：我希望“高级”工程师是一名成熟的工程师。

我略过那些可以简单列出成熟工程师应该掌握或理解的技术领域（例如“Web”、“文件系统”、“算法”等）的部分，而是强调个人特征。在我看来，这些特征表明某人可以在工程领域对组织或企业产生积极影响。

在 Quora 上，有人曾经问我“除了技术能力/经验之外，还有哪些特质可以成就一位优秀的技术运维副总裁？”。我在回答中提到的属性列表是基于这样的理解：它们是我自己永恒的愿望。

我认为，Web开发和运维领域的高级工程师与其他工程领域（机械、电气、化学等）的高级工程师具有相同的特征——工程的不成文法则均可适用。

成熟工程师必备的精髓

我将为大家提供一些要点。一些是我自己的，一些是从各种来源摘录的，其中许多来自上述不成文的法则。

首先，成熟的工程师会寻求对自己设计的建设性批评。

我遇到的每一位成功的工程师，在完成设计或准备一个项目时，他们都会不断地向他们的同事问这样类似的问题：

“我可能错过了什么？”
“这怎么会不行呢？”
“你能尽可能多地批评我对此的看法吗？”
“即使从技术上来说它是可行的，但它是否足够易于组织的其他成员理解，以便能够操作、排除故障和扩展它？”

这是因为他们知道，他们所做的任何事情都不会只掌握在自己手中，而良好的同行评审才能做出更好的设计决策。正如其他地方所说的那样，他们“乞求坏消息”。

成熟的工程师了解他们如何被看待的非技术领域。能够用 Erlang 编写 Bloom Filter，或者在睡梦中编写多线程 C 语言是不够的。

接下要说的，如果没有人愿意和你一起工作，这些都毫无意义。

成熟的工程师都知道，无论他们的设计多么完整、优雅或优秀，如果没有人愿意与他们一起工作，这一切都毫无意义，因为他们是一个混蛋。

傲慢、轻视、自恋和自我膨胀的行为会向其他工程师（也许是心照不宣地）发出彼此远离的信号。

工程师的快乐一部分来自于在设计和创建东西时，享受与你一起工作的伙伴陪伴。一个动不动就骂别人白痴的工程师，注定会阻碍自己的职业生涯。

这也意味着成熟的工程师在沟通方面有自我意识。这并不是说每个成熟的工程师都能完美地沟通，只是他们知道自己在哪些方面可以做得更好，并不断要求同事和经理对他们的表现进行评估。他们力求在表达自己的想法时表现得自信，而不是消极或咄咄逼人。

我已经在其他地方提到过。但我必须再强调：别人想和你共事的程度直接表明了你作为工程师的职业生涯会有多成功。

因此，请务必你成为每个人都想与你共事的工程师。

现在，这并不是说你应该回避对工程师（而不是工程师本人）的工作提出（或接受）建设性批评，因为害怕惹恼别人。称某人为白痴和指出他们的代码或产品中的错误是有区别的。

在与 Theo 的对话中，他指出了我们的领域可能发展的另一个领域：

作为一个行业，我们需要（当然）避免对人类性格和状况进行批评，但不要回避对工作成果的批评。

我们需要变得更加坚强，能够通过试图消除个人关注的视角来接受批评。也会有混蛋，他们应该被避开。但将某人的代码视为他们的孩子的态度应该结束。代码没有感情，不会发展出情结，当然也不会表现出最重要的特征（如繁殖能力），而这些特征是你的遗传品系所携带的。

我认为这与不成文法（重点是我的）有一个必然联系：

当涉及其他部门的利益时，要谨慎选择将信件、备忘录等复制给别人。年轻人传播含有有害或令人尴尬言论的备忘录已经造成了很多的恶作剧。

当然，新手有时很难识别此类文件中的“重磅炸弹”，但一般来说，如果该文件过于冒犯他人或暴露了任何人的严重缺陷，则很容易引起麻烦。如果该文件的发行范围很广，或者涉及制造或客户困难，除非你非常有把握，否则最好在发出前征得老板的批准。

此外，成熟的工程师不会回避做出估算，并且总是努力做得更好。

以下，摘自不成文的规则：

承诺、时间表和估算是井然有序的业务中必不可少的重要工具。许多工程师没有意识到这一点，或者习惯性地试图逃避做出承诺的烦人责任。你必须根据自己对自己负责的工作部分的估算以及从相关部门获得的估算来做出承诺。

任何人都不应该用老套路来回避这个问题：“我不能做出承诺，因为它取决于太多不确定因素。”

逃避估算责任的另一种说法是，“我还没有准备好被依赖来建设关键的基础设施。”所有企业都依赖估算，所有从事项目的工程师都应该参与估算。一起联合活动，这意味着他们有责任让自己变得可预测。

因此，一般来说，成熟的工程师能够适应在一定范围内的不确定性以及风险下工作。

成熟的工程师有着与生俱来的预见能力，即使他们并不知道自己有这样的能力。

例如，经常有人会这样说：

“这段代码看起来不错，我为自己感到自豪。我已经请其他人审查了它，并听取了他们的反馈。”

现在的问题：它会持续多久才会被重写？一旦投入生产，它的执行将如何影响资源使用？我预计 CPU/内存/磁盘/网络会增加或减少多少？其他人能理解这段代码吗？我是否尽可能让其他人轻松扩展或反思这项工作？

成熟的工程师明白，并非所有项目都充满了摇滚明星般上舞台式的工作。

不管你早期的任务看起来多么琐碎，你都要尽最大努力。

完成任务意味着做一些你可能不感兴趣的事情。无论一个项目多么令人兴奋或吸引人，总会有一些无聊的任务，甚至是乏味的任务。

不太成熟的工程师可能会认为这些任务有损他们的尊严或自己的职位光环。

优秀工程师的“慷慨精神”

凯兰·埃利奥特-麦克雷（他是 Etsy 的现任首席技术官），他对任务有这样的看法：

有时，繁琐任务的可取之处在于，任务的简单性和成熟性体现在快速完成任务并继续前进。

有时任务之所以繁琐，是因为它们需要极强的纪律性和可塑性的注意力。最繁琐的任务只能由最资深的工程师来完成，这也是最可怕的，这是一个奇怪的现象。

成熟的工程师，他能够提升周围人的技能和专业知识，甚至于更多。

他们认识到，在某个时候，他们个人的贡献和潜力无法单独发挥。他们认识到一个人能创造的东西是有限的，世界上最好的工程壮举是由团队完成的，而不是由单个才华横溢的工程师独自完成的。

在 Etsy，麦克雷团队们称之为“慷慨精神”。

慷慨精神是我们的核心工程价值观之一，也是我们的员工工程师职位（职业级别职位）的主要职责。这些工程师花时间确保不熟悉我们技术或流程的初级或新工程师不仅了解他们在做什么，而且要了解他们这样做的原因。

“授人以渔”是这一级别的必备技能，这需要耐心和对组织其他部门的投资眼光。

因此，请你不要再说：“好的，让开，让我来帮你做！”，而是：“好的，我们一起来做吧。我可以向你展示我是如何写作/故障排除/等等。然后，你来做，这样我就能确保你知道为什么/我们如何这样做，等等。”

成熟的工程师懂得指导和赞助之间的区别，并养成后者的习惯。

那些发现自己的工作越来越受关注的工程师们承认，在当地社区（组织内部和外部）发挥影响力的一个基本方法是发展和保持对赞助周围受益者的机会的认识。众所周知，科技行业在支持代表性不足和/或边缘化群体方面面临严峻挑战。

养成这种习惯需要付出努力，但好处是多方面的；工程师可以提高他们的批判性思维能力（“哦，我们在这次会议上谈论的内容对 $NAME 来说是一个很好的机会...”），而受赞助的工程师也获得了他们原本可能得不到的机会。

拉拉·霍根的必读文章

拉拉（Lara）说，当享有特权的人开始看到偏见和特权制度时，他们的第一反应通常是指导那些没有从同样特权中受益的人。这是可以理解的——他们希望帮助那些被边缘化的人成长、晋升或成为更好的工程师，以帮助平衡我们行业普遍存在的不平等现象。

但从本质上讲，这种指导本能表明了这样一种观点：那些被边缘化的人还没有足够的技能、不够聪明，或者没有足够的能力承担更多的责任或领导。
科技界中代表性不足的群体成员最需要的往往是机会和知名度，而不是建议。他们必须非常努力地工作，并且非常擅长自己的工作，以对抗我们工作环境中的系统特权和无意识偏见。尽管他们的工作非常出色，但他们一直得不到充分的提拔和报酬。

Lara 继续举例说明这种情况：

以下是我见过的真实生活中赞助成功的例子：

根据此代码库的经验、解决此类问题的经验或过去按时完成工作的效率，推荐适合领导新项目的人员
建议某人担任事后总结主持人，或在其他人正在学习的会议上担任另一种可见的领导者
建议有人为工程博客撰写一篇新博文，介绍他们最近的项目、解决棘手问题的方法或其他公司可以借鉴的解决方案
建议某人在公司或团队会议上发表演讲，展示他们的工作
将项目的电子邮件摘要转发给与原始受众不同的人群，强调为什么它很有趣或者你从中学到了什么
询问某人的经理你是否可以分享你见证的一些他们出色工作的反馈
在 Slack 中提及或分享您认为有帮助、有趣等的某人的工作。
向一大群有影响力的人讲述你最近从某人那里学到的一件有趣的事情

成熟的工程师在做出判断和决策时，会明确自己的权衡

他们意识到所有工程决策、实施和设计都存在于一个范围内。确实，我们并不是生活在一个二元世界中。

工程师们可以快速指出一种成功的方法或解决方案在哪些情况下可行，在哪些情况下不可行。他们知道一个人不可能同时既高效又彻底（ETTO 原则），大多数工程师所从事的项目都存在一个最优性和脆性轴，而且他们所解决的问题要界定急性的还是慢性的。

他们知道他们的工作范围是理想和非理想的，并且对此很满意。

他们对此感到满意，因为他们努力使设计中的理想和非理想情况明确。在设计生命周期的后期，当原始设计不再可扩展或需要替换或重写时，他们可以回顾过去，而不是以那些早期决策有多么短视的眼光来看待，而是说“是的，我们做到了这一点，并且知道我们必须在某个时候扩展或更改它。看起来现在是时候了，让我们开始重写工作吧！”

他们不用暴躁的语气回应，消极被动事后偏见充满反对事实的言论（例如“那些白痴第一次就做错了！，“他们偷工减料，写的代码烂！，“我告诉过他们这行不通！”）

有许多精辟的引言阐明了这种权衡的概念，成熟的工程师知道任何充满哲学意味的引言（包括我在这里写的这些）都是有局限性的：

“过早优化是万恶之源。”——这是一句被滥用的格言，我之前也写过。它的推论可能是（取自此处）“了解什么是‘过早’，什么不是‘过早’，是区分高级工程师和初级工程师的标准。”
“合适的工具适合工作”——另一个被滥用的词。这里的意图是合理的：谁想使用不合适的工具？但一个罕见的观点是，如果走极端，这可能会有害。木匠不会用所有可用的锤子来武装自己，即使他可能会遇到可以用每种锤子完美处理的锤击任务。为什么？因为拖着（和维护）无数把锤子需要花费成本。因此，在这个轴上的决定也是有权衡的。

关于权衡的总结就是，每个人都会在每个项目中偷工减料。不成熟的工程师事后发现他们会对此感到厌恶。成熟的工程师会在项目开始时就明确说明，接受它们，并将它们视为良好工程的一部分。

成熟的工程师不会践行 CYAE（“Cover Your Ass Engineering”）

如果有人只是以形式作为借口，不去尝试理解自己的代码（或基础设施）会如何被系统或业务的其他部分所影响，那么这种做法一定是失败的。

遮住你的屁股，这暗示你是一个愿意将其他人（你的团队？你的公司？你的社区？）置于危险境地的人，只要有人暗示你的工作存在任何缺陷。而成熟的工程师会站出来承担赋予他们的责任。如果他们发现自己没有必要的权力对自己的工作负责，他们会想方设法纠正。

CYAE 的一个例子是“这不是我的错。他们弄坏了它，他们用错了。我按照规格制造了它，我不能为他们的错误或不适当的规格负责。”

成熟的工程师富有同理心。

在复杂的项目中，通常会有许多利益相关者。在任何项目中，设计师、产品经理、运营工程师、开发人员和业务开发人员都有目标和观点，成熟的工程师意识到这些目标和观点可能会有所不同。他们理解这一点，以便能够在工作中有效地导航。从这个意义上讲，同理心意味着能够从另一个人的角度看待项目，并在自己的工作中考虑到这一点。

目标冲突是所有工程工作中固有的，抱怨它们（而不是将它们视为成功的要求）是工程师不够成熟的表现。

成熟的工程师，他们不会凭着感性空口抱怨。

相反，他们根据经验证据表达判断，并根据这些判断提出解决问题的方案。我的一位优秀技术经理说，永远不要在没有至少一个（最好不止一个）解决方案建议的情况下向老板抱怨任何事情。

即使表明你已经尝试过自己解决问题，但一无所获也要比空洞的抱怨要好。

成熟的工程师意识到认知偏见

这并不是说每个成熟的工程师都需要有心理学学位，但认知偏见确实会在某个阶段限制工程师的职业发展。即使他们不知道这些偏见是如何出现的，也不知道如何防范，我认识的大多数成熟工程师都有一定的自我意识，至少能认识到他们（和所有人一样）容易受到这些偏见的影响。

从文化角度来看，工程师每天都在研究中运用经验等证据。基本可以说：给我看数据。认知偏差的问题在于，我们可能完全没有意识到我们何时用自己的大脑以违背经验数据的方式解释数据，并且可能对我们完成工作和团队合作的方式产生令人惊讶的影响。

以下是一个很好的清单，我见过很多工程师（包括我自己）陷入以下的陷阱：

自利偏差——基本上：如果某件事是好的，那可能是因为我做了或想到了某件事。如果它是坏的，那就是别人做的。
基本归因错误——基本上：其他人在工作中取得的糟糕结果一定与他的个人性格有关（愚蠢、笨拙、马虎等），而如果我取得了糟糕的结果，那是因为我当时所处的环境、承受的压力、所处的境况等造成的。
后见之明偏差——（据说这是现代心理学史上研究最多的现象）基本上是：在发生不幸或负面事件（严重的错误、停电等）后，会说“我早就知道了！”。这是一种非常强烈的倾向，即以比实际情况更简单的方式看待过去。当描述涉及反事实或“……他们应该……”或“……他们怎么没看到——这太明显了！”时，你可以看出存在后见之明的偏差。
结果偏见——如上所述，在意外或负面事件发生后出现。如果事件破坏性极强、清理成本高昂或严重，那么导致该事件的决定或行动就会被判定为非常愚蠢、鲁莽或疏忽。判断与事件的严重程度成正比。
计划谬误——（与上文关于在不确定性条件下做出估计的观点相关联）基本上是：对预测特定项目所需的时间过于乐观。

当然，还有许多其他的，我个人觉得它们都很有意思，我有时会沉迷其中，想了解更多。如果你有兴趣了解自己如何限制自己的效率，强烈建议你多阅读。

无我编程的十诫

恰当的规则，即使有些陈旧……我曾看到有人引用它来自计算机编程心理学，写于 1971 年，但我在正文中没有看到它。无论如何，以下是无我编程的十诫：

理解并接受你会犯错的事实。关键在于在错误投入生产之前尽早发现它们。幸运的是，除了我们 JPL 开发火箭制导软件的少数人之外，错误很少会在我们的行业中造成致命后果。我们可以而且应该学习、大笑并继续前进。
你不是你的代码。请记住，审查的全部目的在于发现问题，问题会被发现。当发现问题时，不要把它当回事。
无论你懂多少“空手道”，总会有人懂得更多。如果你问的话，这样的人可以教你一些新动作。寻求并接受他人的建议，尤其是当你认为不需要的时候。
未经协商，请勿重写代码。 “修复代码”和“重写代码”之间只有一线之隔。了解两者的区别，并在代码审查框架内进行风格上的更改，而不是作为单独的执行者。
尊重、顺从和耐心对待那些知识不如你的人。经常与开发人员打交道的非技术人员几乎普遍认为我们最好是自命不凡的人，最坏则是爱哭鬼。不要用愤怒和不耐烦来强化这种刻板印象。
世界上唯一不变的就是变化。要对变化保持开放，并微笑着接受它。将需求、平台或工具的每次变化视为新的挑战，而不是需要克服的严重麻烦。
唯一真正的权威源自知识，而非地位。知识产生权威，权威产生尊重——因此，如果你想在无私的环境中赢得尊重，就必须培养知识。
为你的信仰而战，但要优雅地接受失败。要明白有时你的想法会被否决。即使你是对的，也不要报复或说“我早就告诉你了”。永远不要让你已逝去的想法成为烈士或战斗口号。
不要成为“角落里的程序员”。不要成为黑暗办公室里只为喝汽水而出现的人。角落里的程序员看不见、摸不到、也不受控制。在开放、协作的环境中，这种人没有发言权。参与对话，成为办公室社区的参与者。
批评代码而不是批评人——善待程序员，而不是代码。尽可能让你的所有评论都积极向上，以改进代码为导向。将评论与当地标准、程序规范、提高性能等联系起来。

新手与专家的区别

现在我一般不太关注知识获取作为一个研究课题，但我认为在谈论一门学科的演变性质时很难避开它。

一个有趣的分析来自德雷福斯和他的论文名为“定向技能习得心理活动的五阶段模型”，其中列出了不同专业水平的特征：

初级	严格遵守规则或计划情境感知能力较差没有（或有限）自由裁量权
高级初学者	基于属性和方面的行动指南，它们都是平等和独立的情境感知有限
胜任的	有意识的深思熟虑的规划标准化和常规程序
精通	看待问题时要整体看待，而不是只看个别方面感知到与正常模式的偏差使用格言作为指导，其含义与上下文相关
专家	不再依赖规则、准则或准则直观地掌握情况仅在新情况下使用分析方法