这几年陆陆续续带过五六个人，说心得有点大，就把印象最深的三个写一写。三个人的问题完全不同，而且前两个的问题，主要出在我身上。
第一个：我教得太细
他是应届来的，很聪明，学东西快。我当时刚开始带人，非常怕他做错，于是把每件事都拆得极细——这个模块怎么设计我先跟他讲一遍，代码写完我逐行看，评审意见能写四五十条。
头两个月效果特别好，他产出的东西质量很高，我很有成就感。
问题出在第四个月。有一次我出差一周，回来发现他有个任务卡了三天没动。我问他为什么不问别人，他说他不确定该怎么办，想等我回来。
那一刻我才明白我做了什么。我没有在培养一个工程师，我在培养一个执行我意图的接口。他所有的判断力都被我的评审意见替代了，因为反正我会兜底，反正我的意见更对。
后来我改了做法：设计我不再先讲，让他先写，写完我们讨论他的方案哪里有问题；评审意见从四五十条压到最多五条，只挑真正会造成后果的，剩下的忍住不说。
这个忍住不说非常难。有大概两个月，我看着一些我明知道不够好的代码合进去，心里很难受。但半年之后他的成长速度明显快了，而且开始会在评审里反驳我，有两次他是对的。
我从他身上学到的一条：新人需要的不是正确答案，是犯错之后被兜住的经历。你替他把所有错都避开了，他就永远不知道错误长什么样。
第二个：我放得太开
吸取了上一个的教训，下一个人来的时候我走到了另一个极端。
她有三年经验，不算新人，只是新来。我想着她有基础，就给了很大的自由度：目标给她，路径她自己定，我一周一次一对一，不干涉过程。
三个月后出了问题。她做的一个模块，方向从一开始就是偏的——不是技术上有错，是她理解的业务目标跟实际不一样。这件事本来在第二周就能发现，但我们的一对一聊的都是进展怎么样、有没有困难，她说没什么困难，因为在她的理解里确实没困难。
返工花了六周。她那阵子状态很差，我知道她觉得是自己的问题。
我后来反省的是：放手和不管，看起来像，实际上差很远。放手是我知道你在什么位置、往哪个方向走，但我不替你走每一步；不管是我根本不知道你在哪。我当时是后者，还给自己找了个信任的说法。
改法也很具体。一对一里我不再问有没有困难——这个问题的答案永远是没有。我改成三个问题：这周你做的东西，最终会被谁用、怎么用？你现在最不确定的一件事是什么？如果这件事最后失败了，你猜最可能是因为什么？
第三个问题特别好用。它给了对方一个安全的方式说出担忧，因为那是假设，不是承认自己有问题。
第三个：找到了一点分寸
第三个人来的时候，我的做法大概是这样：
前两周，我给他排的都是小而完整的任务。小是为了失败成本低，完整是为了他能走完一遍全流程——从需求到上线到看线上的数据。我见过太多新人干了半年还不知道自己的东西上线之后长什么样。
第一次让他独立做决定，是在第五周。那个决定不重要，两个方案差别不大。我故意没给意见，只问他为什么选这个。他讲了三条理由，其中一条站不住，我指出来，他改了主意。这个过程我很在意——重要的不是他最后选了哪个，是他知道选择是要有理由的。
还有一件小事我一直坚持：他第一次搞砸的时候，我在群里担了下来。
那次是他改了一个配置导致了一个小故障。他自己在群里说是我改的，我马上接了一句：这个是我 review 的时候没看出来，我的责任，我们十分钟内恢复。
事后我私下跟他复了一遍，说得挺严的，该说的都说了。但在公开场合，我不会让一个来了两个月的人独自站在那儿。
这一条我认为比什么方法论都重要。他后来跟我说，那件事之后他才敢真的动手做事。
几条零碎的
- 别说有问题随时找我。这句话等于没说，因为新人判断不了什么算问题。要给具体的触发条件：卡住超过一小时就来找我，不管什么事。这个一小时是可执行的。
- 一对一不要变成进度汇报。进度用文字同步就行，见面的时间应该聊那些不好写在文字里的。
- 不要把自己走过的弯路当成必修课。有些苦是环境造成的，不是成长必需的。我们这一代人特别容易犯这个毛病。
- 他做得好的时候，要具体地说好在哪。做得好啊、不错这种话，接收方是无感的。说这个地方你把异常情况先考虑了，比我预期的细，他才知道以后该往哪儿使劲。
最后说个我到现在也没解决的问题：怎么带一个各方面都还行、但就是不太投入的人。
技术不行可以教，判断力不够可以练，唯独那个想把事情做好的劲头，我不知道怎么给。我试过谈心、试过给更有挑战的活、试过给更多认可，效果都很有限。
可能这本来就不是我能给的东西。但我还没完全接受这个结论。