“10 倍工程师”,以一当十的程序员真的存在吗?

2019 年 7 月 16 日

“10 倍工程师”,以一当十的程序员真的存在吗?

本文最初发布于 Jason Crawford 个人博客,经原作者 Jason Crawford 授权由 InfoQ 中文翻译并分享。


导读: “有些工程师能以一当十,创业如果有幸有这号人加盟,那么成功率就能够大幅提升。”自投资人 Shekhar Kirani在 Twitter 抛出这一观点来,引发了极大的讨论,有人赞同,但更多的人却是反讽。截止小编翻译此文时,原始推文已经有1500多条讨论,1300多次转发和4300多点赞:

今天,Jason Crawford也参与了这一场讨论,分享了他对10倍工程师的看法。


今天 Twitter 上有好多人在讨论 10 倍工程师。


是否存在所谓的 10 倍工程师呢?这个“10 倍工程师”到底是什么意思呢?


这个话题引起了人们激烈的口水战,因为它触及了深刻的意识形态话题:是不是有些人比其他人更有才华,为什么是这样(以及它是天生的还是后天努力的),如果是这样,我们又该如何对待他人。因此,社交媒体上就爆发了激烈的争吵:一方面,人们都说 10 倍工程师是一个神话,一切都源于刻板印象,而且不管怎样,难道就没有更重要的事情?比如是否可以编写文档、指导其他工程师,或者仅仅只是做一个好人?另一方面,人们翻着白眼说,当然有 10 倍工程师了。任何不承认这一明显事实的人都被社会正义宣传蒙蔽了双眼,或者是不愿承认自己低人一等的失败者。


让我们现实一点儿吧。首先,让我们来做经验分析。


关于这项研究应该知道什么


对于这个概念及其基础的最好解释是 Steve McConnell 的文章“Productivity Variations Among Developers and Teams: The Origin of 10x”(《开发人员和团队之间的生产力差异:10 倍的起源》)。一下是关于“10 倍工程师”需要了解的关键事项:


  • 10 倍指的是最好的开发人员和最差开发人员之间的差异,而不是最好的开发人员和一般开发人员的差异。 这会有很大的不同。在我看来,更容易相信最好的开发人员要比一般开发人员的水平高出三倍,而最差的开发人员要比一般开发人员的水平低三倍左右。这样,就可以得到 10 倍的总范围。(请注意,谈论“0.5 倍工程师”是没有任何意义的,因为根据定义,最差的开发人员是 1 倍。)


也许我们应该重新定义“x”为平均值,把最好的工程师称为“三倍工程师”,然后就结束这场争论?


  • 10 倍的概念是基于研究提出的,但研究并不完美。 在上面的链接中,McConnell 描述了已完成的研究(如果你想深入了解,还可以看看这篇评论McConnell 的反驳)。我们有理由对这些研究及其与今天的相关性持批评态度:样本量相对较小,而且它们并不总是得到很好的控制。其中一些还是几十年前完成的(第一次是 1968 年),当时计算机、编程语言和开发任务和今天大相径庭。他们有时会使用可疑的生产力指标,例如每天的代码行数,但他们也使用很好的指标,比如完成时间,在某些情况下,代码行被认为是负面的(对于给定的任务,代码行数越少越好)。


总体而言,我认为,有明显的证据表明,个人和团队之间,生产率存在很大的差异。


  • 10 倍是个粗略的平均值。 不同的研究和测量发现了不同的范围,一般在 5 倍到 25 倍之间。再加上刚才讨论的研究的局限性,则意味着我们只能粗略地说“大致数量级”。所谓的“10 倍”并不精确;它只是一种简练的方式,用来记住生产力的差异是存在的,并且差异巨大。

  • 这些研究,只针对那些实际完成任务的开发人员。 他们的数据并没有考虑到那些没有完成任务的人(在一些研究中约占 10%)。他们也不能考虑到软件的真实成本,这些软件名义上已经开发完成,但漏洞百出,缺陷太多,或很难维护,以至于不得不由其他人重写。这甚至还没有提到软件缺陷造成的损失,这些缺陷影响了公司的销售,使公司蒙受损失,甚至将生命置于危险之中。不过,所有这些因素只会强化这一基本观点。

  • 10 倍的数字仅与工程生产率的具体衡量指标有关。 它并不是为了完全捕获一个工程师对一个组织的价值,也不能用于这个目的。尽管如此,这些仍然是有意义的、重要的措施。

  • 据我所知,这些研究并没有解决造成这些差异的原因。 至少,McConnell 的调查并没有涉及以下重要问题:一个人的生产力水平会随着时间的推移而保持稳定吗?它是否因环境而异?工作环境对生产率的影响有多大?它是否随任务的不同而随机变化,是否取决于某个特定的“顿悟”时刻的运气?它会随时间增长吗?它可以学习或者可以教授吗?(他说,1968 年的最初研究发现,“程序员的经验与代码质量或生产率之间并没有任何关系”,但这并不意味着生产力不能随着时间的推移而增长,只是它并不一定会增长。)


我所相信的


以下是我的想法,不仅基于研究,还基于我自己的轶事经历和个人世界观:


  • 生产力的差异是真实的、巨大的、重要的,而且可能被低估了。 如果差异不是“10 倍”,那么它就足够重要了。我相信这一点部分是因为研究,但部分是因为这种现象比软件要广泛得多。McConnell 自己指出了这一点,引用了 Norm Augustine 的一项研究,“发现在各种职业中,如写作、足球、发明、警察的工作和其他职业,前 20% 的人产生了大约 50% 的产出,无论产出是触地得分、专利、破案还是软件。”

  • 工作环境很重要。在现实世界中,重要的生产力受到工作环境的强烈制约。工程师是否有明确的目标和优先级?他们会买账吗?他们有动力吗?他们彼此信任吗?还有,他们信任管理层吗?他们可以集中注意力吗?他们会参加会议吗?还是在生产环境中扮演“救火员”的角色?他们有良好的基础设施和工具吗?等等。

  • 生产力是天赋和后天技能的结合。 也就是说,它是可以部分地学习的。获得的技能包括一系列的东西,从特定的调试工具到一般的思维模式和解决问题的方法。这些天赋与我们不能(或还不知道如何)识别和交道的智力和其他思维模式有很大的关系。

  • 生产力与经验并没有很强的相关性。 有很多高产的初级工程师,也有非常平庸(甚至更槽糕)的高级工程师。因此,即使生产力是可以学习的,这种学习也不会自动发生,甚至在我们的行业中也不会经常发生。很少有人教授如何提高生产力的技能,那些能够独立学习这些技能的人,也是那些一开始就很优秀的人们。


那又如何?


10 倍的争论到底是关于什么的?这个问题的情感影响在于,它对我们如何招聘、如何奖励员工以及我们如何对待个人产生影响。


以下是我的结论:


  • 招聘很重要。 努力吸引、发现和留住最优秀的人才。

  • 环境很重要。 努力营造一个良好的工作环境,如果你发现生产力方面的普遍问题,那可能就是环境的问题。

  • 奖励生产力。 一个人创造的越多,他就赚的越多。

  • 但是,不要认为生产力是与生俱来的。 在一个环境中生产力低下的人,可能在另一个项目中或在另一个团队或公司中,生产力更高。在解雇某个人之前,先要确认这个问题。

  • 培训工程师的生产技能。 我还不知道这样做能有多大的效果,但我认为,我们作为一个行业,甚至没有在这方面进行尝试(我也把自己包括在内)。

  • 生产力不能为不良行为开脱。 这个应该是不言而喻,大家都明白的道理吧。


而且也没有什么特别的技巧可以“找到”“10 倍工程师”(尽管引发当前讨论的推文很奇怪、很可笑)。“10 倍工程师”并不是什么精灵或者妖精,你不可能通过他们所用终端的颜色、所用键盘上的磨损程度或者其他任何的刻板印象来识别出他们。



这是我用了 6 年的键盘。我想我唯一经常做的就是拷贝。我保证它并不总是来自 Stack Overflow。


作者介绍:


Jason Crawford,目前在 Flexport 任技术经理。曾任 Fieldbook 联合创始人兼 CEO,Fieldbook 是一家主打电子表格数据库的公司(类似 Airtable)。同时还是博客 The Roots of Progress 的博主。此前,还正在 Amazon 和 Groupon 担任团队负责人,并在其他几家初创公司担任联合创始人或早期员工。很久之前,曾帮助 D.E.Shaw Research 制造了一台生物技术超级计算机。


原文链接:


“10x engineers”: Stereotypes and research


2019 年 7 月 16 日 16:2611622
用户头像

发布了 324 篇内容, 共 119.8 次阅读, 收获喜欢 800 次。

关注

评论 4 条评论

发布
用户头像
在公司工作这么多年,浑水摸鱼的实在是太多了,如果能拥有这样的10倍程序员那就倍加珍惜吧。
2019 年 07 月 17 日 08:51
回复
人不是机器,总会有疲惫和状态不好的时候,不可能随时保持10倍的状态.
2019 年 07 月 17 日 16:20
回复
用户头像
极客时间上有个10x程序员的专栏:https://time.geekbang.org/column/article/84185
2019 年 07 月 16 日 20:00
回复
知道了,咋不直接文末加一个呢?
2019 年 07 月 16 日 22:28
回复
没有更多评论了
发现更多内容

第一周总结

changtai

极客大学架构师训练营

食堂就餐卡系统设计(第一周)

架构培训-01学习总结 如何成为架构师

刘敏

我不想做一个架构师

彭灵俊

极客大学架构师训练营

架构师训练营0期第一周

Blink

架构训练营0期总结--第一周

互金从业者X

食堂就餐卡系统架构设计文档

changtai

极客大学架构师训练营

软件架构学习记录

八两

第 1 周食堂就餐卡系统设计

陆不得

架构视图学习总结

uangguan

第一周作业--架构设计文档

CP

什么叫架构师

平淡人生

极客大学架构师训练营

食堂就餐卡系统设计

Acker飏

极客大学架构师训练营

架构视图

uangguan

作业一:食堂就餐卡系统设计

Coder

极客大学架构师训练营

第 1 周作业 - 食堂就餐卡系统设计

张小小的席大大

编译运行Zookeeper源码

CoderLi

Java zookeeper 程序员 源码分析 后端

聊聊架构师

Jerry Tse

随笔杂谈 极客大学架构师训练营 作业

Week01 总结

一黑到底

作业一:食堂就餐卡系统设计

JI

极客大学架构师训练营

第一周-学习总结

JI

极客大学架构师训练营

关于架构师这个角色的感悟

祝好

作业一:食堂就餐卡系统设计

独孤魂

极客大学架构师训练营

食堂就餐卡系统设计

ruettiger

「架构师训练营」20200606作业一:食堂就餐卡系统设计

极客

极客大学架构师训练营 食堂就餐卡系统设计

第一周作业-食堂就餐卡架构设计

molly

极客大学架构师训练营

第一周学习总结

架构师训练营-第1周命题作业

红了哟

本周学习总结

ruettiger

Wireshark的使用与数据分析(二)

姬翔

架构师训练营-第一周-食堂就餐卡UML

人世间

极客大学架构师训练营 UML

“10 倍工程师”,以一当十的程序员真的存在吗?-InfoQ