Stop Chasing 10x Programmers: Why System Design Beats Individual Heroism For Sustainable Tech Teams / 别再追捧「十倍效率程序员」：为什么系统化设计比个人英雄主义更能支撑技术团队长期发展
I recently came across a thought-provoking piece that hit on a pain point almost every tech team has faced at some point: the trap of celebrating individual "super performers" instead of building processes that work for everyone. It’s so easy to get impressed by that one engineer who can fix a production bug in 20 minutes, or crank out a feature in half the estimated time. But have you ever stopped to think what happens when that person leaves, or even just takes a two-week vacation? Suddenly, the entire team’s velocity grinds to a halt, and no one knows how to fill that gap.
这篇文章提出的核心观点非常戳人：企业级开发的本质其实是对系统复杂度的管理，我们的目标从来都是降低 Bug 率、保证可扩展性、同时快速交付，而这些目标光靠一两个能力突出的员工根本不可能长期实现。就像我们偶尔会刷到短视频里那些手艺精湛的工人，他们闭着眼就能把活做得又快又好，看起来是老板赚了——同样的工资，这个人能产出别人好几倍的工作量，但本质上这只是个人能力拉高了团队效率的上限，整个流程本身其实是低效的。一旦这个人走了，同样的活其他人根本做不到同样的水平。
What the author calls a "system-based approach" isn’t just a bunch of rigid rules to restrict people, it’s built on a very realistic premise: everyone is human, everyone gets tired, distracted, or makes silly mistakes, and we should design processes to minimize the impact of those human factors, not hope they never happen. A perfect example is the standard practice of blocking direct pushes to the master branch and requiring pull requests instead. No one assumes engineers are going to intentionally push bad code, but everyone has had that moment where they accidentally commit to the wrong branch after a long day. A good system catches that before it causes damage, no willpower required.
作者提到的系统思维实践其实和我们写代码加测试的逻辑一模一样：你不能只修复当前遇到的 Bug 就完事，你得加个测试用例，保证下次其他人改代码的时候，同样的问题如果再出现会被自动拦住。流程也是一样的，你遇到了某个共性问题，就得把解决方案固化成所有人都要遵守的规则，就算整个团队的人都换了一遍，这些沉淀下来的流程、文档、代码规范、决策记录，依然能保证项目正常运转。比如要求所有决策都留书面记录、强制代码评审、PR 流水线自动跑检查和测试、禁止使用语言里危险的特性、要求所有改动都加测试——这些看起来麻烦的规则，本质上都是在把「避坑」这件事自动化，不用指望每个人都足够自律、足够细心，只要规则足够完善，能通过规则检查的代码下限就不会太低。
Of course, introducing these systems will almost always face pushback, and the author shares a very relatable anecdote about that. His team had recurring performance issues in a React app from missing memoization, so they proposed a simple rule: memoize everything returned from hooks by default. One engineer pushed back hard, citing "premature optimization" and the lack of this recommendation in React docs, but the author’s take was that this engineer actually wanted to keep being the go-to expert who fixes these tricky memoization bugs every time, which gives him job security. That’s a really uncomfortable truth to face: for people who benefit from being the only one who knows how parts of the system work, process changes that demystify that work feel like a threat.
其实说到底，这篇文章不是说个人能力不重要，个人效率当然值得鼓励，但我们不能把团队的命运赌在少数人的能力和责任心上面。不然你就会遇到产出质量忽高忽低、交付预期永远不准、核心员工一走项目就崩盘的问题。我自己也见过不少团队，平时天天捧着几个核心开发，什么疑难杂症都丢给他们，等这些人一离职，整个团队要花好几个月才能缓过来，很多历史代码甚至没人敢动。反而是那些看起来流程有点「死板」的团队，人员流动从来不会伤筋动骨，每个人来了都能按流程快速上手，长期走下来反而走得更稳更快。不知道你们有没有遇到过这种「团队依赖某个英雄」的情况？你们又是怎么解决的？
