团队最依赖的人,往往不是最优秀的那批。
做过芯片的都懂,一个项目能按时Tape-out,靠的不仅是某个天才架构师,而是那群默默写RTL、跑验证、调timing的普通工程师。问题在于,这些人里总有那么几个——代码写得像屎山,bug修了又冒,进度永远delay,但你就是开不掉他们。
为什么?因为他们掌握着项目的历史包袱。
举个例子,某个模块的clock domain crossing逻辑,当初设计时为了赶进度,加了一堆workaround。现在只有小王知道哪些信号不能动。小王干活拖沓,写的代码reviewers看了想骂娘,但你敢让他走?或者有必要？
// 小王写的代码,注释都没有 always @(posedge clk) begin if(rst) data_reg <= 0; else if(en && !busy && flag1 && !flag2) data_reg <= data_in; // 为什么要这么多条件?没人知道 end这种依赖关系,本质上是技术债转化成了人员债。当系统复杂到一定程度,换人成本会变高。培养一个新人熟悉整套verification flow,起码三个月。三个月里谁来cover那些regression fail?谁来fix customer发现的silicon bug?
更讽刺的是,这些平庸者往往活得很滋润。他们知道自己的价值不在能力,而在不可替代性。所以会刻意把知识藏着掖着,文档能不写就不写,关键代码故意搞复杂。管理层也心知肚明,但能怎么办?项目deadline摆在那里。
根本解决方案只有一个:从一开始就建立可维护的系统。代码review不是走形式,architecture document必须详细,critical path的设计决策要有trace。但现实是,大部分公司都在用”先跑起来再说”的开发模式,等技术债堆成山,人员债也就随之而来了。
很多优秀的工程师,早被大厂高价挖走。留下的团队,能保证产品不出大问题已经不错,还指望什么创新突破?
所以下次看到那个总是delay、代码又烂的同事,别只顾着生气。想想是不是项目架构本身就有问题,是不是知识传承机制根本没建立起来。
依赖平庸者不是选择,而是系统性失败的症状。
 的巧妙用法)
