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

想，在咱们这个行业中，有不少经验知识，特别是关于如何成为合格的工程师。虽然在管理领域中有不少关于非技术性我的贡献者的“专家”角色和责任的书籍，但我并无看到多少现代书籍或帖子，直接讲述要如何才能成为一名优秀的高级工程师。一个值得注意的例外固然是 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 原则），大多数项目工程师所从事的项目都是以 最优化 和 脆弱性 为轴心的，而且他们所解决的问题是 急性 的或慢性 的。

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

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

• “过早的优化是万恶之源。”这是一句被滥用的格言，我 以前 也写过，由此能够得出一个推论（可今后文《剖析当今互联网流量高峰》（Dissecting Today's Internet Traffic Spikes）开始）。“高级工程师和初级工程师的区别在于，前者知道哪些是‘过早’的，哪些不是。”

• “适合工做的工具”，这是另外一个被滥用的格言。这句话的意图是合理的：有谁愿意使用不合适的工具呢？但有一种罕见的观点认为，若是采起极端措施的话，多是有害的。木匠不会用各类各样的锤子来武装本身，即便他可能会遇到每一把都能理想地完成锤击任务的锤子。为何呢？由于拖着（以及维护）那么多锤子处处干活是要付出代价的。所以，在这条轴上做出决策是要进行权衡利弊的。

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

（相关阅读：《你的代码可能很优雅》（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 与发布和分享信息的概念密不可分。若是咱们但愿将这个领域发展成一个真正的学科，就须要继续指出“高级”和“成熟”工程师的含义。