我和密友常讨论的一个话题是：我们生产力的瓶颈在哪里，以及如何能更快地执行。这与我在更广泛的社交圈中看到的截然不同——在那里，人们常说速度并不重要。在网上讨论中，我经常看到有人更进一步，给这件事赋予道德色彩，声称试图提高速度、变得更高效或努力工作实际上是不好的（更多例子见附录）。

我看到的认为生产力不重要（或实际上有害）的主要原因可分为三类：

  • 做正确的事比快速做事更重要
  • 在X方面的速度不重要，因为你花在X上的时间并不多
  • 思考生产力是坏事，你应该“享受生活”

我当然同意做正确的事很重要，但提高速度并不会阻止你做正确的事。事实上，这两者互为放大器。如果你擅长选择正确的问题，那么强大的执行能力会更有影响力，反之亦然。

确实，选择正确问题带来的收益可能大于改进战术执行带来的收益，因为前者可能带来无限收益。但改进战术执行要容易得多，而且这样做也有助于选择正确的问题——因为更快的执行能让你更快地实验，从而帮助你找到正确的问题。

一个具体的例子是我参与的一个项目，旨在量化整个机器集群的健康状况。该项目发现了一系列严重问题（相当一部分主机正在主动破坏数据，或存在性能问题，导致尾部延迟增加超过两个数量级，或两者兼有）。这被认为严重到需要成立一个新团队来处理。

回顾起来，我最初量化问题的尝试注定失败，根本行不通（至少无法在合理时间内完成）。我花了数周时间尝试各种行不通的想法，而最终能在“仅仅”数周后找到可行方案的关键，在于能够快速尝试并摒弃无效的想法。在之前的一篇文章中，我曾描述过这一过程中极小一部分所花费的时间，结果多位网友在评论中表示这快得不可能。

我觉得这有点好笑，因为我天生就不是一个编程快手。学习编程对我来说真的很艰难，在很长一段时间里我都学得很慢（而且在我没有练习的方面，现在依然如此）。我的“独门诀窍”是，我特意去加快那些我经常做的事情，而大多数人并没有这么做。我把这种情况类比为运动员在真正开始训练之前的时代。很长一段时间里，许多运动员并不认真训练，而一旦人们开始尝试训练，按照现代标准来看，这些训练往往也是误导性的。例如，如果你读一下70年代关于棒球的评论，你会看到有人说棒球运动员不应该进行力量训练，因为那会让他们“肌肉僵硬”（很多人认为举重会导致“过多”的肌肉块，让人速度变慢、爆发力减弱、灵活性降低）。但如今，运动员通过使用增强肌肉块程度的兴奋剂获得了巨大优势，这意味着仅靠力量训练，运动员根本不可能变得“肌肉僵硬”到那种程度。与上述讨论类似的一种说法是，运动员不应该担心力量/体能，而应该提升技巧，但力量会提升技巧的回报，反之亦然。

回到编程这件事上，如果你刻意练习和训练，而几乎没有人这样做，那么即使像我一样没有编程天赋、一开始就非常挣扎，你也能比大多数人更快地完成事情。当然，总会有更有天赋的人，他们花更少的时间提升就能执行得更快。但幸运的是，对我来说，认真尝试提升的人相对较少，所以我还能做得不错。

尽管如此，以某些网络评论者认为不可能的速度运作，我还是花了数周时间在死胡同里摸索，才找到可行方案。若按常人眼中的正常速度推进，恐怕要花足够长的时间才能找到可行解——而在这期间，我可能投入一两个季度后就会放弃这个问题。那些看似合理的死胡同数量，或许正是这个问题多年来虽为关键痛点却始终悬而未决的原因。当然，比我更擅长构思的人或许能绕过这些死胡同直接解决问题，但正如我们之前讨论的，在“执行速度”上摘取低垂果实相对容易，而“拥有更优创意”的低垂果实却难觅踪迹。不过，通过快速试错与淘汰想法，可以在有限程度上模拟出比我更擅长构思的人的状态（我也在提升构思能力，但优先攻克那些高回报的易得成果同样合理）。快速试错还能加速提升构思能力——因为建立直觉的关键正是通过反馈验证哪些方法有效。

下一个主要反对意见是：特定任务的速度无关紧要，因为花在该任务上的时间有限。从宏观层面看，我不同意这种观点——即便对某类任务而言确实如此，解决方案也应是改进每类任务，而非全盘否定改进本身。有人会提出子反对意见：“但我每周要花20小时在低效会议上，其他时间做什么都无所谓。“我认为这错得双重离谱：即便只剩20小时潜在高效时间，这段时间的生产力乘数仍会作用于整体效率。况且，退出注定徒劳的会议、提升尚有价值的会议效率，通常都是可行的1。

更普遍而言，当人们说优化X无济于事是因为他们不花时间在X上、且X并非瓶颈时，这与我的经验相悖——我发现自己在那些常被轻视的X上，往往耗费大量时间且深受其困。部分原因在于：提升X的速度反而可能通过良性循环的反馈机制，增加实际投入X的时间。另一部分原因，正如Fabian Giesen的评论所揭示：

人们普遍接受一个近乎陈词滥调的观点：除非你真正对程序进行性能分析，否则你根本不知道程序的时间消耗在哪里。但它的推论——除非你实际测量，否则你也不知道自己的时间花在哪里——却远未得到同样的认可。

当我对比人们实际的时间分配与自认为的时间分配时，发现两者存在巨大偏差。我认为这有一个根本原因：除非进行测量，否则人们对自身时间分配的估算往往严重失准。这一点被法比安·吉森的另一段引述精妙概括——这段话恰好关于解魔方，但同样适用于其他认知任务：

套用一位知名魔方玩家的话：“当你自己解魔方时，永远感觉不到停顿有多糟糕，因为你的大脑在忙碌，你知道自己在思考什么。但一旦有了录像，需要改进的地方就会变得显而易见。“这几乎就是编程领域”别靠猜测，要用性能分析“的经典建议，只不过应用到了你全程专注忙碌的场景——而编程圈子的默认假设似乎是：只要你在真正工作而非分心偷懒，就不可能浪费大量时间。

与网上大多数讨论这个话题的人不同，我确实追踪过自己的时间去向。结果发现大量时间花在了那些被奉为“不值得优化”的典型例子上——因为人们声称自己不会在这些事情上花太多时间。

其中一个最常被引用的“不该优化的反面教材”就是打字速度（讨论时人们常说打字速度不重要，因为思考时间远多于打字时间）。但当我审视自己的时间去向时，大量时间确实花在了打字上。

举个具体的例子，我在目前的工作中写了不少有影响力的文档。当别人问起某份文档花了多久时，他们通常惊讶地发现只花了一天时间。就像机器健康那个例子一样，速度能帮人判断哪些文档会产生影响力。回顾我写过的文档，大概只有15%真正产生了巨大影响（比如催生新团队、改变现有团队方向、显著影响公司利润等）。部分原因是我并不总能预判哪些想法能引起共鸣，但更关键的是，我经常提出一些看似离谱的想法——因为这些想法听起来太蠢，没人会当真（比如，针对容量瓶颈，我提出的一个解决方案是：在每个机架上关掉10%的服务器，从而提高有效配置容量——这大概是你能想到的最蠢的主意了）。如果我写文档的速度慢得多，提出这种真正离谱的想法就不划算了。按现在的情况，如果我觉得某个想法有5%的成功概率，那么预期需要花大约20天写文档，才能让其中一个落地。

我大约一半的写作时间花在打字上。如果我的打字速度是某些人所说的中位数（40词/分钟），而不是某个随机打字测试测出的110词/分钟，那么速度会慢0.5 + 0.5 × 110/40 = 1.875倍，这意味着需要将近40天才能让一个冒险的文档落地，这会让这件事变得不太靠谱。如果我没有优化写作流程中非打字的部分，我估计整体速度可能会慢10倍2，那么每个高影响力的冒险文档就需要大约200天，这足以让我根本不会去写这种文档3。

更广泛地说，Fabian Giesen曾指出，这种速度带来的非线性影响其实很常见：

当你跨越某些阈值时，会经历“相变”（具体细节在一定程度上取决于问题），你的整个工作方式都会改变。……理论上我可以在任何速度下做很多事情，但实际上却做不到，因为随着迭代时间的增加，首先会变得令人沮丧到无法长期坚持，最终耗时之长甚至会让它从我的短期记忆中消失，所以我必须记笔记或以其他方式组织信息，否则根本无法完成。

当然，如果我能通过交互式界面拖拽滑块进行实验，并在不到一秒内看到结果，那就会非常“无过滤”——想尝试什么就直接去做。

一旦迭代时间进入几秒级别（比如静态编译语言的编译-链接周期），你就不会再随意尝试了，还会花时间思考这次运行是否能有收获，因为耗时足够长，你宁愿不浪费一次运行机会。

当迭代时间达到几分钟或几小时级别时，就需要大量规划来避免浪费运行机会，同时还要进行上下文切换（等待期间做其他事情），以及做笔记/记账；在这个级别，错误既代价更高（因为浪费一次运行会浪费更多时间），也更常见（因为注意力如此分散）。

当规模进一步扩大，你可能需要为一段可观的时间占用大量资源，并且需要获得批准和预算，这本身就需要开会等流程。

我工作中一个从一类问题转变为另一类的具体例子是这个关于指标分析的项目。当时有多个解决该问题的方案。大家一致认为这个问题很重要，没有异议，但这些方案都属于需要分配一个团队通过多个路线图周期才能完成的事情。启动如此昂贵的项目需要大量组织层面的支持，以至于许多重要问题（包括这个）都无法解决。但事实证明，如果范围界定得当且执行合理，这个项目实际上是一个程序员可以在一天内创建出MVP（最小可行产品）的事情，这完全不需要组织层面的支持就能启动。你不再需要让多个总监和副总裁同意这是组织最重要的问题之一，只需要一个认为这个问题值得解决的人。

回到那些人们说速度不重要、因为他们不花太多时间在X上的例子，另一个我经常看到的是编程，而编程速度不重要也并非我的个人体验。以上面讨论的机器健康案例为例，在我找到可行的方案后，我花了整整一个月几乎只做这件事：编码、测试和调试。那个月我大概只有6小时的会议，除此之外，除了吃饭等时间，我就是去上班、整天编码、然后回家。我认为比较不同人的编程速度要困难得多，因为很少看到人们做相同或非常相似的非琐碎任务，所以我不会试图与他人比较。但如果对比我在提升效率之前和现在的生产力，如果没有通过关注速度找到的加速方法，这个项目可能根本无法完成。

基于阿姆达尔定律的论点在寻找固定基准（如SPECint的子任务）的加速时可能合理，但当你面对一个系统——提升某项任务的能力会增加该任务的回报，并可能增加花在该任务上的时间——那么说“你不应该因为花了很多时间做某事就去改进它”就不合理了。我会花时间在高回报的事情上，但这些事情之所以高回报，通常是因为我花时间提升了速度，从而降低了回报中的“投入”。

我看到的最后一个反对提升速度的主要论点，是将思考生产力和提升速度本身赋予负面道德权重。这类评论往往将各种休闲活动（如与朋友和家人共度时光）赋予正面道德权重。我认为这种论点本末倒置。如果有人觉得与朋友和家人共度时光很重要，一个简单的方法就是提高工作效率，减少工作时间。

就我个人而言，我刻意避免长时间工作，而且我怀疑我的工作时间不超过公司中位数员工——这是一家我认为工作与生活平衡整体不错的公司。我的许多生产力提升都用于休闲而非工作。此外，刻意提升速度让我相对较快地获得了晋升4，这意味着我比没有晋升时赚得更多，这给了我更多自由去花时间在我看重的事情上。

对于那些并非主张“不应考虑生产力，因为更应关注休闲”，而是认为“根本不该考虑生产力，因为它不自然，人应过自然生活”的人，这最终归结为个人偏好。但对我来说，我太珍视工作之外所做的事情，以至于无法不在工作中明确地提升生产力。

正如这篇关于衡量原因的文章所述，虽然本文讨论的是提升生产力的实际原因，但我个人致力于提升自身生产力的主要原因并非出于实用。主要原因是我享受不断进步的过程——无论是某个小众的桌游、一项我毫无天赋且永远不会有实际价值的运动，还是工作。对我而言，次要原因是，鉴于生命有限，我希望将时间分配给我所珍视的事物，而提升生产力能让我做更多这样的事。但直到二十岁左右，我才产生这个想法，而那时，我已经在很多投入大量时间的事情上努力提升多年了。

另一个常见的工作动力是，精通或擅长某事对许多人来说似乎令人满足。这并非我个人共鸣的点，但当我询问他人为何致力于提升技能时，这似乎是一种常见的动机。

一个相关的观点——Holden Karnofsky 一直在谈论——是，如果你希望以某种方式改变世界，那么即使在工作岗位上，提升技能也很有用，即便这些技能对当前工作并不明显有用。因为当你转向更符合自己目标的事情时，这些技能会为你提供更大的杠杆作用。

附录：思考改进方向的一种方式

以下是我喜欢的一个来自 Gary Bernhardt 的框架（除了本句外，整个部分均为他的内容，未用引用块标注）。

人们在谈论效率时，往往只关注单一的分析粒度。例如，“思考是最重要的部分，所以不必担心打字速度”。如果我们退一步看，对此的回应是：“效率存在于从年度战略到毫秒级按键的整个连续谱系中。”我认为可以合理假设，更大尺度上的改进会产生最大的影响。但随着粒度变细，回报率在何处下降并不明显。以下是一些从粗到细的例子：

  1. 你一开始提出的宏观观点是：编程不仅仅是思考，而是思考加上编辑代码这类战术活动。编辑速度越快，留给思考的时间就越多。
  2. 但编辑代码的成本远不止打字所花的时间！编程高度依赖短期记忆。每次停下来编辑都是一次干扰，你可能会忘记正在处理的细节。编辑速度慢实际上会削弱你的短期记忆，从而降低效率。
  3. 然而，编辑代码不仅仅是敲击键盘！它还包括敲击键盘所触发的编辑器命令。即使你的打字速度（WPM）和以前一样，一个更高效的编辑器也能显著提升实际的代码编辑速度。
  4. 但每个编辑器命令并非孤立存在！完成同一项编辑任务往往有多种方法。Vim 新手可能会输入“hhhhxxxxxxxx”，而更高效的做法是“bdw”。高级 Vim 用户可能会使用“bdw”，却没有意识到它比“diw”更慢，尽管两者按键次数相同。（在 QWERTY 键盘布局中，前者完全由左手操作，而后者是左右手交替。以 140 WPM 的速度打字，你每秒大约敲击 14 次按键，每个手指只有 70 毫秒来定位并按下按键。交替双手操作能让下一个手指有更多时间准备，而前一个手指还在按键过程中。）

在思考这个问题时，我们必须决定深入的程度。我认为，思考第 1-3 点有明显的投资回报率，并且让这些思考指导工具的选择和实践。我不认为第 4 点值得投入大量精力。我们似乎会自然而然地在那里找到“足够好”的平衡点。但这也可以作为一个很好的界标，来框定其他几点。

附录：更多示例

等等。

以下是一些积极利用生产力来“资助”自己珍视事物的人的例子：安迪·凯利（Zig）、杰米·布兰登（多个项目）、安迪·马图沙克（助记媒介、多个项目）、索尔·普旺森（VisiData）、安迪·朱（Oil Shell）。我举的是编程领域的例子，但你也能找到很多其他领域的，比如尼克·阿德尼特（Darkside Canoes），当然还有无数退休后去追求完全不像是工作的兴趣的人。

附录：避免高效的另一个理由

在我所在的各大科技公司社交圈中，一个越来越流行的观点是，人应该避免工作，并尽可能多地浪费时间，这通常被称为“反工作”，它似乎是“拼命努力”变成贬义词后的自然延伸。给出的理由通常是，工作主要让雇主的上级管理层和/或股东受益，而这些人通常比你更富有。

我理解这个论点，也同意上级管理层和股东攫取了工作中的大部分价值。但尽管我同情这种故意低效以“反抗体制”的想法，我更看重把时间花在自己真正想做的事情上，所以我宁愿快速完成工作，以便去做比工作更让我享受的事情。此外，过去的高效工作为我带来了不错的工作选择，因此我从事的工作比那些拥抱“反工作”运动的科技界熟人要享受得多。

你对环境的掌控越少，就越应该拥抱“反工作”。各大科技公司的程序员相对而言对自己的环境有较多掌控，这就是为什么尽管我同情“反工作”事业，但我并不奉行它。

虽然话题不同，但普拉奇·阿瓦斯提关于在获得终身教职前避免有争议的工作和避免推动必要变革会养成难以打破的习惯的评论与此相关。如果一个人想永远“反工作”，那没问题，但如果想在某个时候推动一些改变，那么在大型科技公司工作时养成“反工作”的习惯，会培养出适得其反的行为模式。

感谢法比安·吉森、加里·伯恩哈特、本·库恩、大卫·特纳、马雷克·马伊科夫斯基、安雅·博斯科维奇、亚伦·莱文、曾立凡、贾斯汀·布兰克、希思·博德斯、陶L.、尼哈尔·帕特尔、@chozu@fedi.absturztau.be、亚历克斯·阿兰和杰米·布兰登的评论/更正/讨论。

  1. 当我观察会议的生产力时，有些人非常擅长让会议保持正轨并富有成效。例如，我曾与一位名叫 Bonnie Eisenman 的人一起开会，她特别擅长确保会议高效。在我目前工作的早期，我问她如何如此有效地保持会议的生产力，并从那以后一直使用她的建议（我远不如她擅长，但即便如此，在这方面有所改进对我来说是一个显著的收获）。[返回]
  2. 10倍听起来可能是一个难以置信的写作速度提升，但在一个私人 Slack 上关于写作速度的讨论中，一位知名通讯作者提到，他们写一篇 5000 字通讯的净速度略低于每分钟 2 个单词（WPM）。我的净速度（包括编辑等时间）每份文档超过 20 WPM。

以测得的 110 WPM 打字速度来看，这听起来可能像是我只花了一小部分时间在打字上，但实际上大约占了一半时间。如果我看我的写作速度，它比我的打字测试速度慢得多，似乎大约是后者的一半。如果我看实际时间花在哪里，大约一半用于打字，一半用于思考，这两者几乎是串行的，这导致了我打字时的长时间停顿。

如果我看这里最大的收益可能来自哪里，那就是并行思考和打字，我会通过练习更多打字（而不是更少）来实现这一点。但即使无法做到这一点，并且打字速度高于平均水平，我仍然有一半时间在打字！

我的净速度远低于我写作速度的原因是，我进行了多次修改和重写。重写时花了一些时间阅读，但我阅读的速度远快于写作，所以那只是很小一部分时间。原则上，我可以采用一种减少重写的方法，但我尝试了一些可能达到这一目标的方法，但还没有找到适合我的（也许将来会有？）。

虽然这里的例子是关于工作的，但这同样适用于我的个人博客，我的速度在那里也类似。如果我写作速度慢十倍，我想我不会有多少博客内容。我猜我可能会写几篇文章，甚至可能写几篇草稿，但不会达到发布然后停止的地步。

我喜欢写作，并从中以多种方式获得很多价值，但我足够重视生活中的其他事情，以至于如果我的净写作速度是每分钟 2 个单词，我认为写作不会在我的生活中占有一席之地。

[return] 3. 另一种策略是撰写更短的文档。有些文档风格确实适合短篇幅，但我经常利用自己的写作速度来讨论那些若不借助长文档就很难令人信服的问题。

我的文档之所以长，一个原因是我经常处理涉及技术栈多个层级的问题。这意味着我不仅要展示来自多个层级的数据，还要为那些不熟悉某个层级的读者提供足够的背景信息，解释为何该层级的问题会向上或向下影响其他层级。这很有必要，因为很少有读者能对所有相关层级都了如指掌。

在多数情况下，之前曾有人尝试推动或资助解决这类问题，但未能获得支持，原因在于没有将某个层级的问题与其他层级的重要问题联系起来。我本可以避开这种跨越多层级的问题，但出于技术和组织层面的原因，这类问题中存在大量“低垂的果实”。因此，我认为仅仅因为需要花一天时间撰写文档来解释问题就忽略它们并不明智（当然，如果花十天时间，尤其是在人们对解决方案持怀疑态度的情况下，或许另当别论）。

[return] 4. 当然，晋升机制非常不公平，更高的生产力并不能保证晋升。如果只看与职级相关的因素，我甚至不确定生产力与职级的关联度是否比身高更强，但在可控因素中，生产力是最容易改变的因素之一。[return]