我把自己当成了取之不尽的资源

我花了海量的精力，去精心优化系统的每一个部分，却几乎没有把任何精力放在那个最重要、也最不可靠、却支撑着这一切运转的部件上：我自己。我把自己当成了一种取之不尽、随叫随到的资源——一台可以无限期满负荷运转的机器——而这个项目为这个错误付出了代价，一次又一次，而且代价高昂。

这是我抵抗得最久的一个教训，因为承认它，感觉就像在找借口。但它不是借口。它只是对一个我拒绝去建模的约束的如实描述，而拒绝为一个真实存在的约束建模，并不会让它消失。那只会让它在某个时刻把你打个措手不及。

那个我从未建模的部件

我曾为自己善于审慎地思考各种极限而自豪。我会推敲系统每一部分的容量、它的失效模式、它在负载下会如何表现、它会在哪里崩坏。每一部分都推敲到了，唯独一个例外。我从未哪怕一次，把同样的工程诚实用在自己身上。

我从未明说，却在暗地里假定：我可以永远满负荷运转——我的精力和专注力是无限的、永久在线的，那个干活的人没有容量上限，也没有任何值得提前规划的失效模式。任何称职的工程师都绝不会这样去给一个部件建模。你绝不会在”某个关键部件吞吐量无限、永远不需要维护”的假设之上去设计一个系统。然而，这恰恰就是我给自己建模的方式，而我甚至没有察觉到自己在这么做。

以塌方收场的冲刺

模式总是一样的，而我花了多到令人难堪的重复次数，才看清它。先是一阵激烈而亢奋的工作——长时间的全神贯注，远远冲过任何可持续的极限，因为那种感觉富有成效、紧迫而美好。然后，带着十足的可预测性，崩溃来了。接连数天，有时是数周，我几乎完全无法工作，那口井就是干了，再怎么努力也注不满。

而每一次，无一例外，我都责怪自己。我的自律、我的软弱、我没能挺过去。我把崩溃当作一种个人的道德败坏，一种更坚强的人就不会遭受的东西。在很长一段时间里，我从未想到：崩溃根本不是性格上的失败。它完全是机械性的后果——把一个有限的资源逼过了它的极限。这资源做的，正是一切有限资源在被透支时都会做的事。唯一令人意外的，是我居然一次又一次地感到意外。

倦怠是系统性失效，不是意志力失效

正是这个重新框定的视角，终于让某些东西发生了改变。我一直把自己的崩溃当作意志的失败——我本该更坚强、本该挺过去、本该更渴望它。但倦怠不是性格缺陷，而把它当成性格缺陷，只会保证你不断地把它制造出来。

倦怠不过是：当你把任何一个系统逼过它可持续的容量、并持续足够久时，所发生的事。这是一种系统性失效，而非道德上的失效。把它叫作意志力问题，就像把一台过热的发动机叫作怯懦问题——它从根本上误诊了出错的地方，于是开出了恰恰相反的药方。对一台过热的发动机，答案不是要求它更勇敢。答案是不要再把它逼过它本就注定会有的极限。对一个精疲力竭的操作者施加更多意志力，并不会产出更多产出。它只会产出一次更惨烈的崩溃。

节奏的算术

在这一切之下，是一道我完全忽视了的算术题。一个漫长而艰难的项目，不是靠任何单一时刻的峰值产出来取胜的。它是靠在极长时间里累加起来的总产出来取胜的。而这里有一件本该显而易见的事：一个温和、可持续的节奏，稳稳地保持许多个月，其总和远远超过那些被塌方所打断的英雄式冲刺的总和。

冲刺感觉上更快。在当下，它确实更快。但放到项目真正的全程来看，它要慢得多，因为崩溃所付出的代价，远高于那些爆发所赚到的。每一个壮观的、过度工作的星期，都换来了一个惨淡的、用于恢复的两周，而当你诚实地把整段跨度算清楚时，这笔交易永远是亏的。我一直在为”当下感觉有多快”做优化，而当这场比赛是以月为单位来计量时，这恰恰是错误的变量。

休息是一种输入，不是一种背叛

让我深陷其中的部分原因，在于我看待休息的方式。我把它当作工作的缺席——从进度里偷走的时间，一种该为之愧疚的放纵，一种投入不足的证据。于是我把它压到最低，并为压低它而感到自己很有德行。

但对一个从事持续性认知工作的有限资源来说，恢复并不是产出的反面。它是产出的一项必需输入。休息不是从工作里夺走的时间；它本就是让工作得以可能的一部分。拒绝休息不是奉献。那是让一台机器在不维护的情况下运转，然后把那必然到来的故障当成运气不好，而不是当成跳过维护所带来的、直接而可预见的结果。我把对一项必要条件的忽视，错当成了一种美德。

为操作者而设计

于是我终于开始去做那件我回避了太久的、显而易见的事：围绕那个运转项目的人的真实约束来设计这个项目，就像我会围绕任何其他真实的限制来设计一样。一个我真能保持得住的节奏，而不是一个看上去很唬人、却以崩溃收场的节奏。为糟糕的日子留出刻意的缓冲，因为糟糕的日子永远都会有。对我自己的容量做一份诚实的核算——把它看作一个有限的、会变化的、需要维护的东西，而不是一台我没能活成它样子的无限发动机。

起初，这感觉像是在降低我的标准。其实恰恰相反。这是终于把真实的系统认真对待起来，包括其中由一个人构成的那部分，而不再假装那部分是它永远不可能成为的样子。

更深一层的教训：你正是那个你拒绝建模的瓶颈

归根结底是这样。在任何一个主要由一个人扛起来的项目里，那个人是整个系统中最重要的部件——而吊诡的是，他也是我们最不愿意当作一个真实的、有限的、需要维护的东西来对待的那个。我们会满怀爱意地优化代码，又毫不留情地虐待那个操作者，然后纳闷为什么整件事老是停滞不前。

但项目只在操作者动起来时才前进，而操作者不是无限的。可持续性不是某种软性的、可有可无的、自我放纵的小情调，等真正的活干完了再来照顾一下。它是一个硬约束，所有其余的工作都得装进这个约束里。我用了很长时间，把我系统中最关键的那个部分，当作唯一一个不配被工程化对待的部分。项目跑不过那个错误，而到头来，我也跑不过。

— 没有信号，没有收益，不构成投资建议。