Stop Chasing 10x Developers: Building Robust Systems Beats Relying on Individual Heroics / 别再追捧「十倍效率程序员」了：搭建可靠系统远胜于依赖个人英雄主义
I recently came across a thought-provoking piece about team management in enterprise software development, and its core argument really struck a chord: the most successful teams don't bet on star individual contributors to carry the project—they build systems that make consistent performance almost automatic, no matter who is on the team. It's easy to get impressed by those viral videos of construction workers or craftspersons performing their jobs at superhuman speeds, right? We see them finish a day's worth of work in a few hours and immediately think we want someone like that on our team. But what happens when that person gets sick, quits, or moves to another project? Suddenly the entire workflow grinds to a halt, because the efficiency was tied to one person, not the process itself.
在企业级项目里，这个问题会被无限放大：如果团队的交付速度、代码质量全靠一两个「明星程序员」撑着，那项目从一开始就埋下了巨大的隐患。管理者可能会基于这些人的超常产出制定进度计划，一旦他们离职，之前承诺的交付节点就全部成了空谈，留下的代码如果只有他们自己能看懂，后续接手的人光是梳理逻辑就要花上几倍的时间。更不用说人总会有状态差、失误的时候，哪怕是最细心的程序员，也可能不小心把有问题的代码直接推送到主分支——靠人的自觉性来规避风险，本质上就是在赌小概率事件不会发生。
The article makes a great point that a good system isn't just a set of rigid rules to micromanage people—it's a safety net that accounts for human fallibility. For example, instead of just telling your team not to push directly to the master branch, you can configure the repository to automatically reject all direct pushes, only allowing changes through reviewed pull requests. That one simple rule eliminates the risk of accidental pushes entirely, no matter how experienced or careful the developer is. It's the same logic as writing tests for your code: when you fix a bug, you don't just patch the specific instance, you add a test to make sure that same bug never comes back, even if a completely different developer touches that part of the code later.
放到流程设计里也是一样的道理：一个健康的系统应该能做到，就算把整个团队的人都换掉，项目依然能稳定运行下去。这就要求所有的工作产出都要是可沉淀的资产——不只是代码，还有文档、决策记录、规范手册，把之前踩过的坑、总结的最佳实践都固化到流程里。比如要求所有技术决策都要有书面讨论记录，所有性能优化主张都要有实际测试数据支撑，用严格的代码检查工具把危险的语法特性直接禁用，强制所有提交都要经过代码评审，而且评审人要对代码质量负责。这些规则看起来好像有点繁琐，会拖慢一点速度，但长期来看反而能减少大量反复踩坑、排查低级错误的时间，让整个团队的产出更稳定。
Of course, introducing these system-focused processes isn't always easy. The article mentions that some team members might push back against these changes, especially those who have benefited from being the "only person who understands how X works"—their job security relies on the system being opaque and dependent on their individual expertise. I've seen this happen firsthand too: a team might resist adding a simple automation rule that would eliminate a whole category of recurring bugs, arguing that it's "unnecessary overhead" or "not how everyone else does it", when the real underlying concern is that it would take away their unique value as the person who always fixes that specific issue. At the end of the day, prioritizing systems over individuals doesn't mean we don't value great developers—it means we build teams where great work is the default, not the exception that only happens when a specific person is around.
