成为一名 +10% 的工程师

那么 10x 工程师怎么样？

1.1 工程师

我如何让其他人更有效率？

好的，但我想编写代码

太棒了，但我还有一些功能需要发布

开始之前，我正在开发https://cloudash.dev，这是一种监控无服务器应用的全新方式🚀。如果你在调试生产事件时厌倦了在 50 个 CloudWatch 选项卡之间切换，可以看看这个。

好吧，我知道你可能在想什么。

等等，我以为我们已经不再讨论 10 倍工程师了？现在赶上这个潮流是不是有点太晚了？

嗯，也许吧——这就是为什么我想谈谈那些对团队更有价值的人[需要引文]

那么 10x 工程师怎么样？

如果你和我一样，你可能会看到一篇关于 10 倍工程师（甚至100 倍——去读读这篇文章，它比这篇文章更好）的文章。这篇文章的核心思想是，有些人比其他软件工程师优秀十倍。

他们编写代码的速度是其他人的十倍，他们的代码中的错误少了十倍，他们的代码比其他人的代码快十倍（当然，假设使用相同的语言），并且他们的初创公司恰好有十个用户（好吧，不包括最后一个）。

那么...如果我的公司有 100 名工程师，我们能否只聘请 10 名非常优秀的工程师，支付他们三倍的薪水并节省70% 的工资？

当然！

假设你需要编写的软件不需要协作、不需要规划、不需要估算、不需要沟通，而且从第一天起所有东西都记录得非常完整。这种情况（据我所知）从未发生过。如果他们的工作只是敲键盘，那么显然，那些能以10倍的速度完成这项工作的人，他们的水平也会高10倍。但这并不是软件工程的意义所在。

（注意：有些软件工程师确实比其他软件工程师更优秀、更快、更熟练、更擅长交付可靠的软件。）

这并不意味着你可以雇佣几个天才（天才二？）来完成几百人的工作。“10倍工程师”指的是一个人独自坐在角落里，每周戴着耳机工作40小时，并且写出非常出色的代码。你或许就是这样的人（没关系！），但我想谈谈另一种在组织中产生巨大影响的方法，而无需（不知何故）以比别人快10倍的速度编写代码。

1.1 工程师

（或者 +10% 工程师，随你便）

+10% 的工程师是那些让同行进步 10% 的工程师。

他们并非比团队里的其他工程师更优秀，而是因为他们，他们的团队比其他团队更优秀。道理在于，如果你能提升身边人的效率，很快就会产生巨大的影响。

让我给你举个例子。

想象一下，如果你刚加入一家公司，就不得不经历一段令人望而生畏的入职流程。没有任何记录，你花了4天时间才成功访问JIRA，项目也才勉强搭建完成，总而言之，你过得并不愉快。我曾在几家公司工作过，我可以向你保证，入职过程至少可以说是坎坷的。

一旦设置好环境，就可以开始编码。

或者 - 您可能决定记录整个过程：

• 创建详细、友好的 README 文件。
• 撰写一份详细说明公司术语的文件（亲爱的 C 级经理，我知道每个人都知道您是谁，但作为贵公司的新员工，我怎么知道谁是“吉姆”）。
• 设置提醒，以便 IT 支持人员在每个月初为新雇主创建 JIRA 帐户。
• 安排一封欢迎电子邮件给新雇主，与他们分享最重要的链接

那天没有写一行代码。

但你的改变带来的影响是惊人的。之后加入公司的每个人都会获得更好的体验，他们从一开始就会更有效率（甚至第一天就提交代码！），而且你的公司还能省下之前浪费在人才等待 Github 访问权限上的钱。

这就是“+10% 工程师”的意义所在。数字不会说谎。这听起来可能有点傻，但如果你能让 25 个人的生产力提高 10%，那么你的影响力（根据 JavaScript 的计算能力，它的数学能力非常强）远大于这个神话般的 10 倍。

我们可以进一步说，如果我们谈论的是 50 个人呢？

天哪！说不定你能得到 100 倍的奖励？！

我如何让其他人更有效率？

文档只是一个例子。促进组织内部的知识共享是另一个想法。这可以通过线上或线下的方式进行（“线下”在2019年的含义是“非实时”）。

写一篇关于你最近学到的、让你更有效率的东西的文章，与你的团队分享，你已经产生了影响。

在你的团队/组织里组织一次知识分享会。你可以组织一场内容丰富的活动，提供小吃、饮料和8场演讲，这当然很酷，但你没时间安排所有这些。但并非所有活动都完美无缺。你可以预订一个房间，问问大家有什么想分享的（如果你鼓励他们，你会惊讶地发现有很多人愿意做演讲），然后尽情享受吧！

我并不是说你（尤其是我自己）是需要被鼓励与他人分享神圣知识的智者。也许你知道团队中有人对你（或许还有其他人）正在努力解决的问题有着丰富的经验。如果你请他们来教你——他们作为老师会进步，而你作为工程师也会进步。

但是，如果你要求他们公开分享（或者，你可以公开学习 - 分享你所学到的东西） - 影响会更大。

不久前，我有个……挺有意思的想法：不是每个人都有能力/愿意去参加会议（或者下班后看YouTube视频），所以，不如我们把会议演讲嘉宾请过来？在OLX集团，我们开始组织一个“会议演讲影院”（Conf Talk Cinema），大家聚在一起，一起在YouTube上看一两场演讲。

你也可以这样做，分享你在印度看到的这个精彩演讲的链接，其他人也必须看到它，但转化率真的很低，而要求某人与他们的团队成员在电影院（好吧，会议室）放松 30 分钟则成功率要大得多。

好的，但我想编写代码

当然！这是你的工作！

当你这样做的时候，也许重构这个自 1928 年以来没人触及过的部分，而你可能是唯一一个真正理解它的人？

这不是什么高深的学问，但意义深远。重构这个庞大的类/函数，不仅能让你更好地理解代码库，还能提高其他人的工作效率，因为他们不用费力去理解这段代码。

如果 100 位开发人员需要花费 15 分钟来理解某个功能，而你却能将这个时间缩短到 1 分钟……我甚至不用编写任何代码就能直观地看到这一点——这显然能节省其他人多少时间和精力。不仅如此，他们接触这部分代码时也会更加安心，因为他们真正理解了其中的原理。

说到感觉更安全：

如果你在某个冲刺中的能力比其他冲刺更强，或许可以编写一些额外的测试？或者用自动化测试覆盖更多代码？或许一开始就应该设置自动化测试？

我对自动化测试有点偏见，但我不在乎。我是cypress.io的忠实粉丝，我强烈认为采用更多测试可以提高效率。

如果通过花费 4 个小时对系统中这个棘手的部分进行单元测试，您可以为那些因为错误而必须回滚生产部署的人节省 X 个小时 - 这难道不值得吗？

用自动化测试覆盖系统的关键流程，可以让你（以及其他人！）在未来进行重大变更时，将破坏主要功能的风险降至最低。未来的你（以及你的团队，希望如此）会为此感谢你。

太棒了，但我还有一些功能需要发布

别担心，我也是同样的情况。

找时间去做这些事（以及其他事，这绝不是一份完整的清单）可能很难。很难，但绝对值得。

这完全取决于优先级，以及弄清楚什么才是最重要的。是某个每小时能交付3个功能的天才开发者的生产力？还是整个团队的生产力和可靠性？又或者两者兼而有之？没有灵丹妙药，但或许可以找到一个折衷方案。

话虽如此，我坚信以下说法是正确的：

团队生产力>个人生产力

你怎么认为？