我前段时间在知乎写过一篇回答：《你见过的最差的程序员是怎样的？》
那篇回答下面，有很多网友评论。
但有一件事，我当时没有写。其实，我前前后后花了两年多时间去培养他，最后才决定把他优化掉。
现在回过头来看，我觉得自己最大的错误，不是选择了培养，而是培养得太久了。
因为我一直都有一个管理理念。
能培养的，尽量培养。
团队要想长期稳定、高产出，不能总想着招人，更要想着把现有的人培养起来。
所以，那两年多里，我是真的投入了很多时间。
他每次提交代码，我都会认真做 Code Review，不只是指出哪里有问题，还会告诉他为什么这样写不好，正确的思路应该是什么，甚至写demo代码给看。
很多需求，我也会手把手带着他分析，一起讨论边界条件、异常场景，以及性能、安全、可维护性这些非功能性的需求。
我一直觉得，只要愿意教，再给一点时间，人总会成长。
所以，每隔一段时间，我都会告诉自己：
再给他一点时间吧。
结果，这个"再给一点时间"，一给就是两年多。
直到最后，我才不得不承认：
不是每个人，都能培养出来。
就在今天2026年7月12日，我还在处理他以前遗留下来的问题。
他基本不主动去考虑边界条件、异常处理、性能、安全这些事情。只要功能稍微复杂一点，几乎都会留下坑。
有人可能会问：
那你不是一直做 Code Review 吗？
是的。
但我自己也得撸代码呀，还要带团队，也要负责大量业务需求和技术需求，很多核心功能都是我自己在写。
我不可能把所有时间，都花在审核一个人的代码上。
而现实就是，只要我没有仔细审核，他写的代码，当前或者将来，大概率都会出问题。
有的问题上线当天就暴露了。
有的问题当时看起来没事，几个月以后才爆出来。
今天周末，我处理的，就是其中一个。
因此：
一个长期不能独立完成工作的员工，占用的不是一个人的成本，而是整个团队的成本。
- 他写代码，需要别人审核。
- 上线以后，需要别人兜底。
- 出了线上问题，需要别人救火。
看起来是一个人在工作，实际上却长期占用了另外一个人的时间。
而那个长期兜底的人，很多时候就是管理者，或者团队里的核心骨干。
时间一长，被拖慢的不只是一个人的产出，而是整个团队的效率。
这也是我后来为什么改变了自己的管理方式。
我依然坚持培养人。
但我不会再无限期地培养一个人。
我会投入时间，会手把手带，会认真做 Code Review，也会给他成长的机会。
但如果经过持续的培养和反馈，依然看不到成长的趋势，我就会及时止损。
因为管理者最大的责任，不是证明自己能培养所有人。
而是让整个团队持续创造价值。
所以，如果你问我：
发现下属能力不行的时候，是花时间培养他，还是干脆换掉？
我的答案是：
先尽力培养，但培养一定要有期限。
