Stop Betting on 'Star Developers' – Why Reliable Systems Beat Individual Brilliance / 别再迷信“明星开发者”：为什么可靠的系统比个人才华更重要
I recently came across a thought-provoking piece about enterprise software development, and it hit on a truth we’ve all probably seen play out at least once in a tech team: how easy it is to get distracted by that one standout engineer who seems to fix every bug and ship features twice as fast as everyone else. The author makes a really compelling case that this kind of “hero culture” is actually a trap for long-term team success, no matter how impressive those individual feats look in the moment.
我们大概都在团队里见过这样的场景：某个技术大牛出手就能解决别人卡了好几天的问题，所有人都习惯了遇到难题就找他，仿佛他是整个项目的“定海神针”。但这篇文章戳破了这种模式的隐患：如果哪天这位核心成员离职了，整个项目是不是就直接停摆？很多时候我们把个人能力当成了团队的护城河，却忘了人本身就是最不可控的变量——会倦怠、会跳槽、会生病，把项目成败赌在少数人身上，本质上就是给自己埋了个定时炸弹。
The author’s definition of a good system really stuck with me: it’s not just a list of rigid rules to follow, but a framework that accounts for the fact that every person is fallible. We all make typos, have off days, or forget a step in a complicated process, so the best systems are designed to catch those mistakes before they cause problems, instead of assuming people will never mess up. Things like blocking direct pushes to the main branch, mandatory code reviews, and automated test pipelines aren’t red tape to slow people down – they’re safety nets that let everyone work more confidently, no matter their skill level.
其实这套思路和我们写单元测试的逻辑是一模一样的：你发现了一个bug，光修复它本身还不够，得加个测试用例确保以后不会再有人踩同样的坑。系统建设也是这个道理，遇到问题不要只想着“这次找个厉害的人解决就行”，而是要把解决方案沉淀成流程、文档、自动化工具，就算以后整个团队都换了新人，照着这套系统走，也能产出稳定的质量。那些看起来“死板”的规则，比如强制静态类型检查、禁止使用危险的语法特性、要求所有变更都补测试，本质上都是在把人为犯错的空间压到最小，根本不需要指望所有人都是不出错的“大神”。
Of course, the author also acknowledges that rolling out these systems isn’t always smooth sailing. Some team members might push back, because being the only person who knows how to fix certain problems gives them job security. He shared an anecdote about a React project they worked on, where they tried to introduce a simple rule to memoize all hook returns to prevent frequent re-render performance issues. One engineer pushed back hard, citing “premature optimization” and lack of official React recommendations, but the author suspected the real issue was that this engineer enjoyed being the go-to person to fix those re-render bugs every time they popped up.
这其实也给团队管理者提了个醒：鼓励个人成长和搭建系统流程从来都不矛盾，我们可以欣赏甚至奖励优秀的个人表现，但绝对不能把个人能力当成团队的依赖。好的系统会让普通人也能做出靠谱的成果，而坏的模式只会把所有压力都堆在少数人身上，最终要么把人逼走，要么等出了问题才发现根本没人能补位。说到底，我们做技术团队建设的目标，从来不是养出一两个不可替代的“英雄”，而是打造一个离开谁都能照常运转的、靠谱的系统。
