工作时无所事事

# 上班时无所事事 来源：https://www.seangoedecke.com/doing-nothing-at-work/ 很多工程师应该少干点活。我不是说少产出代码或改动，而是实实在在地每天少工作几个小时。干活时，也应该放慢节奏。我通常喜欢把利用率控制在80%：除非手头有高压项目，否则我会把20%的工作日时间花在离开电脑上。 ### 高影响力的机会 为什么？**科技公司的绩效取决于异常事件**。回想我那些最有影响力的改动，很多都只涉及少得惊人的工作量。软件开发中，努力本身并不加分。重要的是在正确的时间解决正确的问题。 在大型工程组织中，通常存在一些微不足道的工程任务，做好了就能为公司带来数千万甚至数亿美元的收益。这里有三个常见的例子： 第一，当公司试图签下大型企业级合同时，介入并提供某个功能或修复某个bug，就能促成交易。甚至不一定是个*好*功能：有时只是展示出你愿意且能够做出具体改变就足够了。 第二，及早预防或缓解事故（哪怕只是知道该关闭哪个正确的功能开关），就能节省大量资金：既包括事故期间直接损失的收入，也包括因客户撤单或拒绝签署待定合同而损失的未来收入。 第三，当公司试图发布一个备受瞩目的功能时，成败往往取决于一些微不足道但隐蔽的改动（例如，快速在用户设置中新增一个字段，或更新多年无人问津的、陈旧的企业数据导出功能）。对系统的熟悉程度，能决定这些改动耗时几小时还是一整周。 这些例子有什么共同点？它们都*依赖于时机*。你不能早上登录后就决定去扫清一个重大交易的障碍，或缓解一起事故，或加速一个高调功能的发布。这仅仅是运气好碰上了吗？不完全是。**你还必须本身不忙才行。** ### 保持松弛 我几年前在《搞定JIRA工单只是小把戏，不是通往影响力的路径》(https://www.seangoedecke.com/party-tricks/) 一文中写过这个观点。如果你总是100%投入到源源不断的低优先级工作中（比如，只是从待办事项里拿工单、搞定它、再拿下一个），你就会错过参与高影响力工作的两种机会。 首先，你会忙得根本无法*注意到*这些机会。你不会和做其他事的人聊天，不会看团队更新，也不会留意正在发生的事故。因此你会错过参与高影响力工作的最佳途径：主动贡献你的专业知识。 其次，如果你总是看起来很忙，你的经理就不想为你争取机会。这是参与高影响力工作的第二佳途径：让经理或产品经理说“哦，Sean有空可以帮忙，我把他拉进来”。为什么这样更好？因为经理和产品经理通常更清楚哪些是高影响力工作。他们参加你不在场的会议。 ### 无所事事 如果你应该保持时间空闲以应对高影响力工作，又不应只是埋头处理工单，那你每分钟应该做什么？就应该什么都不做吗？是的！ 实际上，什么都不做是好事。软件工程可能是一份压力很大的工作，但它通常不是*持续*高压的：压力来自偶尔的事故、高压的紧急任务，或者（现在这个时代）裁员。如果你以紧迫而紧张的状态去处理那些相对低压力的工作部分，那么当你必须处理高压部分时，你已经精疲力尽、焦头烂额了。 即使在工作的压力部分，无所事事仍然有好处。我给刚接触值班的工程师的一个建议是：不要匆忙。在加入通话或发言前先深呼吸几下，并尽量让自己“慢速思考”(https://www.seangoedecke.com/thinking-clearly/)。大多数事故会自行解决。事故期间那些手忙脚乱、抱有“也许这会有帮助”的改动，通常只会让事情变得更糟，而不是更好。一般来说，只要你避免恐慌，你在事故响应方面的表现就会超过大多数工程师。 无所事事能为你创造思考空间¹(https://www.seangoedecke.com/doing-nothing-at-work/#fn-1)。如果你给大脑一个休息的机会，你会发现更容易产生新想法。如果有人给了你一项重要任务，你可以全神贯注地去处理（而不是同时应付手里其他三件还在做的事）。当你不忙时，你就有时间去*观察事物*并吸收新信息。 ### 刻意不去做某些事 很多工程师看到有任务需要做而不去做时会感到不舒服。我也是这样。我在《沉迷于有用》(https://www.seangoedecke.com/addicted-to-being-useful/) 一文里写过：这是一种许多软件工程师共有的心理特质，因为拥有这种特质（在某种程度上）让你适合这份工作。为了有空闲时间无所事事，有时你需要强迫自己不要插手。 例如，我认为**工程师一般应该避免“胶水工作”**²(https://www.seangoedecke.com/doing-nothing-at-work/#fn-2)。大多数胶水工作——确保人们互相沟通、为你并不领导的工作更新文档、主动去解决技术债务——反映了组织并没有明确优先处理这些工作。如果组织优先处理了，你就不需要主动去做。要么这没关系，要么这是个重大错误。如果没关系，那你就不应该挺身而出：你会浪费自己的时间，还会惹恼经理。如果这是个重大错误，*你仍然不应该去做*，因为这样做会让你以牺牲自己的职业生涯和心理健康为代价，让公司免于承担自身错误的后果。 这对你来说是一笔糟糕的交易，给你的初级同事树立了坏榜样，并且为其他人不可避免地在你的位置重蹈覆辙设下了坏先例³(https://www.seangoedecke.com/doing-nothing-at-work/#fn-3)。如果后果真的很严重，就让它发生吧，这样组织才能感受到痛苦并改变其政策。 我还认为**过于乐于助人会让你容易受到剥削**。科技公司里有很多人想从软件工程师那里获取无偿劳动⁴(https://www.seangoedecke.com/doing-nothing-at-work/#fn-4)。这与通过正常渠道分配、并通过晋升、奖金（以及你的正常工资）获得回报的工作不同。我指的是通过非正式渠道找上你的工作，来自那些没有能力或不愿意确保这些工作能被正式记录在你的名下的人。例如，来自其他部门的产品经理私下发消息说“你太会查数据了，能帮我拉一下关于X的统计数据吗？”，或者来自另一个团队的工程师请你“结对”完成一项工作，结果最终是你写了所有代码，而他们悄悄地以自己的名义提交了改动。 做一定量的这类工作没问题。力所能及的时候帮别人一把也好。但你需要能够施加反向压力，要么直接拒绝，要么只是将自己的回复延迟几个小时或几天。 **避免在很可能消失的工作上投入过多精力**也是个好主意。例如，假设你和一位产品设计师合作，而他们自己也在不断摸索想要什么。早上9点他们发消息说希望页面标题看起来是A样，10点又做了调整，11点又有更多改动，如此反复。你不应该每个小时都全身心投入去重写整个页面。相反，你应该什么都不做（比如说，去散散步），然后下午根据最新的设计稿一次性重写页面。另一个常见例子是“来自一个没有足够政治资本去推动落地的经理的宏大想法”。通常你可以只是拖延时间，直到项目最终不可避免地取消⁵(https://www.seangoedecke.com/doing-nothing-at-work/#fn-5)。 ### 结论 很多软件工程方面的建议和工具都是围绕如何扩展你投入技术工作的能力而设计的：如何同时做更多事情，如何接手更大范围的项目，或者如何写出更多代码。但软件工程的成功并不由这些决定。它取决于在*正确*的时间做*正确*的事的能力，这就要求你在日常工作中刻意保留一部分精力。 根据我的经验，以80%的精力投入工作，仍然可以成为一名“高绩效工程师”。实际上，这反而*更容易*，因为你不太会因为压力而犯低级错误，而且你也能随时准备好去接手那些能带来超额回报的高影响力任务。 这并不意味着你永远不应该100%全力投入。我认为可能一年中有两到三次，我会竭尽全力地工作：长时间、高强度专注，从醒来到入睡都在思考问题。但我只在这种工作*回报确实非常高*的时候才使用这种方式(https://www.seangoedecke.com/the-spotlight)。一年中的其他时间，我会相对轻松地度过。 编辑：这篇文章在Hacker News (https://news.ycombinator.com/item?id=48442880) 上收到了一些评论。评论者讨论了当你拥有弹性时间时，如何避免被经理找麻烦 (https://news.ycombinator.com/item?id=48446245)（根据我的经验，如果你通常产出很高就没问题，但经理差异很大），以及工程师是否真的能掌控自己的工作负荷 (https://news.ycombinator.com/item?id=48443273)。 --- 如果你喜欢这篇文章，可以考虑订阅 (https://buttondown.com/seangoedecke) 邮件获取我的新文章更新，或者在 Hacker News (https://news.ycombinator.com/submitlink?u=https%3A%2F%2Fwww.seangoedecke.com%2Fdoing-nothing-at-work%2F&t=Doing+nothing+at+work) 上分享它。 这里是一篇相关文章的预览，它与本文共享标签。 > “只会说不”的工程师是ZIRP时代的产物 那些总是拒绝 (https://www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise#a-senior-developer-is-a-problem-avoider) 的工程师是高级和Staff工程师中的一种真实原型。他们的角色是放慢速度，阻挠那些增加复杂性的功能开发，并确保尽可能少地编写代码（因为代码是负债）。我们可以将其称为“只会说不”的工程师，与“只会说行”的工程师相对。“只会说行”的工程师痴迷于快速行动，默认批准代码变更，重视MTTR (https://en.wikipedia.org/wiki/Mean_time_to_repair) 而非MTBF (https://en.wikipedia.org/wiki/Mean_time_between_failures)，并且倾向于发布大量代码。“只会说不”的工程师痴迷于质量，乐于放慢速度，默认阻止代码变更。大多数工程师处于这个光谱的中间位置。我所说的“只会说不”的工程师，指的是最强烈认同该原型的那群工程师。继续阅读... (https://www.seangoedecke.com/the-just-say-no-engineer-was-a-zirp-phenomenon/)