Stop Betting on 'Superstar' Developers – Build Systems That Outlast Any Team Member / 别依赖“明星”开发者：搭建能脱离任何人稳定运行的技术体系
I recently came across this thought-provoking piece about enterprise software development, and it hit on a pain point I bet almost every tech team has run into at some point: we love celebrating the 10x engineer who can fix a production outage in 10 minutes or ship a complex feature in half the estimated time, but we rarely talk about how dangerous it is to build our entire workflow around those individual heroes. The author makes a really solid point: the core goal of enterprise programming isn't to showcase individual brilliance – it's to manage complexity, minimize bugs, scale reliably, and ship consistently. None of those goals are sustainable if your whole team's output relies on one or two people keeping all the context in their heads.
我之前待过的一个团队就踩过这个大坑：当时团队里有个核心开发，对整个项目的底层逻辑熟到闭着眼都能改代码，每次出问题他半小时就能搞定，所有人都觉得有他在特别省心。结果他突然跳槽了，接下来的三个月我们整个团队乱成一锅粥：之前只有他能改的模块没人敢动，出了小问题都要排查好几天，本来排好的需求直接延期了快两个月。现在回头看，那根本不是他能力强的功劳，是我们整个团队的流程体系出了问题：我们没有把他脑子里的经验沉淀成文档，没有做强制的代码规范和评审，也没有自动化的检查机制，相当于把整个项目的风险都绑在了一个人身上。
The author draws such a clever parallel between process building and writing tests for your code. When you find a bug, you don't just fix the single instance and call it done – you write a test case so that same bug never pops up again, no matter who changes the code later. Processes work exactly the same way: if people keep accidentally pushing broken code to the master branch, you don't just send out a reminder email telling everyone to be more careful – you set up branch protection rules that block direct pushes entirely, no self-discipline required. None of these rules are about distrusting your team, they're about accepting that everyone is human: we all get tired, we all make careless mistakes, we all forget edge cases when we're in a hurry. A good system catches those mistakes before they cause problems, instead of expecting people to never make them in the first place.
文章里提到的很多具体实践其实我们日常都在用，但很少有人把它们上升到“体系建设”的高度：比如强制的代码评审、PR 必须过所有自动化检查才能合并、所有技术决策都要有书面记录、禁止使用太灵活太“聪明”的语法强制大家写直白易懂的代码……这些规则刚推的时候往往会遇到阻力，很多人会觉得麻烦，觉得束缚了自己的发挥，甚至有人会觉得，体系越完善，自己作为“老员工”的不可替代性就越低。但实际上，好的体系反而能解放所有人的精力：你不用再花大量时间排查低级错误，不用再靠记一大堆“不成文的规矩”才能写对代码，哪怕是刚入职的新人，照着流程走也能写出质量合格的代码，所有人都能把时间花在更有价值的事情上。
At the end of the day, building a system isn't about downplaying individual talent. High-performing team members are still incredibly valuable, and we should absolutely encourage and reward individual efficiency – we just shouldn't depend on it. The mark of a truly great team isn't that it has a couple of superstar developers, it's that the team can keep delivering high-quality work even if any single person leaves tomorrow. If your project would fall apart if your top engineer quit, you don't have a strong team – you have a single point of failure.
