背景

A佬是国内某TOP大厂算法工程师，也是我相识多年的好哥们。他是非常强的一个大佬，拿了校招的最高职级+薪资进了国内top的互联网公司中最核心的业务部门，我经常从他那里学到很多东西。

本文取自某天晚上我把他邀来我家喝酒，两个人的日常聊天，恰好聊到了这个话题…

另：我开启这个话题的时候也刚刚工作，对很多事情的认知并不到位。看到这个题目，如果让我现在来说，我觉得把工作做得又快又好最重要的是第一性原理，不过这就是另一个话题了，有时间再写一篇文章细细展开。

正文

本文是凭借记忆所写，因此很多细节和对话都是方便阅读写出来的，并且省略一些private的细节，我发给朋友去check和检查的，大家只关注重点和我想表达的意思就好。

…

我：我记得上次聊天的时候，你提到，贵司的特点是工作量很大，要把工作做的非常solid，因此你们公司的工作量往往是其他公司的2-3倍。但同时，我了解到的信息是，你们公司的另一个文化特征是”快”，做什么业务都非常快。我想知道，为什么这两点是可以同时拥有的？在我看来，solid就会拖慢工作节奏，但你们公司的业务并没有呈现出这个特点，至少我完全没看到，并且也没听人讲过。所以我很好奇，你作为（也许是）最强的中国互联网公司（之一）中最核心部门核心业务的员工，我想你一定有很多发言权。

A佬：我现在就来解答你这个问题。我过去做的所有的工作、现在做的所有的工作和未来打算做的所有的工作，都会整理成文档记录下来，然后把这篇文档发出去，我的同事、+1、+2会给我很多的评论来 challenge 提问我，我必须一一解答他们的质疑，只有这些回答被通过了，这些策略才会被采纳。所以工作需要更多的工作量，做的更加地solid。

我：哈哈，所以这其实有点像学术界的投稿，当你有一个好的idea或发现觉得还行，你投出去，然后一堆 reviewer 就会过来喷你，你必须通过 rebuttal 来回应他们的质疑说服他们，才能使得你的文章被接受。不过，我觉得好的一点是，工业界应该不会有人关注 novelty，只会关注性能效果，效果好就可以，这是我觉得比学术界的那帮 reviewer 们好的多的一点。（笑）

A佬：哈哈，是这样。

我：可我还是不理解，为什么你还会做的快呢？既然工作量多了很多，凭什么还可以比其他公司做的更快？凭什么你们还可以保持这么快的业务推进速度？我觉得把东西做的solid和把东西做的很快，本身就是一个paradox，不可能都满足。而且你这么做会花费大量的时间来写文档，这些文档都是必要的吗？我认识贵司的很多朋友，他们很多人都向我吐槽贵司的文档文化，说形式主义，写一堆文档浪费时间，大家都卷着写，就很烦。

A佬：（笑），不同部门的方法和目标是不一样的，对公司业务来说，核心部门的文档非常重要，因为其他的部门都需要使用我们的文档。从我个人角度来说，我觉得写文档也是很有必要的，因为这些文档是不断地被复用和查看的，首先我自己是每次实验都检查这些文档，其次我的同事如果需要的话，他们可以直接检查和使用我的文档，就省去了很多不必要的沟通交流。而且我做的工作非常多，如果没有文档的话，我根本记不住这么多的细节。如果因为记不住而出错的话，那么这些错误带来的时间浪费反而是更大的。

我：这一点我自己也深有体会。我很感谢你推荐给我写 SOP 这个文档的习惯，我一开始也不理解，后面发现真的很好用。因为我每次起训练任务都要修改和检查很多的参数，如果有一个错了，那么起的实验就完全白跑了，这其实是对时间的巨大浪费。后面我每次起实验都按照顺序检查一下我的SOP文档，有点像是外科医生做的List清单思维，这样保证每一个环节不出错，就不会因为前面的错误而拖累时间。

A佬：是的，solid 本身就是快，因为前面你做的很solid的，后面就会少走很多弯路，这样反而是快了。

我：这里其实是有一个观察，就是大部分情况下，可能我们做的慢并不是我们工作和执行能力慢，而是因为被很多莫名其妙或者不必要的错误挡住了道路，即使我们做的很快，因为结果未必是对的和好的，其实前面那么着急也没用。

A佬：是的，我觉得你花一天时间还是两天时间去实现一个功能的代码，其实对结果的影响区别不大，关键是你实现的要对，要起作用。代码谁都会写，无非写的快些写的慢些。我觉得工程能力并不重要，重要的是你在写代码前，和写代码后的思考，写代码本身是最简单的。

我：笑死，我觉得这是你作为 ACM 信息竞赛大佬的凡尔赛(…)

(说回来)，我觉得用一个词来总结，就是”慢就是快”。因为系统是复杂的，而复杂系统的变量非常多，每一个变量都会影响着最终的结果，而人的记忆力是有限的，人是会出错的，所以需要完整的sop来进行流程管理。我们前期花很多时间build这样一个sop，然而一旦这个sop build 好了，我们后面的迭代会非常快，实验会加速。一个印象很深刻的例子就是，我有一天晚上起一个训练任务，跑了几个小时，突然我的同事过来和我说，有个监控的参数没有改，必须停掉重启。我立刻重启了，并且把这个参数加入了我的sop中，我知道后面我就肯定不会再发生这种问题了。

A佬：是的。

我：你觉得还有没有哪些方面是体现”solid 就是快”呢？除了我们说的写各种文档这样。

A佬：solid 是贯穿整个实验始终的，而不只是实验前。时时刻刻做到solid，就是快。比如我今天要起一个实验，我有一个预期的结果，然后这个实验可能要等到明天后才能出结果，我不会把这个实验就放在这里，然后等明天早上起来再看，我今天晚上就会监控观察，在经过了部分数据之后（没有全量数据），实验的指标是否符合预期。

我：所以你们有一些 intermediate metric 去监控？

A佬：是的，如果这些指标出现了异常，我会立刻去检查和分析是哪些指标出现了异常？造成的原因是什么？是因为我代码的bug没有写对，还是逻辑是有问题的，如果发现问题，立刻进行修改重启实验，这样就节省了整整一天时间。

我：笑死，要不就说xx和心脏只有一个能跳动呢。那你现在需要打开电脑看一下训练情况吗？

A佬：哈哈不用

我：那我去打开电脑看下……

A佬：哥，别卷了，差不多得了

我：哈哈。所以要得到最快的feedback，这样才能最快的做事。我自己深有感触，要是一开始我做科研的时候就懂得这个道理就好了哈哈哈。我觉得让我深受启发的一点是，我们的工作可能会包含这样一个事实：复杂系统是会受很多因素影响的，而每一个因素都会影响最终的结果，因此会造成混乱，混乱会拖累我们的进度。我们很多工作做的慢，大部分是因为被这些混乱和噪声影响，持续产生无效的结果，所以慢就是快。另一个事实，再复杂困难的流程，一旦被标准化，就可以被迅速加速，从而产生正向反馈，加速迭代，最终产生了更快的结果。

A佬：是的。

我看了看表，夜已深，给他的酒杯又倒上最后的酒，道：这酒后劲有点大，我有点晕了哈哈哈。

A佬：我也有点晕了。

我：行，我们不聊工作了，终于开始步入正题了，燕国地图实在太长，我们开启讨论下一个话题吧，爱情，八卦下你的相亲故事。

A佬：好啊。

…