带初级开发者这件事，教他们的同时，我自己学到的可能更多。有些方法确实管用，有些纯属浪费时间。以下八条是我反复验证过的。
一、解释"为什么"，而不只是"怎么做"
"我们这么做是因为……"比"照这个做"记得更牢。当你给出背景（比如"我们用这个模式是为了不用调API也能测试"），他们开始自己归纳规律，做出更好的判断。一句"为什么"能省下大量重复纠错的时间。
二、把代码评审变成教学现场
PR反馈是教学机会。别只写"改这里"，要加上"因为……"或者"另一种做法是X，在Y场景下更好"。有文档或示例就指给他们看。久而久之，他们会预判这些要点，需要的评论越来越少。
三、卡壳时结对，但别抢方向盘
有人卡住太久，就结对30到60分钟。共享屏幕，一起讨论问题，一起调试。你帮他们疏通，同时观察他们在哪里困惑——这对完善文档或改进新人入职流程很有用。别接管，要引导，让他们自己主导。
四、给一块小地盘让他们做主
分配一个小功能、模块或bug区域，归他们负责。设计、实现、维护全包。他们会提问、会犯错——这就是学习过程。你留在旁边做评审和解堵，但由他们牵头。
五、把"不知道"常态化
明确告诉大家，没人什么都知道。说"我不确定，查一下"或者"好问题，我去确认"，这是在示范学习是持续的过程。这样能减少装懂的压力，鼓励提问。
六、把"好"的标准说清楚
明确写出"好"是什么样："新逻辑的PR要有测试""复杂代码要注释""改动了setup要更新README"。期望清晰，他们就能自检改进，不用瞎猜。
七、别事事代劳
如果你总是跳进去改他们的代码，他们学不到东西。让他们自己修bug（需要的话给点提示）。只有阻塞团队或他们彻底卡死时才介入，默认问法应该是："你试过什么？你觉得下一步该做什么？"
八、勤检查，短平快
简短、频繁的检查（"任务进展如何？有阻塞吗？"）胜过漫长、稀少的会议。他们及时获得帮助，你也能及时发现他们卡壳或需求范围不清的情况。
带好新人确实耗时，但回报明显：团队变强，你也能更清楚自己的系统和文档对新人是怎样的体验。目标不是复制另一个你，而是帮他们建立思考和交付的自信。
热门跟贴