Stop Chasing Rockstar Developers: Why Good Systems Beat Exceptional Individuals in Tech Teams / 别再追捧明星开发者：好的系统比优秀个人更能支撑技术团队长期发展
I recently came across a thought-provoking piece that calls out a common trap we often fall into in enterprise tech teams: we idolize the \"10x developer\" who can crank out code at impossible speeds and fix any crisis in 10 minutes, but we rarely stop to ask what happens when that person leaves. There's nothing wrong with celebrating individual skill, of course, but building an entire project around a few exceptional people is one of the riskiest moves a team can make. Those flashy viral videos of construction workers pulling off near-impossible feats look impressive, right? But if that worker gets sick or quits tomorrow, the whole operation slows to a crawl, because the efficiency was tied to that one person, not a repeatable process.
我相信很多团队都遇到过类似的状况：核心开发离职后，项目接连爆出没人能解决的问题，新成员要花好几个月才能摸清楚隐藏在个人脑子里的逻辑，原本稳定的交付节奏直接被打乱。这篇文章戳破了一个很多管理者不愿意承认的真相：把项目进度、代码质量的期望寄托在个人自觉性和能力上，本身就是管理的失职。人的状态是波动的，会犯错、会疲惫、会离职，而一个好的系统，就是为了把这些人为因素的影响降到最低。
The core idea of a system-based approach isn't to create rigid, bureaucratic rules that stifle creativity — it's to build guardrails that prevent avoidable mistakes before they happen. Think about the standard practice of blocking direct pushes to the master branch: no matter how careful a developer is, everyone has had that moment where they almost committed something to the wrong branch by accident. That rule doesn't punish people for being human, it protects them from their own occasional slip-ups. The best systems work invisibly: they don't make good developers work slower, they make it hard for anyone, regardless of skill level, to cause catastrophic damage.
文章里提到的一个类比让我印象特别深：建立流程就像写测试用例，你不能只修完当前的bug就完事，要写一个测试保证下次同样的问题再出现的时候能被自动拦住。很多团队遇到问题只会喊“大家下次注意”，但下次还是会有人踩同样的坑。真正有效的解决方式，是把应对方案固化成流程、工具、文档这些可以传承的资产，哪怕整个团队的人全换了一遍，新成员照着规则走，也能输出稳定的质量。
Of course, pushing for system-based workflows will almost always meet resistance, and it's not hard to see why. For developers who have built their job security on being the only person who understands a certain part of the codebase, a system that makes that knowledge accessible to everyone feels like a threat. The author shares a story about pushing for a simple rule to memoize all hook returns in a React project to cut down on re-render bugs, only to face pushback from a developer who argued it was "premature optimization". When you dig into that kind of resistance, it often comes from people who would rather spend hours fixing the same repeatable problems to look like a hero, instead of eliminating the problem entirely with a simple rule.
最后想说，推崇系统思维并不是要否定个人能力的价值。优秀的开发者当然值得鼓励和奖励，但我们不能把团队的生存寄托在某几个人身上。一个健康的团队，应该是普通开发者按流程走也能输出合格的成果，优秀的开发者能在系统的基础上做出更好的创新，而不是反过来，让少数人拖着整个团队往前走。毕竟，我们做企业项目的目标从来不是培养几个超级英雄，而是能稳定、可持续地交付可靠的产品，对吧？
