作者：addyosmani

今天，我将分享一些软件工程“软技能”，这是我在使用 Google Chrome 的前 10 年中学到的，我在 Google Chrome 担任高级员工工程经理。在我入职 10 周年之际，我想反思一些一直伴随着我的教训。我希望这些在您的职业生涯中对您有用。

成为一名优秀的工程师就是要积累经验。每个项目，即使是小项目，都是向您的工具箱添加新技术和工具的机会。当您可以通过将在一个项目中学到的技术与在另一个项目中学到的工具配对来解决问题时，这会带来更多价值。这一切加起来。

首先，我会说我不重要、不明智且缺乏原创性。YMMV :)

学习新事物

以下要点应该可以帮助大多数初级或中级职业开发人员在遵循软件工程范例中的标准流程和发现新的最佳实践的同时，继续前进、应对不断变化的技术并构建复杂的系统。尽可能应用首要原则。学会将问题分解成更小的部分是生活中最重要的技能之一。

精通

精通技术意味着交付的价值与工作时间的比率很高。

这意味着您可以识别增加价值的任务，并帮助您的团队将精力集中在那个方向上。这也意味着你知道如何避免不为团队/公司提供价值的工作——最好的工程师甚至可以引导整个团队远离没有那么有用的工作。处理最重要的事情。

我经常被问到，“我怎么知道我是否在充分利用我的时间？”。几乎总会有一些任务可以让您“感到”忙碌。这里真正的诀窍是确保你在做正确的事情。如果您想移山，请专注于移动针头的任务，即使该移动很小。

您可以问自己一些问题：

• 我的目标是什么？我关注的任务是否符合这些目标？

• 有什么我可以做的不同或更好的吗？

即使问自己这样的问题也会非常强大。

批判性地思考并制定有充分理由的论点

批判性思维是使用认知技能独立思考以做出深思熟虑的决定的能力。投资这项技能可以提高您的思维清晰度。

作为工程师，我们有时会急于立即解决问题，这样感觉就像我们正在取得进展或看起来我们正在对利益相关者做出回应。如果我们没有充分考虑因果关系，这可能会带来风险。换句话说，批判性思维是有目的地思考并形成自己的结论。这种以目标为导向的思维可以帮助您专注于根本原因问题，避免因未牢记因果关系而产生的未来问题。

概括地说，我喜欢基于批判性思维提出的一些问题是：

• 我们怎么知道我们正在解决正确的问题？

• 我们怎么知道我们正在以正确的方式解决问题？（即根据我们对问题和约束的理解，平衡严谨性和效率）

• 如果我们不知道问题的根源，我们如何确定根本原因？

• 我们如何将关键问题分解成更小的问题，以便我们进一步分析？

• 一旦我们有了一个或多个假设，我们如何构建工作来评估它们？

• 如果我们在限制（时间压力）的情况下不过度损害我们围绕问题的分析严谨性，我们可以采取哪些捷径？

• 证据是否足以支持结论？

• 我们怎么知道什么时候完成？什么时候解决方案“足够好”？

• 我如何向所有利益相关者清晰、合乎逻辑地传达解决方案？

我发现这些问题通常很有帮助。有时我们会解决问题的症状，却发现还有其他症状突然出现。在其他时候，我们可能会快速交付一个解决方案，但会在以后产生更多问题。借助批判性思维，我们可能会挑战假设，仔细研究风险/收益，寻找相互矛盾的证据，评估可信度并寻找更多数据来建立我们正在做正确事情的信心。

例如，我见过工程师犯的一个常见错误是假设相关性意味着因果关系（即仅仅因为两件事相关并不一定意味着一个导致另一个）。一个批判性的思想家可能会反驳这样的假设，问我们为什么相信它们是真的。

批判性思考者：

• 提出有意识的问题，清晰准确地表述它们

• 收集和评估相关信息，验证他们如何回答问题

• 得出合理的结论和解决方案，并根据相关标准和标准对其进行测试

• 在不同的思想体系中以开放的心态思考，根据需要识别和评估它们的假设、含义和实际后果

• 与他人有效沟通，找出复杂问题的解决方案

注意：批判性思维既是“软技能”又是“硬技能”，因此包含在本文中。

筑牢基地

掌握基础知识并反复应用它们以获得新技能。

学习基础知识的长期价值在于它们是可迁移的。短期是它们可以帮助您做出更好的决策，并使代码更有效率。

可转移技能

可转移技能是那些你可以从一个项目带到另一个项目的技能。让我们从基本面的角度来谈谈它们。

基础知识是任何软件工程职业的基础。它们有两层——宏观和微观。宏观层是软件工程的核心，微观层是实现（如技术栈、库、框架等）。

在宏观层面上，您学习的编程概念在很大程度上不受语言影响。语法可能不同，但核心思想仍然相同。这可以包括以下内容：数据结构（数组、对象、模块、哈希）、算法（搜索、排序）、架构（设计模式、状态管理）甚至性能优化（例如急切与惰性求值、记忆、缓存、惰性- 加载等）。这些是您会经常使用的概念，因此向后了解它们可能具有很大的价值。

在微观层面，您将学习这些概念的实现。这可能包括：您使用的语言（JavaScript、Python、Ruby 等），您使用的框架（例如 React、Angular、Vue 等），您使用的后端（例如 Django、Rails 等），以及技术您使用的堆栈（例如 Google App Engine、Google Cloud Platform 等）。其中涉及的细节对于获得有效的专业知识可能很有价值，但并不总是可转移的。

通过学习基础知识，您可以获得技能组合和工具，然后忽略基础知识并成长。

也就是说，从实用的角度来说，没有人有时间在他们职业生涯的开始就学习所有的东西。有一点你不应该过度索引基础知识并学习为现实世界实际构建应用程序所需的内容。这就是“边做边学”方法的用武之地。

效率

很好地理解基础知识可以帮助您编写更高效的代码。这包括时间复杂度（运行代码所需的时间）、内存使用以及性能和可维护性之间的权衡等概念。这些想法允许您在构建任何相当大的应用程序时做出有用的权衡。速度对于现代应用程序通常至关重要，并且通常会以明显的方式影响最终用户体验。

更好的决策

充分了解宏观和微观基础知识可以帮助您做出更好的决策。

您可以根据任何项目的目标和约束，使用您获得的知识更好地决定使用哪些技术以及避免使用哪些技术。这可以帮助您避免为工作选择错误的技术或工具的陷阱。

“在你明白什么时候不应该使用它之前，你还没有掌握一种工具。” - @kelseyhightower

软件工程涉及考虑许多不同的层次——核心语言、实现、基础设施、工具和人员。只有对这些层次有一个表面的认识绝对可以让你更快地构建。但真正了解基础知识（包括 O(n) 时间复杂度）可以帮助您走得更远，尤其是当语言和框架的格局随时间变化时。

相关阅读：

• 软件工程基础知识的价值

• 为什么学习基础知识很重要

• 了解良好开发人员心态的基础知识
  

专注于用户，其余的将随之而来

从用户体验开始，然后倒退到您需要的技术。

史蒂夫·乔布斯 (Steve Jobs) 曾说过一句名言：“你必须从客户体验开始，然后倒退到技术。你不能从技术开始，然后再想办法把它卖到哪里去。”。

这句话让我印象深刻，因为作为工程师，从想要使用特定解决方案的地方开始太容易了——无论是由于受欢迎程度、开发人员经验还是仅仅是个人偏好——并试图找到一种合理化使用它们的方法。相反，我们应该关注我们为谁而建，他们有什么问题，以及当前可用的选项如何不足。

出色的用户体验来自于结合两种观点——客户和技术。向人们展示您认为他们想要什么，并注意他们所说的话。当然，这个问题空间存在巨大的细微差别——哪些工程选择可以让您在移动硬件上提供出色的体验？哪些选择会影响工程速度？或规模？或招聘？最终，我们受益于首先不懈地关注客户，然后在我们必须处理的限制范围内导航什么使我们能够满足他们的需求。

最好的软件是由对用户有同理心的工程师开发的。

商业成功取决于客户满意度，在软件的情况下，客户满意度通常转化为用户体验。了解最终用户如何体验产品或服务。确保您的解决方案不会妨碍他们高效完成工作的能力。如果您的职位允许您直接与最终用户互动，请尝试更好地了解他们的需求和痛点。

提升技能

选择适合您的用例的内容，而不是当月的风格。

使用“无聊”技术（经过尝试和测试的技术）与炒作火车是可以的。语言、框架和库经常发展。选择有助于交付出色最终产品的技术。开始新项目时，从“无聊”技术开始（但很好理解）然后有意地决定从中选择解决问题的最佳工具。

在选择要学习或使用的新技能时，不要害怕选择无聊且不在新闻中的东西。当涉及到技术时，无论是语言、框架、库还是工具，FOMO 可能都不会产生效果。虽然了解使用什么很重要，但您的主要目标是交付出色的最终产品。请不要追逐闪亮的新技术，除非您认为它们可以为您的解决方案增加价值。同时，不要因为谈论得不够多而回避某些事情。

利用新项目学习新技术。

同时，个人和黑客马拉松项目可以成为学习新技术的绝佳机会。与在已经做出许多决定的现有代码库上工作相比，我们中的许多人很少有机会开始全新的事情。此类项目可能是研究新技术、评估其优势和劣势（小规模）并积累一些对您未来可能有价值的第一手知识的低风险方式。

保持好奇心，永不停止学习

写下你学到的东西。它会促使您更好地理解主题。有时，只有当您尝试向他人解释事情时，您的知识差距才会变得清晰。如果没有人读你写的东西也没关系。为你做这件事，你会得到很多。

学习应该是一个持续的过程——声称对特定技术无所不知的人往往不是专家。真正的专家精通这项技术，但意识到总有学习和改进的余地。好奇心驱动学习 - 所以如果你对一个新框架感到好奇，谷歌它，阅读文档，尝试教程，阅读源代码！学习不需要发生在课堂上。它可以随时随地发生。每天花半小时阅读课本中的一章、收听技术播客、阅读开发博客或学习一门新的编程语言。

领导者在不知道某事时承认是很有力量的。

拥有这种信心会降低对高级工程师必须无所不知的期望。你绝对不需要知道所有的答案，但能够承认你是人，并致力于弄清楚如何与你的团队一起解决问题是重要的部分。

领导者犯错也要承认。

重要的是要教会您的团队如何谦虚地处理错误以及学习和改进的愿望。现实世界并不完美，向您的团队展示让他们为此做好准备并不完美是完全可以的。

做一个看守者，而不是主人。

在开源项目的早期阶段，像所有者一样思考是很常见的。您通常直接拥有证明价值、开发功能、回答问题和宣传的权利。这对于采用某些东西可能非常有用，但可能不是在人员变动或您自己的时间有限时扩展项目的最佳方式。

在最初的紧缩之后，另一种思考角色演变的方式是成为看守人，而不是主人。看守人可能会专注于扩大自己的规模。这可以通过与其他维护者、贡献者和社区共享尽可能多的知识来完成（通过设计文档、代码评论和其他记录在案的最佳实践）。它还有助于增加具有足够上下文的审阅者库，以便在您不再参与时做出正确的决定。

这通常是项目需要在未来多年可持续发展的条件。

技能的深度和广度

考虑成为万事通和精通大师是否适合您。

您可以掌握的最重要的技能之一就是学习如何学习。这应该优先于说，只是深入研究特定的编程语言或框架。它有助于保持好奇心。一旦你有了这方面的经验，你可能会质疑你应该以成为专家还是万事通为目标。

我个人喜欢T 型工程师的想法。这些工程师精通一种或少量技能（T 的竖线），但对构建和运行产品所需的许多其他技能（横线）有基本的了解。一些团队喜欢通过一系列不同的专业轮换团队成员，以建立更多的 T 型团队成员。

我发现，在大中型团队中，如果有必要，让在某一领域拥有专业技能并且具备技能、多才多艺和协作能力的人来填补其他人的空缺是很有效的。

体验就是学习

学习一门新语言时，专注于用它构建一些有形的东西，让你有第一手的经验。

如果您正在学习一门新语言，则无需记住其所有语法或文档即可成为一名优秀的开发人员。更重要的是知道如何解决问题。通过编写大量相关代码或从现有代码中学习来获得经验。结果应该可以帮助您用该语言编写高效的代码。正如这里提到的，“软件的主要价值不是产生的代码，而是产生它的人所积累的知识”。但是，在试验新技术时请不要在生产中进行试验。

技术复杂性

通用代码与特定代码

专门针对手头的问题编写代码，但尽量找出可以负担得起的地方，使其变得有点通用。

通常，我们试图编写尽可能通用的代码，并最终制作出无助于解决问题的有效代码汤。相反，专门针对这个问题构建，但试图找出可以让它变得更通用的地方，这完全消除了我知道如果我没有想到的话我以后不得不再次重构的时间。

有几个通常讨论的原则来讨论设计复杂性。在极限编程世界中，您拥有：

• YAGNI或 You aren't gonna need it，它指出程序员在必要时不应添加功能。

• 做可能有效的最简单的事情——快速进步而不是为未来做计划。

这两个原则都旨在防止过度工程。然而，这些原则可能会被滥用来创建多个不能很好集成的简单解决方案。

另一方面，您拥有抽象原则，旨在通过抽象和概括在可行的情况下减少代码中的重复结构。我更喜欢通过使代码稍微通用一些来在极端抽象和极端简单之间采取中间立场。AHA （避免仓促抽象）原则提倡类似的想法。

深层模块

编写代码为其他开发人员解决复杂问题，但通过清晰的界面公开功能。

如果您是 API 设计者或开发者——您的责任是提供一个接口来为其他开发者简化复杂的功能。如果界面太难理解并且给使用它的程序员带来成本，那么目的就落空了。这种想法反映在Deep Modules的概念中——“最好的模块是那些收益最大且成本最低的模块。模块提供的收益是它的功能，而模块的成本是它的接口。”

虽然接口的简单性是可取的，但复杂的问题有时需要复杂的代码来解决（这虽然不是普遍规则，但通常是正确的）。这种复杂性最好嵌入代码中。当复杂的功能被抽象出来时，提供给最终用户或界面用户的价值更高。

与使用较少公共函数/类实现相同功能的另一个 API 相比，具有包含某些功能的多个可见函数和类的 API 更加复杂且难以搜索。新函数和类增加了维护程序员和库用户的接口成本。

习维护项目

在旧系统中处理遗留代码时，了解应该保留的代码和应该删除的代码之间的区别。

任何高级工程师都应该努力理解应该留下的代码和应该离开的代码之间的区别。

大型、长期的生产系统将有一些错误的代码或没有充分理由继续保留的代码。理解为什么会有某些东西是健康的（好理由？坏理由？）。删除坏代码并保留好代码。

我曾在许多公司工作过，在这些公司中，人们认为遗留代码是不可触及的，或者是出于充分的理由按照原样设计的，已经被时间流逝了。这可能会导致害怕改变，因为你只是不断地向薄弱的基础添加抽象。

软件行业已经到了这样一个阶段，许多项目都涉及旧系统或遗留系统的维护和迁移。如果您发现自己在这样的团队中，请不要感到沮丧。通过查看旧代码，您可以获得许多特定领域的知识。虽然生产中存在旧代码/验证可能有充分的理由，但最好不要假设每一行仍然相关。

一些软件工程师对接触生产中的代码持谨慎态度，因为害怕引入错误。因此，它们包含条件并为较新的用例重复一些代码。这样的解决方法可能会在那一刻节省时间，但随着时间的推移它们会变成维护的噩梦。不要假设现有代码是有福的或绝对可靠的。您可能会解决以前忽略的可扩展性或效率的某些方面。

学习新项目

试验、创新、快速失败并更好地解决问题。

当您的任务是从头开始构建系统时，您的学习旅程将完全不同。当您开始原型设计或以迭代方式实现功能时，您会了解哪些有效，哪些无效。敏捷方法和快速失败原则可帮助您以更少的资源更早地验证您的想法。它们使您能够分而治之，解决复杂的问题。

完成的定义

定义“完成”的内容可以节省时间，因为它可以帮助您估算所需的工作量、制定开发计划并避免以后进行不必要的修改。

另一个在处理复杂性时派上用场的敏捷原则是就完成的定义达成一致。除了满足用户要求和验收标准外，这还可以包括其他条件，例如代码审查、测试、文档等。

分阶段推出

一个单一的大型版本可能会被分成一系列低风险且易于理解的发布。

在规划大规模生产系统的发布时，推出计划与体系结构和代码一样重要。具有迭代开发的分阶段发布可帮助您更好地管理由于重大更改而带来的风险。您还可以使用开发和测试策略创建发布策略，以便为复杂的发布制定端到端的计划。

系统调试

调试时，应尽量系统、严谨地解决问题，以解决所有测试条件。

始终阅读错误消息（和堆栈跟踪）。那里可能有有价值的信息，可以帮助您隔离问题，以便解决问题。在寻求调试帮助之前，数量惊人的工程师忽略了错误消息可以提供的洞察力。假设你的机器告诉你哪里出了问题，也可能是正确的，而不是假设进行小的编辑并不断重新运行代码会更快地解决问题。如果您编写了一个抛出异常的解决方案并且没有仔细阅读异常，那么您可能是在浪费时间。通常，错误或异常消息是一个很大的提示，表明实际上出了什么问题。

设计文档

设计文档的重要性

设计文档不应该是事后才想到的，而应该是软件工程过程的一个组成部分。

设计文档是一种无处不在的工具，可以帮助您从需要与您的系统部分进行交互的同行或其他团队那里获得共识。来自他人的反馈使您能够找出差距并改进您的设计。设计文档还可以为将来加入团队的工程师提供宝贵的帮助。这将帮助他们了解问题空间以及设计解决方案时考虑的权衡和备选方案。设计文档提供了一个空间来捕获参与设计的所有参与者及其作为文档历史的一部分的贡献。这有助于其他人了解是谁推动了具体的决定，以及应该联系谁进行进一步的阐述。

文档处理

协调对设计文档的审查，并将设计的演变与原始文档进行比较，以验证是否解决了所有相关约束。

虽然一个人可以记录设计，但实际的设计过程发生在一系列白板会议、随机的面对面讨论、闲谈或电子邮件/电话讨论中。只有在将其写在纸上之后，您才能识别相互矛盾的承诺，并查看您讨论的不同部分是否适合。创建初始草案后，协调审查可确保所有相关方都参与其中。但是，可能会发生实施的设计与记录的内容不匹配的情况，因为在此过程中发生了一些变化。

沟通

谦虚、清晰地沟通并尊重他人。友善不需要任何成本，但影响是无价的。有些人可能会说良好的沟通需要精力和体贴。应该有更多的能量用于慈悲。

沟通是成为有效、多产和高效软件工程师所需的软技能或人际交往能力的关键部分。沟通不畅会导致功能不正确、代码不兼容或攻击性团队动态。沟通可以帮助人们更好地理解需求并防止问题升级。

世界可能会把软件工程师想象成整天写代码的人。然而，为了确保我们的产品对他人有帮助，我们必须将我们的努力与团队中的其他人以及业务和用户的期望同步。这使得协作和沟通成为我们工作的关键支柱。

初级开发人员主要与其他团队成员、测试工程师和团队负责人交流，以分享想法并讨论解决问题的备选方案。随着我们职业生涯的发展，有效完成工作所需的沟通量也会增加。电子邮件、会议和公开演讲的数量增加了。我们必须与业务领导、经理、利益相关者和团队成员进行沟通。你的工作越专业，别人不容易理解你的风险就越大。

定制通讯

使用与您的听众相关的语言、概念和详细程度。

无论我们对问题或情况的理解程度如何，当我们与他人讨论时，我们都必须调整我们的措辞，以便他们能够快速掌握与他们相关的内容：

• 与业务人员交谈时，谈谈您所做的事情对业务的影响。避免使用过于专业的术语。

• 与工程管理人员交谈时，传达技术影响或挑战。

• 与决策者交谈时，您描述的是可用选项及其影响和风险，而不是选项如何运作的细节。

• 在提供状态更新时，请注意还发生了什么以及您的更新与项目目标的相关性。

同样的原则也适用于撰写电子邮件和向更多观众展示时。写下与接收消息的人相关的内容。演讲时，您可能必须捍卫自己的想法。以深思熟虑的方式表达问题和回答。膝跳反应通常不利于沟通。

善良体贴

友善是一种超能力——运用它。

冷静、友善和乐于助人比切断别人的联系更能让你走得更远。对团队中的人友善，因为这将有助于使团队更强大和成功。对团队以外的人也要友好。平等尊重组织中的所有职能（人力资源、财务或营销）。你可能不会直接帮助他们，但你总能理解他们的工作，感同身受。当别人做得好或获得赞誉时，向他们表示祝贺或赞赏。善良是会传染的。您一直友好的人将来更有可能回应任何帮助请求。

大方地告诉人们他们做得很好。

虽然在需要改进时提供反馈很重要，但如果事情进展顺利，给人们积极的反馈也很重要。这有助于您的团队知道他们正在发挥作用并且受到重视。

NO的力量

说不比过度承诺更好。

我们大多数人都不擅长在涉及更多工作时说“不”。要么是因为他们没有意识到“不”是一种选择，要么是因为我们喜欢挑战。然而，过度使用是一种负担，因为它会导致延误。让对方知道你盘子里已经有什么，并合理估计需要多长时间是一种尊重的表现。它让其他人有机会考虑他们的选择——询问其他人或延长他们的时间表。如果管理层知道这会显着影响产品质量，他们就不会要求您在创纪录的时间内交付产品。如果您是高级经理，请授权您的团队拒绝坏主意。

“高级开发人员（或任何有生产力的人）擅长说不。人们会要求你花费比你腾出的时间更多的时间。你可以温和但坚定地说不，将人们带到别处（委托），或者要求人们与你的经理是否可以分配更多的时间来帮助他们。” [1]

您无法取悦所有人——在说“是”与“否”时要格外小心。

领导者对一切都说“不”的对应物是对一切都说“是”并且没有设定明确的界限。承担比您当前资源实际可以合理执行的范围更大的范围，可能会让您、您的团队乃至您的客户感到心痛。这对于领导者来说尤为重要，因为其他人会指望你为他们应该说“是”或温和地反击的时间设定规范。

纳与尊重

当您不知道某事时要承认并乐于寻求帮助，即使是向后辈寻求帮助。

当你不知道某事时，承认是可以的。软件最重要的技能之一是能够找到答案并从中学习

作为高级领导者，要学会接受你周围的初级人员可能更了解项目的技术细微差别。不懂就承认，让低级工程师解释，也无妨。他们会因为你的诚实和对学习的兴趣而更加尊重你，你会更好地了解正在发生的事情并为其增加价值。作为一名初级工程师，您应该向年长者公开或秘密地解释技术概念，这取决于他们的舒适程度。

信息共享

利用会议和问答环节提出正确的问题、交流知识并通知团队。

主持会议时，不要成为唯一发言的人。会议是其他人分享想法和提供诚实反馈的机会 - 所以倾听并为其他人贡献空间。

初级工程师可能会回避问太多问题。如果您是高年级学生，您可以通过提出上下文来提示他们提出正确的问题。回答问题时，让提问的人知道您很高兴他们提出这个问题。

灵活性

尖锐地捍卫你的观点，但每当你有新的证据与它们相矛盾时，也要重新审视它们。

倾听他人的意见是沟通的关键部分。这很重要，因为一个问题可能有不止一种解决方案。与其固执己见，不如倾听并评估其他选择。也许他们会提出你之前忽略的一个方面。Paul Saffo 的“强势观点弱化”原则告诉我们要坚决捍卫我们的观点，但每当我们有新的证据与它们相矛盾时也要审查它们。这是一种基于科学证据的方法，不考虑提出想法或意见的人。

保持记录

非正式会议后的友好电子邮件有助于重申讨论中的要点或承诺。

完全口头交流的一个缺点是它可能会被遗忘或记错。记录所有发生的事情并在相关讨论上签字可以消除这种风险。如果您或其他人同意帮助完成一项任务，请通过电子邮件确认截止日期，以确保包括您的主管在内的每个人都在同一页面上。记录此类计划外工作在评估讨论期间也很有帮助。

诚信

知道什么时候保持安静并观察游戏中的动态。

在某些情况下，您可能不理解某些决策，或者出于技术和业务原因它们没有意义。这可能发生在多团队讨论中。善意参与并假设人们不会冒公开恶意的风险。可能您不了解完整情况，或者他们有不同的优先级。提出问题并陈述您的意见，但不要对最终决定感到生气或沮丧。

资历

我们渴望在我们的职业生涯中成长，无论是在我们的角色还是在能力方面。有些人对高级技术职位感兴趣，而另一些人则希望担任领导或管理职位。无论哪种情况，资历较高的人都会表现出一些关键特征。在您的整个旅程中，您可能会有导师指导您的成长。以下是我培养可以为高级职位做好准备的素质的方法。

资历与战略思维

不要在不确定的情况下做出决定或采取行动。

很多时候你会发现做任何决定都比什么都不做要好。至少能让别人知道你的倾向。有时，作为领导者，我们没有花足够的时间来思考我们的团队希望我们做出哪些决定，但我们没有做出，因为我们不能 100% 确定我们掌握了所有事实。我们可以而且应该尝试构建尽可能完整的细节图，以做出自信的决定，但这并不总是可能的（例如在时间紧迫的情况下）。这可能会导致团队长时间等待/不确定，这有助于在信息有限的情况下积极改进自己如何做出决策。

领导者是那些拓宽了视野，能够进行战略性思考并为他人制定路线图的人。

理想情况下，您的战略性思考和计划以及将您的思维应用于更大范围的能力应该随着经验的增长而增长。作为个人贡献者，您可以专注于分配的任务或您正在处理的功能。当您攀登阶梯时，您的工作影响超出了特定的任务和项目。在权衡选项时，您会学会从好处和限制的角度来看待更大的图景。软技能的应用范围也越来越大。例如，如果之前您正在为一个团队做决定或向您团队中的其他工程师讲话，那么随着您的成长，您的选择和沟通会影响多个团队。

以身作则

教你的团队钓鱼。不要总是为他们解决问题，而是温和地引导他们发展自己解决问题的技能。

工程领导者授权。随着您的资历越来越高，放弃您的玩具、指导、委派并让您的团队取得成功会有所帮助。这就是你衡量效率的方式。这可以通过提出更好的问题而不是（仅仅）给出答案来实现。

您在评估具有挑战性的问题时以身作则，并在有人提供解决方案时提出相关问题。

技术轨道的资深人士负责团队内外的协调、谈判和建立共识。他们有助于提高整个团队的产出，而不仅仅是他们自己的产出。作为一名高级工程师，您可能偶尔会通过编码来获得新技能或了解实际情况，但这不是您工作描述的一部分。相反，您是确保体系结构图中没有任何遗漏的部分或代码中没有漏洞的人。你应该能够用证据或理由来解释你的决定，说明它们将如何提供技术或商业价值。

高级工程师应该擅长架构软件系统和人类系统或团队。您可以领导多元化的工程师团队，将任务委派给他们，指导他们关心代码质量/性能/简单性。您可以在需要时提供反馈，并在必要时为他们辩护。同时，您应该能够推销自己、您的工作以及您解决具有挑战性问题的能力，从而在组织中获得知名度。总的来说，您应该管理与团队和管理层人员的关系。

扩展你的效率。

世界上最好的工程壮举是由工程师团队而非个人完成的。因此，如果您想取得更多成就，或者表明您已准备好在公司中变得更“资深”，请通过协作和指导来提高您的效率。展示这如何不仅为您自己而且为您团队的其他成员增加价值。

当我意识到要扩大自己的规模时，我觉得自己正走在成为谷歌高级工程师的道路上，我必须将思维方式从“我”转变为“我们”。通过与他人合作，分享我学到的东西，并专注于提升我周围人的技能和专业知识，我们开始完成更多的工作。

当您开始作为个人贡献者时，您可能没有领导的专门“团队”，但您可以找到志同道合的人合作（可能与您的目标一致）并共同完成比您单独完成的更多的工作. 随着您的资历越来越高，您会将这种思维发展为建立团队和持续提高您的效率。

冒名顶替综合症

承认犯错、不知道答案或寻求指导是可以的，这有助于克服冒名顶替综合症。

在某些时候，我们所有人都觉得不适合特定的角色或工作。冒名顶替综合症是真实且非常普遍的。它甚至会影响那些明显成功的人。即使其他人向您寻求建议，您也可能会觉得自己像个冒名顶替者。你可能永远无法治愈这种综合症，但它会促使你产生好奇心并学习新事物。

辅导

指导他人

通过提供及时的信息成为护栏，这样您的受训者就不会在完全错误的地方结束，而是通过自己做事来掌握。

您可能会发现自己在职业生涯的不同时期担任导师或受训者的角色。指导不一定是一个正式的过程。您可以寻找机会指导他人或让自己接受非正式的指导。指导他人让您有机会自己学习人际交往能力。以下是指导时要记住的一些要点。

指导是指导人们自己发现答案，而不是给他们现成的解决方案。允许您的受训者在解决他们的问题时进行实验。他们最适合评估风险和收益。但是，请给他们寻找答案所需的工具。如果这是一个技术问题，建议尝试的想法和选项，但让他们做实际的跑腿工作。让他们分享他们的想法并仔细聆听、提出问题并参与对话。

如果有人无法自行找出解决方案，请向他们展示您将如何处理该问题以及您为什么选择特定模式来解决它。教他们如何分析结果或调试问题。在您诊断问题、尝试解决方案、实施和调试解决方案时分享您的思考过程。分享您解决问题的技巧，而不仅仅是答案。

全组织指导

确保指导是高级工程师角色的一部分，还有助于在某人调动到另一个团队、职位或组织时保留关键的领域知识。

假设你真诚地指导某人，这也是你工作描述的一部分。在这种情况下，您必须在日程安排中抽出时间进行指导活动。这将使您能够正确地做到这一点，并改变您的受训者的生活。一些组织可能还根据职业发展阶梯和每个步骤的要求为导师/受训者讨论制定了明确的流程。

色

导师可以为您提供建议，但您是唯一可以采取主动并根据任何建议采取行动来管理您的职业和成长的人。

假设您是一名希望在组织中成长的初级工程师。在这种情况下，只有一条建议适合您。寻找可以帮助您驾驭成长阶梯的强大导师。

在您的职业生涯中，您会遇到您敬仰的教练、导师或同事。他们可以为您提供有关如何发展技能的建议，但您是可以采取行动的人。在吸收建议时，请注意有关技术的笼统陈述。不同的情况需要不同的原则，适用于一个项目的方法可能不适用于另一个项目。

有效的团队

建立信任

信任可以团结团队成员朝着共同的目标努力，而官僚主义会使他们分裂。

当工程师聚集在一起进行思想开放和公正的头脑风暴时，它为推动创新的新想法和不同观点铺平了道路。这导致了高效和多产的团队。然而，只有团队成员之间的沟通和关系健康，团队成员之间的有效协作才有可能。这里有一些关于建立、维护和成为有效团队的一部分的建议。

建立信任是团队建设中最关键的组成部分。整个层次结构的团队成员之间的信任对于快速完成工作和团队有效是必要的。团队成员可能会使用不同的软件工程过程，例如审查和测试来审查项目的健康状况。然而，如果没有信任，这些过程就会变得乏味和官僚。例如，如果您相信某个工程师会处理某些代码，那么您在代码审查期间可能会更少吹毛求疵。

了解商业模式

了解变更对业务的影响。

当您收到一组新的需求时，了解它们背后的动机。不要浏览需求文档的“目的”或“业务目标”部分。提出问题以了解业务模型及其与这些要求的关系。现有代码库或与主题专家 (SME) 交谈可以提供有关领域和架构的见解。请参阅文档或将功能和用例映射到系统流程和数据流。

“许多软件工程师喜欢通过技术挑战来解决问题。了解事物的业务方面并能够提出具有成本效益的解决方案可能会更有价值。请记住，您的用户/客户也是尝试做的人他们的工作，像你一样度过一天或一周。尽量不要让他们的生活比现在更艰难。” [1]

增加影响力

对商业软件等式的洞察力和敏锐度会增加您工作的影响力。

获得业务和产品的 360 度全方位视图有助于您为团队和项目做出积极贡献。如果您了解销售或市场营销的思维方式，您就能更好地做出正确的决定并开展高影响力的工作。随着您对团队成功的影响增加，您的工作满意度和薪酬也会提高。你的上司会认识到你作为一个自我启动者的能力，可以在没有监督的情况下独立工作，并通过做适合团队、项目和业务的事情来提高整体效率。

工作与生活的平衡

如果您掌握了技术能力、人为因素和领域知识，那么您作为软件工程师的技能将不可避免地受到需求。你的团队和组织中的人会咨询你。除了您的工程承诺之外，您还将成为协作过载的受害者。临时请求会占用您的时间并阻止您做您热衷的事情。

时间管理

为深度工作优化你的日历

在日历上预留时间专注于深度工作。我已经这样做了很多年，发现它对于编写设计或策略文档或处理一个棘手的技术问题非常有效。深度工作是一种无干扰、高度集中的工作，可以在短时间内创造大量价值。Cal Newport 的 Deep Work 很好地涵盖了这个主题。

注意力残留是 Cal 谈到的一个想法，它解释了为什么长时间深度工作如此有益。每次你从一项任务切换到另一项任务时，你的注意力都会停留在前一项任务上。这使得很难将必要的注意力集中在真正重要的事情上。

通过专注于一项任务，深度工作可以最大限度地提高您在有限时间内挤出的生产力。没有干扰，没有推特，没有聊天或电子邮件。你为认知繁重的任务保留深度工作。我强烈建议您尝试一下。

我还发现，改变我的位置有时可以帮助深度工作。我们有时会掉入陷阱，将特定地点（如办公桌、房间或建筑物）与特定类型的任务相关联，添加一点变化可以帮助我们重振精神。

避免打断你的工作时间

当一个小时的工作由于分心而被分解成几分钟的小块时，你就会感到压力。确定分心的原因（无论是你还是其他人）并解决它。否则你的一天将不会那么富有成效。

过度工作不是良好职业道德的一部分。

你永远不可能比世界上任何人都更努力。许多公司将员工超负荷工作作为“标准”，错误地认为这与拥有良好的职业道德是一样的。成功来自许多因素，而不仅仅是过度劳累。

不断地试图超越你的标准是不现实的。

我为此感到内疚。如果你想培养冷静并避免疯狂的工作环境，你必须适应足够的环境。作为经理或领导，您的团队可能会带头解决这个问题。足够好可以树立一个很好的榜样。

时间是有限的。与其试图争取更多时间，不如消除不必要的任务。

许多指导都谈到了更好地重新安排工作。真正的问题是一开始就试图完成太多。与试图管理有限的时间相比，无情地消除不必要和浪费时间的工作。

你不必知道最后发生的每一件事。

我们中的许多人都害怕错过每一个新故事或更新。这就是人们沉迷于每小时查看 Twitter、Reddit、Instagram 等的原因之一。我当然经历过这个。实际上，这些信息中的大部分都没有那么重要。相反，请尝试切换到该新闻的摘要视图或限制您查看它的频率。

在Jason Fried 的“ It doesn't have to be crazy at work ”中对这个话题有进一步的思考。

最好通过学习说不、知道何时停止以及计划时间以包括工作之间的休息时间来主动避免精疲力竭。

时间管理和保持良好的工作与生活平衡对于各级工程师都至关重要。经常加班会导致倦怠和压力。压力会导致其他身心健康并发症。在您收工之前解决问题可能很诱人，但随着时间的推移它可能会成为一种习惯。

鼓励您和您的团队休息、休假和休假。

您的健康和家人至关重要。如果您作为一名高级工程师意识到这一点，并为团队中的其他人树立了良好的榜样，这将促进整体幸福感。另一方面，精疲力尽和倦怠会导致工作场所中毒。

随着您对问题的理解的提高，更新估计

对于您的工作，几乎总会有客户或利益相关者想知道何时可以交付项目或任务，以及这笔费用是否值得。这是完全合理的。有时他们想要在最后期限之前完成，或者在其他地方有依赖项需要支持您需要规划的工程工作。

众所周知，软件截止日期很难准确预测。基于估计的最后期限只应在项目处于特定阶段时给出。随着时间的推移，随着我们更多地了解团队解决问题的能力（“知情”估计），估计应该得到更新。第一次估计（“规模调整”）通常是最不可靠的，但它是一个可以随着时间的推移得到完善的起点。这个初始估计通常是非常保守的——如果产品要求、用户体验或依赖关系不清楚，一个更大的保守估计通常对第一个“尺寸”有帮助。当此类估算与 PM 协作进行时，我经常在这里取得最大的成功，因此我们都在同一页面上改进它们。

软件估算的问题在于，当第一次粗略估算被固定为记录计划而不是初稿时。当关键路径上的团队采用它但将对估算的调整视为工程问题时（相对于知情估算的第 1/n 步），这可能是一个问题。一旦项目获得批准，更好地弄清楚细节——这可能意味着基于对满足需求的内容的更深入理解，三个月的估计变成了两个（或四个）。

您几乎总是希望估算驱动您的日程安排，而不是尽可能让日程安排驱动估算。在我的团队中，虽然我们有时确实有不可改变的截止日期（例如会议），但如果估计超过这些日期（通常）很好 - 更改消息（例如“预览”），框架（“在不久的将来”）或踢球未来总是我们可以与领导层讨论的选择。我当然承认这并不总是微不足道的。当确实要安排时间表时，您可以将工作分解为必须具备的和最好具备的（并将它们移至未来的冲刺），然后检查必备项是否符合您的截止日期。

如果日程仍然太紧，您还可以提出其他问题，例如“我们可以为这个项目增加更多的工程师吗？” 以及“是否有大量的范围缩小仍然会使按时发货具有吸引力？”。

取消项目有时是正确的（如果不舒服的话）。

织最健康的长期决定。如果它在有机会启动之前被取消，则尤其如此，获得牵引力然后最终不得不弃用，因为不再能够维持其人员配置。如果人们想知道，是的，我读过Killed By Google。旨在尽可能减少导致项目被取消的情况。我最近取消了一个多年项目，它很粗糙。

这什么时候可以发生？您可以就某个时间点做出正确的新项目投资决策。在那个时间点，明星们很可能已经一致（市场契合、组织认可、人员配置承诺）以使其完全有意义。一年下来，事情可能会发生变化——市场、领导力、项目的重要性。定期检查您在项目开始时所做的假设是否在其整个生命周期中继续保持真实是至关重要的。

您对假设仍然正确的信心越强，项目成功启动并继续得到支持的机会就越大。由于多种原因，取消很难，尤其是有真实的人以真实的情感投资于构建他们希望推出的东西。作为领导者，引导人们从一个已取消的项目中退出到另一个成功启动的项目是复杂的，但对于让人们回到心理安全、信任和幸福的地方很重要。在客户方面，请注意用户信任以及您的长期决策如何影响这一点。

关于技术债务：一盎司的预防胜过一磅的治疗

Titus Winters 将技术债务定义为“我们今天拥有的代码和系统与我们希望拥有的代码和系统之间的差异”，其中某些类型的债务比其他类型的债务具有更大的影响。有些债务可能是由于没有及早发现的错误（疏忽）造成的，有些是由于事后学到的（后见之明）造成的，还有一些是由于技术系统的变化（背景）造成的。

我发现始终优先解决技术债务有时很困难，因为您不能总是量化未出现的错误或未发生的中断，因为您“偿还债务足够多”。保持团队对此类工作的兴趣并在绩效评估期间给予奖励也非常重要。然而，一旦问题随着时间的推移真正开始堆积，“治愈”的成本可能会高得多。与污染类似，在多年的过程中，预防技术债务是一种比稍后缓解的成本更低的策略。

你能做些什么来防止债务累积？除了构建新功能外，技术主管还应定期在冲刺中投入时间进行清理和偿还债务。审稿人应该意识到短期速度的推动实际上可能会导致进一步的问题。经理和董事应注意批准与现有项目重叠的新项目，除非您确定权衡取舍是值得的（例如，解决现有系统中的债务不值得与构建新项目相比）。在所有这些之上，对项目运行状况的监控非常重要。

如果没有休息和良好的工作/生活平衡，您或您的团队可能会精疲力竭。

职业倦怠是由于工作场所压力未得到成功管理而导致的一种疲惫。我看到许多工程师在大流行期间因工作压力而精疲力尽，但它一直存在于技术领域。这些天，我问我的下属，“你的压力水平如何？我能做些什么来帮助你？” 在每个 1:1。

我对倦怠的经验是它发生得很慢，最后以冷漠告终。您会慢慢开始感到精力不足、没有动力和精疲力尽，同时尽您所能应对工作压力。您质疑自己是否有问题，但没有意识到您的身体正在加班加点地工作以弥补您缺乏的能量。你不断地推动自己越来越努力，但最终感觉好像没有多少东西可以付出了。

大约 5 年前我感到精疲力尽，但我很高兴地说我扭转了局面。是什么导致了它？这是一大堆事情。多年来，我一直把工作放在首位，工作时间越来越长，而且说“不”的次数不够多。我从来没有足够的休息或假期。我平均每晚睡 5 个小时。当我在家时，我的精力非常低落，以至于我几乎没有像家人那样“在场”。“修复”是做与这些事情相反的事情：休息一下，多睡一会儿，从我工作的时间中榨取更多价值，更好地授权，并有一个明确的“停止时间”工作。

作为管理者，为了避免我们的报告过时，我认为尝试鼓励我们的团队利用他们的休假时间、休息一下并定期检查人们在压力方面是否真的做得很好是很重要的。

在大型组织中执行可能感觉很慢。有一些方法可以解决这个问题。

我与工程师进行了多次对话，归结为“为什么在（大型组织）中运送 X moon-shot 如此困难？”。Alex Komoroske 有一个很好的类比，将大型组织比作粘液霉菌。也就是说，由于协调障碍，即使是执行简单的事情也会开始感觉比您预期的要慢得多。组织具有复杂的系统、结构和动态，当必须协调项目的人数增加时，不利因素就会增加。

这里有很多因素在起作用，包括低估他人任务的难度（例如，如果他们正在建立依赖关系）。您不能忽视这些问题，因为它会使功能障碍扩散。克服这种不利因素的一种方法是尽可能地解耦事物，以便它们能够落在一个 OK 的时间线上，并最终汇聚到交付 X。

与其从一开始就解决所有 X，不如避免只为登月计划（巨大的风险努力）而努力，而是定义让您更接近目标的屋顶计划（释放价值的安全步骤）。如果这个问题听起来很熟悉，我强烈建议阅读 Alex 的套牌。

关注问题与项目

假设您的用户有未解决的需求（例如问题）。当您是特定项目的工程师时，通常会询问您的特定项目如何将解决这个问题（局部最大值）。在拥有类似形状项目的大型组织中，很可能会看到多个工程师试图以这种方式独立思考（“我的项目如何解决这个问题？”）。然而，当您拥有一个项目组合时，这可能不是很明确。如果用户可能同时使用您的许多项目怎么办？如果他们每个人都以略微不同的方式解决问题而不知道彼此的方法，那不是很奇怪吗？相反，您想问“这个问题的正确端到端解决方案是什么？” 然后回过头来看看哪个项目或对一系列项目的更改最能全面满足这一需求。这可能需要让从事多个相关项目的人们进行更深入的协作。然而，这可以带来更好的，

结论

“追求卓越，与最擅长的人一起工作”——布赖恩·史陶芬比尔 (Brian Staufenbiel)

与可以学习的人建立友谊和关系。对他们的指导、指导、他们的成功和失败持开放态度。永远不要害怕寻求帮助或见解。在很多情况下，这只是一个问题。

在每个阶段，请记住，必须随着时间的推移培养对给定组织的技术、业务领域和人力资源的掌握。一个组织不能从另一个人那里聘请大师，并期望他们从第一天起就富有成效。如果您是一名优秀的工程师，您将为组织的发展做出贡献。作为回报，您将获得新的途径，让您获得新技能并成长。

感谢 Leena Sohoni、Joshua Cruz、Kara Erickson、Jeff Posnick、Houssein Djirdeh 和 Sriram Krishnan 的友好反馈和贡献。