我曾经在一个 YouTuber 的视频中得知这本书，本想看看有没有中文本在售，奈何没有，遂买了英文版硬着头皮读着。断断续续读了一段时间，最近也才读到一半。

在过去的工作中，有幸担任过小组长的职位。在担任组长之前，我并没有进行相关的培训，凭着感觉做着一些管理的工作；而在我认为在这个公司没有成长空间之后，我才慢慢去了解一些晋升相关的规则。

当时在职的时候有一个心理特别明显，我以为在我组里的工程师也应该是差不多是这样想的，就是「在这里能学到东西」。当时我给组员做了一个问卷，大概是有三个选项（与同事的相处氛围、薪资、能学到东西），在团队里最在意的是哪几个？大部分的同事都选择了后两个，而最多的是「能学到东西」。

一次会谈中聊到这个事情，我的领导（当时的技术总监）觉得我做这个问卷的关注点不对，他认为学习和成长是个人的事情。而我则认为，如果一个人在工作中没有成长，那么他在这个公司的发展空间也就没有了，所以我认为这个问题是团队的事情。而且当时的公司，晋升规则是很不清晰的，或者说是没有，这是小公司或者创业公司的通病，也注定了很难留住人才。

回到「The manager’s path」这本书上，有一些点是让我非常反思的，比如「alpha geek」；总结起来，书中描述的「极客」有下面这些特点：

• 优秀、高效的工程师；

• 相信最聪明的人应该成为经理；

• 倾向于通过贬低下属的错误来削弱为 Ta 工作的人，而且在最坏的情况：在没有提前警告的情况下重做队友的工作；

• 有时候喜欢独揽功劳，而不是承认团队的力量。

• 好的想法都来自于 Ta，坏主意都不是 Ta 出的，除非 Ta 事先就知道这个主意会失败；

• 觉得每个开发者应该知道 Ta 所知道的东西，如果你不知道，Ta 很乐于指出你的无知；

• 当其他人批评或者抱怨「极客」构建的系统时，Ta 会觉得受到威胁；

• 非常讨厌那些被他们鄙视的人来指引方向，同时也鄙视非技术角色；

这些特点真的可以当做一面镜子。

结合我自己早些年的经历，「不提前告知就重写其他人的代码」我就做过这样的事情。对方是我带的实习生，他很乐于去做一些有挑战的工作内容，也很积极主动，所以在我和我的领导看来是一个「高潜」。在一个我负责设计的系统中，我指派了一个复杂度相对高的功能给他做。由于各种原因（可能任务难度对他来说确实有点高，也可能编码前的设计沟通做得不够），最后结果是他产出的代码不符合我的预期，而又由于这个模块是这个系统中很重要的一部分，我看到后觉得 review 反复更改耗时比较久，就直接重写了。后来这个实习生没有转正，选择了离开。我很遗憾，时常觉得可能因为自己没有好好指导他，导致他离开了。

书中也提到如何指导一个实习生：

• 交给 Ta 一些简单的 Feature（对自己来说是一两天可以完成的事项）
• 尽可能跟 Ta 坐在一起（指引方向，不让其迷失）
• 认真聆听（Ta 即使没听懂，可能也不会问你，试图挖出这些问题）
• 清晰的沟通（让 Ta 保持在正确的方向上）

【完】