Stop Chasing 10x Programmers: Build Systems That Outlast Any Team Member / 别再追逐「十倍效率程序员」了：搭建能比任何团队成员走得更远的系统
I recently came across a thought-provoking piece on tech team management that made me pause and rethink a lot of assumptions we hold about "star performers" in programming teams. How many times have we heard stories of that one legendary engineer who can fix any bug in half an hour, or ship a feature that would take the rest of the team weeks to build? It feels like every tech team has that "hero" everyone relies on, and we usually see that as a good thing — but this article argues that relying on those heroes is actually one of the biggest risks to a project's long-term success.
我们其实都见过这类「英雄员工」带来的隐性问题：如果哪天核心开发跳槽了，整个项目就停摆，新接手的人根本看不懂他写的「魔法代码」，之前靠着他的能力能完成的交付承诺全都会落空。文章里的一个比喻特别戳人：就像工地上有个工人能徒手把砖切得又快又准，看起来效率极高，可如果他突然离职，其他人根本做不到同样的速度，整个工期都会受影响。问题根本不是这个工人不够优秀，而是整个工作流根本没有标准化，全靠个人能力在托底。
The core idea here is that systems work because they account for human fallibility. We all make mistakes — we might accidentally push broken code to the main branch, forget to test an edge case, or have an off day where our work isn't as sharp as usual. A good system doesn't demand that everyone be perfect all the time; it puts guardrails in place to catch those mistakes before they cause problems. For example, instead of trusting every developer to never push directly to master, you set up branch protection rules that force all changes to go through a pull request with reviews and automated tests. It doesn't matter how senior or skilled an engineer is, the rule applies to everyone, and that's how you eliminate preventable errors.
文章里提到的系统搭建思路其实和我们写测试的逻辑一模一样：你发现一个bug之后，不能只把这个bug修好就完事了，你得加一个对应的测试用例，保证以后不管谁改代码，只要再触发同样的问题，测试就会报错。放到团队流程里也是一样，每次遇到一个共性问题，你要做的不是骂这次犯错的人，而是把解决这个问题的方法固化成流程，让以后所有人都不会再踩同样的坑。好的系统甚至能做到哪怕整个团队的人都换了一遍，项目依然能稳定运转，因为所有的决策逻辑、技术规范、踩过的坑都沉淀成了文档、规则、自动化流程这些可复用的产物，而不是存在某几个人的脑子里。
Of course, building these systems isn't always easy, and you will likely face pushback from some team members. The article shares a telling anecdote about a React team that wanted to implement a simple rule to memoize all hook returns to fix recurring re-render performance issues, but one developer pushed back hard, citing "premature optimization" and "React docs don't recommend it". The author argues that this pushback often comes from people who benefit from being the "go-to expert" for certain problems — if you implement a system that prevents those problems from happening in the first place, that person loses their unique value to the team. It's an uncomfortable truth, but a good system should make every role replaceable, not create gatekeepers who hold the project hostage to their specific knowledge.
这篇文章最让我认同的一点是，它不是说个人能力不重要，而是说你不能把团队的成功赌在个人能力上。你可以鼓励优秀的开发者发挥自己的能力，给他们更好的回报，但你永远不能默认「这件事只有他能做」。比起花大价钱挖一个十倍效率的程序员，不如花精力搭建一套能让普通开发者也能写出高质量代码的系统，这才是团队能长期稳定产出的核心。毕竟，没有谁会在一家公司待一辈子，但好的系统，能陪着公司走很久。
