其他分享
首页 > 其他分享> > “高级工程师”没用！你应该成为一名 “成熟的工程师”

“高级工程师”没用！你应该成为一名 “成熟的工程师”

作者：互联网

想，在我们这个行业中，有很多经验知识，特别是关于如何成为合格的工程师。虽然在管理领域中有很多关于非技术性个人贡献者的“专家”角色和责任的书籍，但我并没有看到多少现代书籍或帖子，直接讲述要如何才能成为一名优秀的高级工程师。一个值得注意的例外当然是 Kate Matsudaira，她最近发布了很多关于 工程文化方面 的文章，这些文章写得都相当不错。

我所知道的有很多成功的工程师，都记得这位导师，他们从这位导师那明白了什么是“高级”。

不过，我确实完全同意我朋友 Theo 在 《网站运维》（Web Operations）（由 O'Reilly 出版）一书中关于成为“高级”的一章中所说的话：

X 一代（甚至更多的是 Y 一代）是一种即时满足的文化。我曾与众多工程师共事过，他们认为，仅凭他们的高智商，“职业道路”应该能让他们在在 5 年之内跻身工程团队的最高层。从我亲眼目睹的惊人数字来看，这简直完全是不可能的。不是每个人都能成为高级程序员。如果说，五年后你成了高级工程师，你是不是正处于事业的巅峰呢？那再过五年，你会不会积累更多宝贵的经验呢？再然后呢？是“超级工程师”吗？如果又再过五年呢？“超超级工程师”？我把这种痛苦归咎于我们管教的年轻人。事实是，在网站运维领域工作十五年的工程师寥若星辰。鉴于我们这个行业的局势，许多人选择转行到管理职位，或者冒着创业的风险。

他是对的：这个网站运维领域还很年轻。因此，当拥有“高级工程师”头街的人，表现出不成熟的行为时，无论是技术性的还是非技术性的，我们都不会感到惊讶。如果你还没读过 Theo 写的章节，我建议你去读一读。

话虽如此，在这门学科中，“高级”到底意味着什么呢？当然，对此我也有自己的看法，因为我负责招聘、支持和留住那些被认为是高级工程师的人。有一种想法，就职业发展而言，有一道门槛需要跨过，能有这种想法是很好的，但我还要补充的是，这些标准存在于一个范围之内，而不是简单的复选框列表。你不会有一天认识到，你之所以是“高级”工程师，只是因为你的职位反映了晋升而已。高级工程师并非什么都懂。他们的技术知识也并不完美，但他们对此并不介意。

为了避免将职位和模糊的期望相混淆，有时我会提到工程师的 成熟度。

意思就是，我心目中真正的“高级”工程师就是 成熟 的工程师。

我将简要地介绍一下一名成熟的工程师应该有一定程度的掌握或理解的技术领域的部分（如“网络”、“文件系统”、“算法”等），相反，我还要强调个人特性，因为在我看来，这些特性表明某人可以在工程领域对一个组织或企业产生积极的影响。

在 Quora 上，有人曾经问过我：“作为一名优秀的技术运维副总裁，除了技术能力 / 经验外，还有哪些特性？”

我在回答中提到的特性列表是基于这样一种理解，它们就是我自己永恒的追求。本文和我那个回答是相似的。

首先我认为，Web 开发和运维方面的高级工程师与其他工程领域（机械、电气、化学等）的高级工程师具有相同的特点，在这种情况下，《工程学的潜规则》（The Unwritten Laws of Engineering ）这本书是适用的。再强调一次，如果你还没有读过这本书，请先读一读。这本书最初写于 1944 年，由 美国机械工程师协会出版（American Society of Mechanical Engineers）。这本书的摘录可参见：人因工程与网络工程的交集（Human Factors and Web Engineering’s Intersection）

虽然这本书的结构和文字给人一种过时的感觉（如“……不要在工作场合说脏话”或“……男人应该特别注意剃须习惯，修剪胡须”之类），但它仍然很好地概括了工程组织的非技术方面的期望、职责和内部工作，以及管理者和成熟工程师的行为方式。

成熟工程师必备的精炼特点

所有试图洞察期望特征的帖子都必须有丰富的要点，而工程学也有相当一部分的要点。因此，我讲给你们讲的，有一些是我的，还有一些来自不同的来源，其中很多都来自上面提到的《工程学的潜规则》一书。

成熟的工程师会对他们的设计寻求建设性的批评。

我遇到的每一位成熟的工程师，在完成一个设计或者为一个项目做好准备之后，都会不断地向他们的同行提出以下类似的问题：

这是因为他们知道，他们所做的一切都不会只掌握在自己手中，而且经过良好的同行评审才能做出更好的设计决策。就像其他地方所说的那样，他们“乞求得到坏消息”。

成熟的工程师了解如何感知他们的非技术领域。

能够在 Erlang 中编写 Bloom Filter，或者在睡梦中编写多线程 C 是不够的。如果没有人愿意和你合作，这些就都不重要了。成熟的工程师知道，无论他们的设计看上去多么完善、多么优雅、多么优秀，如果没有人愿意和他们一起工作，那也没有关系，因为他们都是 混蛋。傲慢、轻视、自恋和自负的行为会把这一信息传递给其他工程师（也许是心照不宣地），让他们远离。工程师的快乐部分来自于在设计和建造东西的时候享受与你一起工作的同事的陪伴。如果一个工程师很快就把某人称为白痴，那么他注定会阻碍自己的职业生涯。

这也意味着成熟工程师在沟通方面有自我意识。这并不是说每个成熟的工程师都能很好地沟通，只是说他们知道自己在哪些方面可以做得更好，并不断要求同事和经理对他们的工作进行检查。他们的目标是如何表达自己的想法时保持自信，而非被动或咄咄逼人。

我 在别处已经提到 过，但我必须更加强调这一点：其他人想和你合作的程度直接表明了你在工程师的职业生涯有多成功。成为人人都想合作的工程师。

这并不是说，你应该避免对工程（而不是工程师个人）所产生的 工作 提出建设性的批评，以免惹恼别人。将某人称为白痴，和指出他们的代码或产品中的错误是两回事。在与 Theo 的一次谈话中，他指出了我们行业中可能成长的另一个领域：

作为一个行业，我们当然需要避免对人性和条件的批评，但也不能回避对工作产品的批评。我们需要做到虚怀若谷，拭面容言，从谏如流，切忌讳疾忌医。混蛋是会有的，应该避开他们。但是，有些人认为他们写出来的代码就像他们的孩子，这种想法应该摒弃。代码没有感觉，不会发展成复合物，当然也不会表现出最重要的特性（如繁殖能力），也就是你的遗传品系所携带的特性。

另请参阅下面的《无我编程十诫》（The Ten Commandments of Egoless Programming）的第 2 条和第 10 条。

我认为这是潜规则的必然结果：

当涉及到其他部门的利益时，在信件、备忘录等文件的副本上，要注意标注对象。许多恶作剧，都是由年轻人广播含有害或令人尴尬的言论备忘录造成的。

当然，对于新手来说，有时候很难识别出这样一份文档中的“炸药”，但是，一般来说，如果它过于冒犯别人，或者暴露了别人的严重缺点，就很容易引起麻烦。如果它流传甚广，或者涉及到制造或客户的困难，除非你非常确定自己的立场，否则最好在它推出之前得到老板的批准。

当然，这凸显了这本书过时的感觉，但在现代，我仍然相信主要观点是正确的。没有什么比一条未经深思熟虑的、带有恶意侮辱的非建设性的推文更能表明你缺乏远见和意识。用 140 个字符来侮辱一项复杂的技术，这是一个初级工程师的错误。（译注：一条推文最多只能发 140 个字符）

当我遇到这些公开评论时，我当然（就像 Christopher Brown 在 Velocity London 的主题演讲中提到的那样）会注意它们，这样我就可以注意到，如果那些人到 Etsy 申请工作，我会重新考虑聘用谁。

成熟的工程师从不回避作出估计，并且总是试图在估计方面做得更好。

摘自《工程学的潜规则》：

在有序的企业中，承诺、时间表和估计是必不可少的重要要素。许多工程师并没有意识到这一点，或者习惯性地避免作出承诺的烦人责任。你必须根据自己对你所负责的那部分工作的估计作出承诺，同时也要根据各部门对他们所负责的那部分工作的估计作出承诺。不应该允许任何人用旧的公式来回避这个问题。“我不能作出承诺，因为这取决于许多不确定的因素。”

避免承担估计责任是另一种说法，“我还没有准备好去构建基础设施的关键部分。”所有的业务都依赖估计，所有从事项目的工程师都参与到联合活动中，这意味着他们对他人有责任使自己变得可预测。一般来说，一些非零的不确定性和风险范围内对成熟的工程师来说是“舒适区域”。

成熟的工程师有一种与生俱来的预感，即使他们不知道自己有这种预感。

这段代码看起来写得不错，我为自己感到骄傲。我已经请其他人评审了，并且已经听取了他们的反馈。现在的问题是：这段代码要多长时间才会被重写？一旦投入生产，它的执行将如何影响资源的使用？我期望 CPU/ 内存 / 磁盘 / 网络增加或减少多少呢？其他人能够理解这段代码吗？我是否应该让其他人尽可能容易的扩展或者反思这项功能呢？

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

无论你早期的任务看起来多么琐碎，多么微不足道，都要尽你所能去完成。

完成每一件事意味着你要做好你可能不感兴趣的事情。无论项目多么令人兴奋或有吸引力，总会有一些无聊的任务、单调乏味的任务、那些不太成熟的工程师可能认为有损他们尊严或职位的任务。我的好朋友 Kellan Elliot-McCrea（Etsy 的首席技术官）对此持这样的看法：

有时，单调乏味的任务的可取之处在于他们的简单和成熟，表现在快速完成任务并继续前进。有时任务之所以单调乏味，是因为他们需要极端的纪律性和可塑的注意广度（attention span）。这是一个奇怪的现象，最单调乏味的工作，反而只有最资深的工程师才能完成，这也可能是最可怕之处。

成熟的工程师会提升周围人们的技能和专业知识。

他们意识到，在某种程度上，他们的个人贡献和潜力不能单独发挥。他们还认识到，一个人能够创造的东西是有限的，世界上最好的工程壮举是由团队完成的，而不是才华横溢、特立独行的工程师完成的。Tom Limoncelli 在他的 文章《系统管理员何以成为“高级系统管理员？》（What makes a sysadmin a "senior sysadmin"? ）中很好地阐述了这一点。

在 Etsy，我们称之为“慷慨精神”。慷慨精神是我们的核心工程价值观之一，也是我们员工工程师职位的首要责任，是一个职业级别的职位。这些工程师花时间确保更多不熟悉技术或流程的初级或工程师新手不仅了解他们在做什么，而且还要了解他们为什么要这样做。“授人以渔”是这一级别的必备技能，这需要对组织的其他部门既有耐心，又要有投资的眼光。

因此，与其说“起开，我来给你做！”，不如说：“好的，让我们一起来解决这个问题。我可以给你看看我是如何写作 / 故障排除等等。然后，你可以这样做，这样我就可以确保你知道为什么 / 我们如何这样做的，等等。”

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

发现自己工作的知名度正在提高的工程师们认识到，在当地社区（组织内外）施加影响力的基本要素就是发展和保持对机会的认识，以资助周围的人，让他们从中受益。科技行业在支持未得到应有重视和（或）边缘化群体方面受到严重挑战，这已经不是什么秘密了。

养成这种习惯需要付出努力，但好处是多方面的；工程师提高了他们的批判性思维能力（“哦，我们在这次会议上讨论的内容将是让 $NAME 为之工作的最佳机会……”），以及被赞助的工程师得到机会，否则他们可能就不会。

关于这一话题，Lara Hogan 的文章是必读之作：《赞助是什么样子的？》（What does sponsorship look like?）

当有特权的人开始看到偏见和特权的制度时，他们的第一本能通常是 指导 那些没有从同一特权中受益的人。这是可以理解的，他们想要帮助那些被边缘化的人成长，获得晋升，或成为更好的工程师，来帮助平衡我们这个行业普遍存在的不公平现象。

但从本质上来说，这种指导他人的本能助长了这样的一种观点，那些被边缘化的人业务不够熟练，脑子不够聪明，或者还没有做好承担更多的责任或领导的准备。

在科技界中，未得到应有重视的群体最需要的往往是 机会和知名度，而不是建议。他们必须非常努力地工作，并且非常擅长他们所做的事情，以对抗在我们工作环境中起作用的系统特权和无意识偏见。尽管这项工作非常出色，但他们在这项工作中，一直没有得到充分的提拔，薪水也一直很低。

Lara 接着举了几个例子说明这看起来可能是什么样子的：

这些都是我见过的赞助的真实例子：

· 建议根据他们在这个代码库的经验，确定一个可以很好地 领导新项目 的人，解决这类问题，或者根据过去的业绩证明，能够按时完成工作。· 建议某人成为事后调解人，或者成为另一种可见会议领导者，在这场会议中其他人都在学习。· 建议某人可以为工程博客撰写一篇 关于他们最新项目的新博文，解决棘手问题的方法，或者其他公司可以借鉴的解决方案。· 建议某人在公司或团队会议上 发表演讲，展示他们的工作。· 将项目的电子邮件摘要转发给与原始受众不同的人群，强调为什么它很有趣，或者你从中学到了什么。· 询问某人的经理你是否可以 分享有关你所目睹的他们杰出工作的反馈。· 在 Slack 中提及或分享 某人的工作，你认为这些工作有用且有趣。· 向一群有影响力的人援引你 最近从某人那里学到的一件有趣的事。

成熟的工程师在作出判断和决策时，会明确权衡利弊。

他们意识到所有的工程决策、实现和设计都存在于一个范围内；我们并不是生活在一个二元世界。他们可以快速指出哪些情况下一个成功的方法或解决方案可行，哪些情况下不可行。他们知道一个人不能做到同时既有效率又全面（ETTO 原则），大多数项目工程师所从事的项目都是以 最优化 和 脆弱性 为轴心的，并且他们所解决的问题是 急性 的或慢性 的。

他们知道他们在理想和非理想的范围内工作，并且对此没有意见。他们对此感到很满意，因为他们努力使设计中的理想和非理想进行明确化。在设计生命周期的后期，当原始设计不再扩展或需要替换、重写时，他们将会回顾过去，不是从一个角度来看待那些早期的决定是多么的短视，而是说，“是的，我们用它走到了这一步，并且我们早就知道必须在某个时候对它进行扩展或改变，看来现在是时候了，让我们开始吧！” 并不会用偏执的、被动进取 的后见之明和充满偏见的反事实的评论来回应。（比如，“那些白痴第一次就做得不对！”、“他们在偷工减料！”、“我就告诉过他们这样行不通的！”等等）

许多精辟的引用都能够说明这种权衡的概念，而成熟的工程师知道任何充满哲理的引用都是有局限的（包括我在本文写的那些）：

关于权衡的 要点 就是，每个人在每个项目都会偷工减料。不成熟的工程师事后才会发现，他们对此感到反感。而成熟的工程师在项目开始时就将它们写出来，接受它们，并将它们视为优秀工程的一部分。

（相关阅读：《你的代码可能很优雅》（Your Code May Be Elegant））

成熟的工程师不会去掩盖事实。

在这种情况下，如果有人以礼仪为借口而不去了解他的代码（或基础设施）如何被系统或业务的其他部分触及，那么这种情况就是一种失败的做法。自我保护 传递了这么一个隐含的信息，即你是那种只要你的工作有任何瑕疵的时候就会把别人（可能是你团队里的，或者你公司里的，也有可能是社区里的）推下公共汽车的人。而成熟的工程师会勇敢站起来，并接受交给他们的责任。如果他们发现没有必要的权力来对自己的工作负责，他们会想办法纠正这个情况。

掩盖事实的一个例子就是“这不是我的错，是他们弄坏了，用错了。我是按照规格做的，我不能为他们的错误或不合适的规格负责。”

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

在复杂的项目中，通常有许多利益相关者。在任何项目中，设计师、产品经理、运维工程师、开发人员和业务开发人员都有自己的目标和视角，成熟的工程师会意识到这些目标和视角可能有所不同。他们明白这一点，这样他们就能够有效地驾驭他们所做的工作。从这个意义上来说，同理心意味着有能力从他人的角度来看待这个项目，并在自己的工作中考虑到这一点。

目标冲突是所有工程师工作中都是固有的，抱怨它们（而不是将它们作为成功的必要条件）是一个不成熟的工程师的标志。

他们不会空洞地抱怨。

相反，他们会根据经验证据来表达自己的判断，并带着这些判断选项来解决他们已经确定的问题。我的一位优秀的经理曾说过，如果没有至少一个（理想情况下不止一个）的解决方案建议，就不要向你的老板抱怨任何事情。即使证明你已经尝试过自己解决这个问题，但空手而归，那也比空洞的抱怨要好得多。

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

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

从文化上讲，工程师每天都在研究中的经验证据中工作，基本上就是：给我看数据。认知偏见的问题在于，当我们用自己的大脑解读数据时，我们可能没有意识到这一点，这些数据有悖于经验数据，可能对我们如何完成工作和团队合作产生意想不到的影响。

关于认知偏差，维基百科 上就有一个很好的列表，但我见过的工程师（包括我自己）就不幸中招：

还有很多其他的认知偏差，我个人对这方面的资料饶有兴趣，我可以为了解所有的认知偏差而废寝忘食。如果你有兴趣了解如何限制自己的效率，我强烈建议阅读。

无我编程十诫

它很合适，即使年代久远……我看到它引用自 1971 年写的《程序开发心理学》（The Psychology of Computer Programming），但实际上我并没有在文本上看到过。无论如何，以下是无我编程十诫的内容，可以在  @wyattdanger 的博客 文章《父亲与无我编程十诫》（Dad and the Ten Commandments of Egoless Programming）中找到，这篇博文是从他父亲那里得到的建议：

  1. 人非圣人，孰能无过。理解并接受不完美的自己。 犯错无法避免，关键是要在错误进入生产环境前尽早发现。幸好除了一小部分需要在 JPL（喷气推进实验室）开发火箭制导软件的程序员外，大部分程序员都不会因错误招致生命危险。所以我们可以并且应该从错误中学习，一笑了之然后向前看。

  2. 你和你的代码是两回事。 记住，代码评审的目的是找出问题，问题当然最终一定会被发现。不要因为代码中被发现问题而对人产生偏见，闹情绪。

  3. 人外有人，天外有天。 三人行必有我师焉。不管你怀揣多少“秘笈”，都不要小觑别人的水平。只要你愿意虚心求教，一定会有人教你；当你认为你不需要的时候，更应该虚心求教。

  4. 沟通好再重构。 “修复代码”和“重写代码”之间只有一线之隔。搞清楚其中的区别，并在代码评审的框架内进行代码风格的变更，而不是孤军奋战。

  5. 尊重求教者，并耐心待之。 经常与开发人员打交道的非技术人员几乎普遍这样认为，这些专业人士充其量不过是一群自负的人，还是爱哭的娇气包。因此，我们要用耐心和谦和来消除他们对技术人员的误解。

  6. 世上永恒不变的就是变化。 我们要做到以风起的日子笑看落花的心态来看待变化。将你的需求、平台或工具的每一次变更都视作一个新的挑战，而不是一些需要解决的麻烦。

  7. 真正的权威源于知识，而非职位。 知识造就权威，权威带来尊重，所以如果你想在一个无我的环境中获得尊重，就要先积累知识。

  8. 屡败屡战，虽败犹荣。 要明白，有时候你的想法会被否决。即使你是正确的，也不要报复，或者嚷嚷“我早就告诉过你了……”。不要把被推翻的想法看做是牺牲品，也不要把它当成战败的哀嚎。

  9. 切勿与世隔绝。 不要成为一个整天在小黑屋写代码，只有在买汽水时才会出来的人。这样你会失去与外界的联系，淡出人们的视线，失去控制。在开放的协作环境里，你会失去自己的位置。

  10. 对“码”不对人。 要批评的是代码，而不是批评写代码的人。尽可能让评论正面、积极，带动代码质量的提升，评论只涉及内部标准、编程规范、性能提升等方面。

新手与专家

现在我一般不太关注知识获取作为一个研究课题，但我确实相信，当谈论一门学科的进化本质时，很难避开这一课题。一个有趣的细分来自 Stuart Dreyfus 和 Hubert Dreyfus 的一篇名为《指导性机能习得心理活动的五阶段模型》（A Five-Stage Model of the Mental Activities Involved in Directed Skill Acquisition）的论文，该论文阐述了不同专业水平的特征：

该论文接着指出：

新手从明确的规则和基于知识的角度进行操作。他们深思熟虑，善于分析，因此他们决定或选择采取行动的速度较慢。

（这意味着新手深受局部合理性的影响。）

专家从成熟、全面、久经考验的理解出发，直观而无需下意识的深思熟虑。这是经验的作用。他们不会把问题看成一回事，把解决问题的解决方案看成另一回事，而是采取行动。

（这意味着专家是上下文驱动的。）

我不一定赞同在技能水平之间画出这样一条干线的概念，因为我认为与上面概述的相比，专业知识还有更多的粒度和方面，但我认为了解过于简化的类别还是有所帮助的。

秘密：成熟的工程师知道人们情绪的重要性（有时是非理性的）。

人们对技术、技术决策和技术方向的看法与关于细节的事实一样重要（如果不是更重要的话）。成熟的工程师知道这一点，并做出相应的调整。再次强调，同理心可以帮助你理解团队中的其他人对技术决策的感受，即使它们自己也并不容易表达出为什么会有这种感受。

人们对软件、架构或模式的信心在很大程度上会受到过去经验的影响，并可能会对使用它们产生积极或消极的反应。你以前有没有用过 mod_perl，发生过很多次神秘故障的那个？这样你就能理解，即使支持的专业知识和用例完全不同，你也不会对不愿意在另一家公司使用它而感到惊讶。你只记得这个：mod_perl = 大麻烦，所以在任何上下文中再次使用它时都要小心。

成熟的工程师在使用有负担的技术时就会理解这种现象，即使这是不合理的。说服一个团队使用他们不熟悉的工具和模式并不是一项简单的任务。“适合工作的工具”格言还有（有时无法量化的）舒适性作为参数。

“如果你不在乎谁得到荣誉，你就能取得惊人的成就。”

这句话通常被认为是出自 Harry S. Truman 之口，但看起来它可能首先是由以为耶稣会牧师以另一种形式说出来的。无论如何，这是另一个迹象表明你正在和一个成熟的工程师合作：他们认为项目的成功远远高于他们个人努力而得到的赞誉。在一个以工程师为驱动的组织中，赞扬或信任的归因可能是这种机能失调的根源，我认为这是因为它在很大程度上是无形的。

这种观念是自由的，一旦被理解并被内化，一个进步和创新思维的世界就会蓬勃发展，因为工程师并不会过分关注将工作等同于自己职业成功的个人责任。

并非结束

我现在很幸运能在 Etsy 与许多成熟工程师一起工作，这让我感到非常荣幸。我们确实是一个年轻的领域，虽然我认为，我们可以就这个问题从其他工程领域学到很多东西，但我也认为我们也是有优势的。在全球范围内，Web 与发布和分享信息的概念密不可分。如果我们希望将这个领域发展成一个真正的学科，就需要继续指出“高级”和“成熟”工程师的含义。


标签：工程师,没用,代码,他们,高级,成熟,工作
来源： https://blog.51cto.com/15060462/2677935