在工作中“无所事事”Doing nothing at work

许多工程师应该减少工作量。我并不是说要少写代码或少提交改动，而是指每天实际工作的时间应该更短。即使在工作时，也应该放慢节奏。我喜欢将默认的工作饱和度目标定为 80%：除非正在推进压力较大的项目，否则我会把每天 20% 的工作时间用来远离电脑。

高影响力的机会

为什么？科技公司的绩效表现往往是由极少数的极端事件决定的。回想我做过的最具影响力的那些改动，其中许多涉及的工作量其实少得惊人。在软件开发中，单纯的努力并不会得分。真正重要的是在对的时间解决对的问题。

在大型工程组织中，通常会有一些微不足道的开发工作，只要你去做，就能为公司带来数千万甚至数亿美元的收入。以下是三个常见的例子：

首先，当公司试图签下一笔大型企业订单时，及时介入并提供一个新功能或修复一个缺陷就能促成交易。这甚至不需要是一个多么出色的功能：有时候，仅仅向对方展示你愿意并且能够做出具体的修改，这就足够了。

其次，及早预防或减轻故障影响（哪怕仅仅是知道该关闭哪个功能开关），可以挽回巨额资金：这既包括故障期间产生的直接收入损失，也包括因客户流失或拒绝签署待签合同而导致的未来收入损失。

第三，当公司试图发布一项备受瞩目的功能时，其成败往往取决于一些微不足道却又冷门的改动（例如：能否在用户设置中快速添加一个新字段，或者能否更新那个多年没人碰过的破旧企业数据导出功能）。对系统的熟悉程度，决定了完成这些改动是只需几个小时，还是耗费整整一周。

这些例子有什么共同之处？它们都极具时效性。你不可能在早上刚登入系统时，就随心所欲地决定去促成一笔大单、缓解一次故障，或是加速推进一个重磅功能。难道仅仅是因为在合适的时间出现在了合适的地点吗？不尽然。你还得确保自己当时没有在忙其他事情。

保持松弛感

几年前我曾在《疯狂搞定 JIRA 工单只是个雕虫小技，而非产生影响力的途径》一文中探讨过这个问题。如果你总是 100% 忙于处理源源不断的低优先级工作（比如，只是不断地从待办列表中拣选工单，解决它们，然后再接着拣选下一个），你就会在两个方面错失从事高影响力工作的机会。

首先，你会忙得连机会都注意不到。你不会去和负责其他工作的人交流，不会去阅读团队动态，也不会去关注正在发生的故障。这样一来，你就会错失参与高影响力工作的最佳途径，那就是主动提供你的专业能力。

其次，如果你总是显得很忙，你的经理就不会主动把机会分配给你。这是参与高影响力工作的次优途径：让你的经理或产品经理说出“哦，Sean 现在有空帮忙，我来圈一下他”。为什么说这个途径更好？因为经理和产品经理通常更清楚目前有哪些高影响力工作正在进行。他们参加了那些你不在场的会议。

无所事事

如果你应该为高影响力工作留出空闲时间，又不能只是机械地刷工单，那么你一分一秒地度过日常工作时到底该干些什么？难道就干坐着什么都不做吗？没错！

实际上，什么都不做挺好的。软件工程可能是一份压力很大的工作，但通常这种压力并非持续不断：压力往往来自偶尔的突发事件、高强度的紧急任务，或者（如今很常见的）裁员潮。如果你在处理工作中压力相对较小的部分时，也保持着应对紧急状态般的高强度，那么等到真正需要处理高压任务时，你恐怕早就精疲力竭、焦头烂额了。

即便是在工作的高压环节，什么都不做依然有好处。对于刚接手 On-Call 值班的工程师，我的一个建议就是不要慌张：在接入电话会议或开口说话前先深呼吸几次，总体上尽量保持“慢动作思考”。大多数突发事件都会自行平息。而在事件发生期间，大多数那种抱着“也许这招管用”的心态做出的慌乱修改，往往只会让情况变得更糟。通常来说，只要你能保持镇定不恐慌，你的应急响应表现就已经超过大多数工程师了。

「无所事事」其实为各种可能性的发生留出了空间。如果你给大脑喘息的机会，你会发现自己更容易产生新的灵感。如果有人交给你一项重要任务，你可以全神贯注地应对它（而不是一边在后台同时处理另外三件事）。当你不忙的时候，你才有时间去观察周围的事物并吸收新的信息。

刻意不去做某些特定的事情

看到有任务需要处理却袖手旁观，很多工程师会觉得浑身难受。我也是如此。我曾在《我沉迷于“做个有用的人”》一文中写过这一点：这是许多软件工程师共有的心理特质，因为具备这种特质（在某种程度上）会让你非常胜任这份工作。为了能腾出时间来“什么都不做”，有时候你需要强迫自己不要主动往里跳。

举个例子，我认为工程师通常应该避免做“胶水工作”（glue work）。大多数胶水工作——比如确保不同人员之间保持沟通、为你不负责的项目更新文档、主动请缨去清理技术债——都反映出组织并没有真正把这项工作摆在明面上的优先位置。如果他们重视了，根本轮不到你来主动请缨。这要么无伤大雅，要么就是公司犯下的一个大错。如果无伤大雅，那你就不该挺身而出去做这些事：这只会浪费你的时间，还会让你的经理感到厌烦。如果是公司犯下的大错，你同样不该去做，因为这等于是以牺牲自己的职业发展和心理健康为代价，来帮公司屏蔽掉其自身错误所带来的后果。

这对你来说极其吃亏，对你的初级同事来说也是个坏榜样，而且当你不可避免地陷入职业倦怠时，这还会立下一个坏规矩，让其他人不得不跳进同一个坑里重蹈覆辙。如果后果真的极其严重，那就让它发生吧，只有让组织切实感到痛了，他们才会去改变政策。

我也认为，过于乐于助人会让你容易成为被别有用心者利用的目标。科技公司里到处都是想从软件工程师身上榨取无偿劳动的人。这与通过正常渠道分配并带来晋升、奖金（以及正常薪水）回报的工作不同。我指的是那些通过私下渠道找上门的工作，提出要求的人既没有能力也不愿意确保这些工作被正式记录在你的名下。例如，另一个部门的产品经理发消息对你说：“你太擅长查询数据了，能不能帮我拉取一些关于 X 的统计数据？”或者另一个团队的工程师找你“结对”完成一项工作，但最终结果是你写了所有的代码，而他们却悄悄地以自己的名义提交了更改。

做一点这种工作是可以的。能帮的时候你也可以帮。但你需要能够施加反向压力，无论是直接拒绝，还是仅仅把回复推迟几个小时或几天。

避免在很可能会凭空消失的工作上投入过多精力也是个好主意。例如，假设你正在与一位产品设计师合作，而对方还在实时摸索他们到底想要什么。上午 9 点，他们发消息说希望页面头部呈现出某种样式；到了 10 点，他们又提出了一些调整；11 点又有了更多的改动，以此类推。你不应该每小时都投入精力去完全重写这个页面。相反，你应该什么都不做（比如去散个步），然后根据最新的设计在下午一次性重写完页面。另一种常见的情况是“来自某位经理的宏大构想，但该经理缺乏将其贯彻到底的政治影响力”。通常，你只需要熬时间，直到这个项目不可避免地被取消即可。

结论

许多软件工程领域的建议和工具都是围绕扩大你输出技术精力的能力而设计的：同时做更多的事情，承担范围更大的项目，或者仅仅是写更多的代码。但软件工程的成功并不取决于这些。它取决于在正确的时间做正确的事情的能力，这就要求你在日常工作中刻意保留一部分精力。

根据我的经验，只付出 80% 的精力依然有可能成为一名“高绩效工程师”。事实上，这样反而更容易，因为你不那么容易因为压力而犯低级错误，而且你能处于一种更好的状态去迅速抓住那些能带来超额回报的高影响力任务。

这并不意味着你永远不应该 100% 地拼尽全力。我想我每年大概有两三次会尽可能努力地工作：漫长的工作时间、高度集中的注意力，从醒来到入睡都在思考问题。但我会把这种工作模式保留在回报非常高的时候。在一年中的其余时间，我过得相对轻松。

如果你喜欢这篇文章，可以考虑订阅邮件以获取我的文章更新，或者将它分享到 Hacker News。

这里是一篇相关文章的预览，它与本文共享相同的标签。

“习惯拒绝”的工程师是 ZIRP（零利率时期）的产物。那个总是习惯说“不”的工程师，是高级（Senior）和主管（Staff）工程师群体中真实存在的一个典型形象。他们的作用是放慢节奏，阻止那些会增加复杂性的功能开发，并确保尽可能少写代码（因为代码本身就是一种负债）。我们可以将其视为“习惯拒绝”的工程师，与“习惯接受”的工程师相对。“习惯接受”的工程师痴迷于快速推进，默认批准代码变更，认为 MTTR（平均恢复时间）比 MTBF（平均故障间隔时间）更重要，并且倾向于交付大量代码。“习惯拒绝”的工程师则痴迷于质量，乐于稳步慢走，并且默认拦截代码变更。大多数工程师则处于这两极之间的某个位置。当我说“习惯拒绝”的工程师时，我指的是那些与该典型形象产生最强烈共鸣的工程师群体。继续阅读...