【译】你是“10倍效率”JS开发者吗?

原文链接:Are You A 10x JavaScript Developer?

作者:Dor Tzur

翻译:野草

校对:墨白

本文首发于前端早读课【第832期】

相信大家都听过“10倍效率”开发者。如果你没听过,或许也是件幸运的事。

开发界有传言,有些开发者效率之高堪比同水平开发者的10倍,在团队里甚至可以以一抵十。

不过,我们大多数人会把“10倍效率”开发者和以下这三种奇葩联系起来:

  1. 才智过人的天才: 天赋异禀却蔑视众生,这样的人即使很能干,也没人愿意和他合作。
  2. 自以为是的庸才: 他们毫无依据地坚信他们就是“10倍效率”开发者。通常这是因为他们与生俱来就高傲,知识面又狭窄造成的。
  3. 奇葩管理者:宣称只雇佣“10倍效率”开发者,并且团队里全部都是“10倍效率”开发者(请问参照物呢?)。 如果你在面试中遇到这种奇葩,那你可要小心了。

即使“10倍效率”开发者似乎臭名昭著,仍然有几个问题在我脑海中挥之不去。

“10倍效率”开发者真的存在吗?我是其中之一吗?如果不是,我怎么做才能成为“10倍效率”开发者呢?

笔者将尝试在本文中回答这些问题,顺便也说下成为“10倍效率”开发者是否就是万无一失了。

“10倍效率”开发者之真假

我还是得告诉你们这个残酷的事实,“10倍效率”开发者,毋庸置疑,的的确确,千真万确,是存在的。

你是不是觉得你要抓狂了?不过,但你抓狂之前,你要记住:不是每个刚从编程训练营出来的小菜鸟都是“10倍效率”开发者。

举个栗子。有个叫Jeff的小子自以为什么都懂,即使在写团队的基础架构代码的时候也从来不和人沟通交流。那根本算不上“10倍效率”,尤其是在他的代码出bug的时候,没人知道他写的那堆是什么鬼。

我不在乎Jeff开发速度多快,因为这样的开发方式最终拖了团队的后腿,摧毁了我美好的周末。我不喜欢Jeff。

“10倍效率”开发者背后的研究

我知道我们生活在一个事实并不重要,美国总统可以是川普(美国在搞什么鬼)的荒诞环境下,但我仍然相信事实胜于雄辩。让我们来弄清楚“10倍效率”开发者到底是怎么回事。

“10倍效率 ”开发者这种说法起源于1968年的研究。研究人员让开发经验和水平相近的开发者同时编码和调试相同的问题,并且进行了计时。研究发现,即使算上了人工操作中的测量误差,最好和最差的开发者表现可以差10倍之多。

我们知道人与人之间的差距的确存在。这些研究是被后人反复不断重现的验证下得以确认的。

如果你愿意,你可以延伸阅读这篇文章validity of the underlying reaserch

你可能是“10倍效率 ”开发者吗

我想你先停下来,思考一下你遇到过的最坑最渣的开发者。我们暂时叫他Jim吧。

你曾经觉得和Jim一起工作,面试他或者跟他交流是件很愉快的事。不管你是怎么认识Jim的,用不了多久你发现他根本就不知道自己在说什么。

你说一个工作经验7年多的JavaScript开发者怎么会不知道Promise是什么?想想都觉得这是件很神奇的事情。

亏他还在简历上写着是JavaScript面向对象编程专家,连什么是原型链继承都不清楚。不说什么语法啊或者实现啊,他甚至连概念都不清楚。

比起Jim,我觉得我们都可以自称是JavaScript“10倍效率 ”开发者了。

你可能不是“10倍效率 ”开发者吗

JavaScript开发者没有NBA比赛,即使那样会很酷。

我们很难用统一的标准去衡量开发者的水平,当然Nike也没有给我们赞助代言。开发不像运动,有积分系统,而且不同公司不同项目之间的“得分规则”也截然不同。

但是综合考虑,还是有那么一些超牛逼超高效的大神,牛逼到让人怀疑人生。

像其他方面的能力一样,在开发方面,有些人就是天赋异禀,但这类人往往凤毛麟角,我们这辈子可能都遇不到一个。

但是在JavaScript开发领域,不是谁最高效谁就能成为大V,我们没有评分系统。(除了Github star的数量,可以说它是我们在这个世界上存在价值的唯一衡量标准了。)

开发不是体育竞技,github能否得到star不是根据我们debug代码多快,或者一个小时内关闭issue的个数有多少决定的。

真正重要的是我们优秀的开发者做出来的东西,以及他们做事的方式。

让我们开始关注什么是真正重要的事情吧。

忘记“10倍效率”,关注真正重要的

先说个小故事。Molly和Magen都在Jerald手下做事。Molly的开发速度在团队里最快,每每Jerald交给她一个项目,他很清楚他最后能拿到什么。Molly干活很卖力,也很准时,偶尔还会提前完成。

而当Jerald分配工作给Magen的时候,他知道她也会按时完成,尽管她的工期估计会比Molly长一些。但是,在那些大项目上面,Jerald仍然更信任Magen。

因为Magen有洞察设计缺陷的本领,并且能在项目初期提出来。她能准确地识别并抽取出可共用的部分放入团队的公共基础库中,甚至会建议团队将那些她认为有利于开发社区的东西开源出来。

曾经Magen想要实现团队里讨论过的新的登录框架,她向Jerald多申请了两天的工期去实现。Jerald愉快地答应了,因为他知道这对大家都有利。

每当Jerald遇到他自己也不确定的项目时,他更愿意交给Magen做,因为他觉得Magen很靠谱,而且她的工作能让大家的工作开展更加顺利。

这不禁让我开始怀疑, 我们应该花多少时间和精力在提高效率上。也许,我们更应该问自己“今天我应该学些什么才能变成更好的JavaScript开发者?”,或者“我应该开发些什么才能真正促进团队发展?”

我觉得去认真思考这些问题,你的时间才用得其所。我确信你会因此变得专业很多。

那么最后你更愿意成为谁,Magen还是Molly?

掌握主动权

我们尽善尽美地完成份内之事,实现我们的价值,这也是我们作为开发者的特权。

如果我们能后退一步,用更大的全局观去理解项目,能主动做没人要求我们做的事情,甚至能告诉团队“我觉得我们需要这个,我正打算去做。”,我们就能最大程度地发挥我们的价值。

当然最难最关键的部分,在于坚持。

当我们决定要开发探索性的项目时,或者当主动权在我们手中,我们去决定开发什么,我们总显得有点忐忑不安。但就是这个时候,才是你真正地在做一些东西的时候。

再说个小故事。几年前,在Facebook工作的Jordan Walke在开发工作中遇到了刺手的问题。即使他尝试了开发中所有的最佳实践,现成的工具库都不能很好地解决他的问题。于是,他决定尝试新的东西。

他打算借鉴PHP库一个听起来有点别扭的概念,这个库当时在facebook已经得到了很好的实践应用,只是JavaScript中根本没类似的概念。为此,他极力给自己争取到了开发的时间。

最后,Jordan创造了一个非常赞的轻量级库。经过了内部广泛的使用之后,Facebook决定将它开源。

它就是React。

所以,你觉得会有人在乎Jordan的调试速度有多快?还是他关闭issue的速度有多快?反正我不在乎。

但我确定我大爱React。

最后,附上一句名言。

想象远比知识重要。因为知识是有限的,但想象力却能推动着进步,孕育着变革,从而影响全世界。 ——Albert Einstein