那个准点下班却产出3倍的程序员
那个准点下班却产出3倍的程序员
你的团队里有没有这样一个人——每天准点下班，周末从不加班，但季度review的时候，他交付的功能数量是你的三倍。
你偷偷观察过他。没有机械键盘加持，不喝功能饮料，甚至打字速度看起来都不快。你一度怀疑他半夜偷偷干活，直到有一次你俩一起被拉去救火，你才发现——他花了40分钟在白板上画图和翻代码库，而你已经噼里啪啦写了200行。结果呢？你的200行在code review时被打回来重写，他40分钟后动手，一次过。
这就是所谓”10倍工程师”的真相。但真相跟大多数人想的不一样。
10倍差距，不在手速
“10x工程师”这个说法最早来自1968年的一项研究：同一个编程任务，最好的程序员和最差的程序员之间，效率差了10倍以上。这个数字被传了半个世纪，传着传着就变了味——好像存在一种”超级程序员”，他们打字如飞、算法信手拈来、一个人能干一个团队的活。
但你冷静想想就知道不对。人的打字速度撑死差两三倍。算法再厉害，日常工作里用到红黑树的时候有几个？技术栈再多，同一时间也只能用一种。
实际的研究数据挺打脸的。高效工程师和普通工程师在”纯编码速度”上的差异，不到2倍。你用2小时写完的函数，那个大牛可能用1个半小时——就这点差距，远远凑不出10倍。
那10倍差距到底从哪来的？
答案藏在一个你可能不想承认的地方：不是你写得慢，是你写的东西有一半不该写。
写得少，反而产出多
微软研究院做过一次内部数据分析，结论相当反直觉：排名前1%的工程师，写的代码量比团队平均水平少20%左右。但他们的代码被revert的比例低了90%，引入的bug少了85%。
少写20%，少出90%的废代码。这意味着什么？
想象两个工程师同时接到任务。你一周写了1000行代码，热火朝天。但其中300行后来删了——方向跑偏了，需求理解错了，跟已有代码撞车了。
那个”大牛”呢？一周只写了500行。但几乎一行不用改。
表面上看，你写得多。实际一算？你花了1300行的工夫（写1000+改300），产出700行。他花500行的工夫，产出500行。你的时间有一小半喂了垃圾桶。
这还只是”返工”这一层。再往上算——code review来回、改bug、集成冲突——差距轻松拉到3到5倍。
最狠的是方向选择。他做的那500行，恰好是最该做的事。你的700行里，有200行做了个最后被砍掉的功能。一加一减，10倍就到了。
射箭还是扫射？
打个比方你就懂了。
普通射手对着靶子射100箭，中了10箭。高手拿起弓，射了10箭，中了9箭。
你去问普通射手：”怎么提高成绩？”他的第一反应是——射更多的箭。”我一天射200箭，总能多中几个吧？”
但高手的策略完全不同。他不是射得更多，是每一箭都瞄得更准。他花大量时间在拉弓之前——站位对不对？风向什么情况？靶子有没有看清楚？等所有条件就绪了，才松手。
编程是一模一样的道理。差距不在力气，在准头。力气指的是编码量，准头指的是判断力。
你见过那种程序员——需求一下来，啪啪啪就开始写代码，写到一半发现理解错了，推翻重来；又写到一半发现有个边界条件没考虑，又推翻一部分。三天下来写了2000行，最终留下来的只有600行。
而那个”10倍工程师”呢？需求下来，他先花半天跟产品经理对齐：”这个功能的核心用户是谁？”“最关键的场景是哪个？”“有没有历史代码能复用？”问完这些问题，他打开IDE的时候，脑子里已经有了完整的方案。写出来的代码，就像GPS导航一样，直奔目的地，不绕路。
三个你明天就能抄的习惯
说到这里你可能想问：这种”准头”到底能不能学？还是只有天选之人才有？
答案可能会让你松一口气——判断力不是天赋，是习惯。习惯这东西，谁都能养。以下三条，是我观察那些持续高产出工程师后提炼出来的共同模式。
第一，动手前先花30%的时间想清楚。
具体怎么做？拿到需求后，别急着打开编辑器。先花30分钟到1小时做三件事：画一张简单的架构草图（纸上画就行）、写一段伪代码跑一遍核心逻辑、找一个同事花10分钟讲一遍你的方案。
这三件事能帮你发现80%的”方向性错误”——而方向性错误一旦到了编码阶段才发现，返工成本是前期的5到10倍。前面花1小时想清楚，后面省5小时改代码。这笔买卖太划算了。
第二，读代码比写代码多。
大部分程序员的时间分配是：80%写代码，20%读代码。高效工程师恰好反过来。
为什么？因为一个成熟项目里，你要做的事大概率已经有人做过类似的了。那个”轮子”可能藏在某个utils文件里，可能是某个同事三个月前写的一段逻辑，也可能是一个已有的内部库。你不读代码，永远不知道这些东西存在，然后你就高高兴兴地重新造了一个轮子——还可能造得没人家好。
读别人的代码还有个隐藏好处：你会吸收别人的设计思路。看得多了，你自己设计方案时就会自然避开很多坑。这比看任何技术书效果都好，因为那些代码跟你的项目是同一个上下文。
第三，会说”不”。
这是最难的一条，也是差距最大的一条。
普通工程师接到任务就开始做。老板说”加个功能”，做。产品说”改个交互”，改。设计说”调个颜色”，调。一天下来忙得团团转，但做的事里有一半是低价值甚至无价值的。
高效工程师会在动手之前问一个问题：”这件事不做，会怎样？”如果答案是”也没什么大不了”——那这件事的优先级就应该往后排，甚至直接砍掉。
我见过一个真实的例子。产品经理提了一个”用户头像支持动态GIF”的需求。普通工程师接到就开始调研技术方案。而团队里的那个高手，先去查了后台数据——过去一年上传头像的用户中，自定义头像的不到8%。他花了5分钟写了封邮件把这个数据丢给产品经理，这个需求当天就被撤了。
他用5分钟省了别人两周的活。这不叫偷懒，叫判断力。
他们最大的超能力不是”做得快”，而是”判断出什么不值得做”。省下来的时间投入到真正有价值的事情上，一进一出，产出差距就这么拉开了。
10倍不在速度，在方向
回到开头那个场景。那个每天准点下班、产出还是你三倍的同事，不是什么天才程序员。
他只是在你打开编辑器噼里啪啦敲代码的时候，先花了一小时确认自己要写的是对的东西。他做完了就是做完了，你做完了后面还有一堆返工在等你。
10倍的差距不在打字速度，不在算法能力，不在技术栈数量。
在于他射箭之前多瞄了几秒钟。就这几秒钟，值10倍。