为什么说执行 996 工作制的脑力劳动者非蠢即坏
抱歉我用了这么个吸引眼球的标题。但我其实是想分析一下 996 工作制度到底存在怎样的问题。注意，我说的是身体力行执行 996 工作制的人，而非要求员工进行 996 工作的老板，这是两类人，今天我想骂的是前一类。
如果让我给执行 996 工作制下个定义，我想不能把全身心投入到工作和事业上的工作方式等同。它并不指工作时长；而是指刻意的制度性的把工作安排在非正常工作时间段。对待工作，不是以是否完成计划内的工作为衡量标准；而是本末倒置的先预设工作时长，然后想办法填满这些工作时间。
对于我最熟悉的游戏软件行业，它的工作本应该是脑力劳动为主。尤其对于程序员来说，主要的工作应该是在你的脑子里通过思考完成的，如果你的工作效率受限于每天不停的敲打键盘、移动鼠标、那么就变成了一项体力劳动。不久的将来，猴子和 AI 都能替你把事情干了。体力劳动或许可以通过制度性的延长工作时间来加快进程，可硬生生的脑力劳动变成体力劳动，只能用蠢来解释了。
如果工作的重点是通过大脑思考完成的，那么就不在乎你在什么时间，坐在哪里进行这些思考。甚至入睡前的那段时间都能想很多，限制每天在办公室坐上 10 多小时没有任何意义。那为什么说起来简单，996 反而成了国内程序员工作的普遍状态呢？我以最大的善意揣测人性，若他们不是心眼坏的话，那只能是大多数从业程序员能力欠缺了。
从游戏行业看，投资做游戏的人最期盼的是什么？并不是压榨你用更短的时间把游戏做出来，而是你能给个明确的计划时间表，在这个时间内保证质量的完工。这个时间可以比较长，但只要计划是明确的，就能估算出未来的收支情况。成功的游戏利润率非常之高，如果游戏能成功，用暴力手段压缩制作时间而减少的成本简直无足轻重。所以，游戏产品上线前，一改再改，无限延长开发时间反而是常态。
健康的项目，计划的落实是第一位的。那么最影响计划安排的是什么？不是工作时长，而是开发中的不确定因素：
顺利的情况下，一个人一天产生 300 到 500 行代码游刃有余。一个游戏程序最终的代码量，抛去一些机械产生的东西，由人的智力产生出来的不会超过 10 万行。这样算也就是 10 个人月不到的事。以现在动则十几数十个程序的开发团队，开发几年才能让游戏上线来看，绝大部分的工作都被废弃掉，或是意外产生的额外量。比如 Bug ，为一个 Bug 花掉 2,3 天时间，这种经历我想大部分程序都经历过；更常见的是改需求，不断地废弃掉已经完成的工作。项目完成后复盘的话，肯定会发现，如果一开始走了正确的路，能压缩掉一个数量级的项目开发时间。996 制度能增加多少工作时长？2 倍我觉得是极限了，再增加工作强度，影响到程序员的日常判断力的话，一定会大幅度的增加出错的概率。
所以，如果存在一个工作计划，那么就不可能事前规划出超长工作时间。因为你必须为不确定因素留出时间。因为经验原因未能按计划做完事情，说明能力不足，有改进空间。但既然是意外，就有顺利的时候，无论多糟糕的程序员，都有不出 bug 的日子，制度性延长工作时间对于落实工作计划毫无意义。
除非，程序员干的就不是智力工作。当我们把工作的智力因素无限降低的话，996 工作制度的确可以保障任务以更加稳定的时间周期完成。就好比你用计算器从 1 加到 100 ，只要你肯把 1 2 3 ... 100 依次按下去，总能得到结果，当你按了几十次按钮后，就能大致估计出全部按完 要多长时间；而寻找等差数列的公式、验证其正确性，然后用更快的方法得到结果，反而是不可控的。996 有效的前提就是：一定要找到最笨最机械的方法去执行，通常必须由蠢人来干，如果你不够蠢，就要把自己变得更笨一点；整个团队的智力在工作状态中拉到一条线上，就可以有条不紊的推进了。
我刚刚提到了团队，团队合作正是另一项重大的影响因素。
996 工作制度下，通常就是无休止的讨论、会议、头脑风暴等等。团队的工作相互依赖，你的工作需要我的工作先完成，我的工作需要交给他审核。团队规模越大，分工越细，越需要更多的人长时间待在一起。否则，做了一半的事情找不到上游或下游就无法开展下去。可是，受过基本训练的合格程序员都应该明白一个道理：越是复杂的项目，就越是需要不同部分（工作）模块的解耦。为了模块划分干净，可以不惜增加模块间的沟通成本。工作也是这样，随时可以找到人讨论问题并不是一件好事，它好比两个模块间事无巨细的反复调用对方的 api 。就算你全部实现都 inline ，开到 -O3 的优化，都未必高效。设计问题无法用精巧的实现弥补；工作规划的失误，无法用超长的工作时间抵消。我们应该容忍工作因为沟通延迟或失误造成的工作浪费，但不应该容忍无穷尽的讨论和会议浪费掉的时间。聪明人规划好计划后，会珍惜每次有限的沟通机会。
不轻易打搅别人应该是职业人应该具备的基本素养。这点至少我觉得自己是做到了的。记得 10 多年前，我有项目半夜出了 bug ，因为是非工作时间，即使 bug 不出在我编写的模块中，甚至我连代码都没看过。可我还是忍住不联系相关的同事，花了一个通宵阅读可能有问题的代码，并在天亮前修复；另一个项目在上线发布前一晚，一块关键数据除了问题，但是维护数据的人已经下班，修改数据的专有工具甚至没有人会使用（编写工具的人也下班了），我的选择不是联系负责的人，而是根据数据格式连夜重新编写工具，在用新写的工具修改错误的数据。举这样的例子，一是想说明，全心投入到工作中，和 996 不是一码事；二是想说，有能力有意愿加班做事是一回事，要求别人是另一回事。并没有那么多耽误不起必须在今晚完成的工作，如果你判断事情严重到必须当晚解决，那么就要具备独自解决问题的能力。如果你没有这个能力，第二天天也不会塌下来，好好做好下一段的计划，不要总是陷入这种僵局。
减少工作沟通并不是说不和别人沟通，闭门造车。反而应该在工作外的时间，尽可能地和不同的人交流，了解不同领域的人做了什么，采用了什么方法。这样才能开拓视野。工作中的许多困境往往都是因为陷入了思维定势，需要一个外部灵感帮你跳出来。和影响工作进程的各种偶然因素一样，捷径出现在眼前也是出乎意料的。你无法期待一个灵感能给你节省多少时间，但若你关上了门，每天干到睡觉，起来就奔赴办公室，也就关上了这扇门。
谈完了蠢，就想说说坏了。这个坏或许不是本心，但实质性的伤害了别人。
当人不能通过自身的技能完成任务，又无法提高自身达到要求。或许能做到的就是给自己降级，用更无智力含量，对技能无所要求的方法来做事了。这样对自己是最佳的选择，因为本质上 996 这种制度性工作才是最容易办到的事，无需思考，只用不停的敲打键盘即可，还能获得极大的自我满足。同时，这样可以把身边的同事，同行业的其他人也一起拖入泥沼。我做不过你，但我可以肝死你，恐怕是这一类人的心声了。
聪明的工作方式，需要团队一起都用聪明的方法来做事，每个人都勤于思考，找到高效的途径。通过独立思考，减少自己的错误产出（尤其是会影响到他人工作的产出）。但是，只要有一两个人做了坏事，就很难维持。比如，原本可以由一个人写一个 meta 模块解决一堆类似的问题，可一旦有一个人偷懒写下一坨狗屎只解决其中一个，并要求后面的人依照这个模板复制修改 10 份，那么工作就轻易的拓展到了 10 人份。最终的结果就是劣币驱逐良币，团队所有人都要趋向于用笨方式更稳健的做事。一旦脑力活动从工作中消退，就演化成 996 制度性长时间体力劳动。
不思进取的工作方式还会导致对自己的结果不做进一步思考，设计好的功能扔给别人实现，期待做好了再看效果；写好的代码不仔细自我检查，期待有测试人员把关，对坏味道无动于衷，等出了 bug 再改，反正干什么活不是干呢？debug 也不影响拿工资就是了。
如果一整个团队就这么下去，坏影响会蔓延到同业。因为无论这种工作方式效率多低，但是产出稳定啊。滥产品能做出来也是产品，也能占据市场，至于对市场是否有消极影响就无所谓了。暂时做不出好产品的团队，一旦忍受不了，最便捷的方式就是把自己降低到同一个水准上。正所谓把敌人拉到和自己一个水平，用自己最熟悉的手段击倒对手。这或许才是整个行业都充斥着 996 工作制的真相。