一位萌新工程师怎样在工作中快速提升自我价值

几个月前一个新工程师加入了我们的团队。和往常一样，我花了些时间和他相处，来更好地了解他是哪种类型的人、他的驱动力是什么。我们经常讨论过去的经历，但更重要的是：未来的目标。结果发现，他有个有趣的目标：

「我想成为世界上最好的程序员」

野心勃勃。我喜欢。

但是，这让我思考了一个问题：成为“最好的程序员”实际上意味着什么。怎么衡量“好”？怎么知道他（她）是“最好的程序员”？

这让我想起了上世纪 60 年代，Sackman、 Erikson 和 Grant 撰写的论文《Exploratory Experimental Studies Comparing Online and Offline Programming Performance》。该研究的目的是调查程序员在编程的多个方面的表现，无论他有电脑——那时是主机——的交互权限还是用“纸和笔”高效工作。尽管这个问题的答案几乎要过时了——谁还在纸上编程啊——仍然有几点发现现在仍然适用：

研究对象中，

最好和最差的程序员完成一个编程练习所用的编程时间有 20 倍的差距。

调试时间有 25 倍的差距。

所写程序大小有 5 倍差距。

程序执行速度有 10 倍差距。

研究对象都有几年的经验，事实上经验年数对这些数字似乎没有显著的影响。总之，差距还是挺显著的，不是吗？

10 倍价值的程序员

“10 倍价值程序员”这个概念起源于这篇论文。这个概念吸引了人们数十年，而且及其有争议。直接 Google 一下这个英文短语（10x programmer）。

公平来讲，Sackman 等人的数字一定被夸大了，很多人都对他们的方法提出了质疑。但是几乎没有人反对在糟糕的程序员与优秀的程序员之间有着显著差距。甚至据传，每个人都认识一个人，他能在极短时间内写出惊人的软件。

谁在乎？

“所以……谁在乎？”你可能会问。为什么 10 倍价值程序员这么重要呢？

一方面来说，10 倍价值程序员至少表面上对雇主来说是桩好买卖。理论上，雇主可以：

1.炒掉 90% 的员工

2.剩余 10% 雇佣 10 倍价值程序员

3.付给他们大约 2 倍工资

4.盈利

简单，对吧？

然而现实会有点不一样。首先，这假设你能招到一个 10 倍价值程序员的团队……祝你好运。由于你很可能做不到这一点，你得把他们整合进现存的一倍价值程序员团队中去。结果发现，团队中有一个比你更更更高产的程序员并不是那么鼓舞人心。

但是实际上，我不想太过详述 10 倍价值程序员这个概念。因为在我看来，有这么一群不同的“人种”，他们的影响力远超过 10 倍价值程序员。

是谁呢？

我们先来仔细研究一下“程序员”这个概念。在 Sackman 的研究中，他们完全只关注编程能力。练习是高度与算法相关的，像“假定某网格代表一个迷宫，编写一个程序找到通路”这样的类型。好“程序员”擅长这种类型的工作：输入编程挑战，输出代码。每个程序员都有自己的任务列，并且在逐个完成。

输入代码。

如果这是你喜欢的工作，我肯定你能找到如此工作的地方。

然而，在我曾经工作的任何地方，实际编程都不是这样的。实话实说——谢天谢地。我觉得长期这样编程会无聊透顶的。

我觉得更有趣的角色是工程师的角色。工程师把想法变成实实在在的产品，他们也因此有更广阔的视野。他们手头有大量工具可以完成工作，当然编程也是工具之一。

但是实话实说，并且我想我也可以在此说，我们真的超级不擅长在那些被过分吹嘘的技能。

统计量不会说谎：

（a）行业均值：“每 1000 行代码中大约有 15 到 50 处错误。”他进一步声明这对那些背后有一定程度结构化编程、可能混有一些代码技巧的代码具有代表性。

（b）微软应用：“内部测试时每 1000 行代码中大约有 10 到 20 处错误，发布产品中每 1000 行代码中大约有 0.5 处错误（Moore 1992）。”他将其归功于代码阅读技巧和独立检测的组合（在其著作的另一章中有进一步讨论）。

（c）“Harlan Mills 开创了名为 ‘cleanroom development’ 的技巧，能实现在内部测试时每 1000 行代码有 3 处错误，在发布产品中每 1000 行代码有 0.1 处错误（Cobb 和 Mills 1990）。几个项目——例如飞船软件——利用了格式开发方法系统、同行审查和统计测试实现了在 500，000 行代码中有 0 处错误的水平。

要我说——我们应该尽力避免编程，使世界免受每次在集成开发环境（IDE）中按下某键产生的所有 bug 的侵害。

所以没错，10 倍价值程序员是个好主意，但是我要把门槛设置得高一点。到 2018 年了，世界已经变了。

…………

100 倍价值工程师

我喜欢延伸目标。它们经常引导我们后退一步，并带来思维的巨大转变。这个目标也一样。如果我们想成为 100 倍价值工程师——其影响力是老一倍价值工程师的 100 倍，该怎么实现呢？

做到自己高产并不够——当然单单有编程天赋就可能实现 10 倍价值，但达到 100 倍价值就不可能了。为了拥有有 100 倍的影响力，你得让团队和组织的生产率均大幅提高，并最终领导其他人用同样的工作方式。

尽管 100 倍价值听起来很极端，我在职业生涯中仍然和许多我认为有“100 倍价值的观念模式”、独特的思考、说话和行动方式的人合作过。

可能让某些人吃惊的是，这些与编程能力、科技和编程语言没有任何关系。常见的口号是：“为什么我们还在用 Java？如果我们能只用 Scala、Clojure、Node，《《在此输入今日便好 insert flavor of the day here》》就会更高产！”现实是，一种不同的编程语言可能最多让你达到 1.5 倍到 2 倍。这与 100 倍价值相比简直是小巫见大巫。100 倍价值是完全不同的游戏。

所以，到底什么是“100 倍价值的的观念模式”？让我们一起来讨论两个方面。

1. Ownership 所有权

100 倍价值工程师掌控他们所做的事。他们知道为什么这么做、怎么做、所做的是什么。在《Extreme Ownership》这本书中，两位前海豹突击队队员解释了他们的极端所有权（extreme ownership）概念。这个概念的核心是，当我说“拥有某物”时到底意味着什么。这意味着：接受你要对你所做的任何事情负责。

最重要的是这意味着：不能指别人。这不意味着所有事情都在你的控制之下，却意味着：当事情不可避免地出错时，你要对你如何反应负责。这意味着：你要负责预期可能发生的事情，并做好应急措施。这意味着你要从错误中学习，甚至从中汲取价值。掌控你所做事情的各个方面。

要得到这种程度的所有权，我只知道一个方法：挑战。挑战你和你的团队被要求做的任何事情，这样你能理解并掌控每一个决定。

2. Challenging the status quo 挑战现状

100 倍价值工程师在三个维度进行挑战：

1.做什么（What）？

这主要是关于范围的：我们在开发什么？是否仔细研究过？要求是否明确？我们确定所有这些都是重要的并且需要（马上）完成吗？

2.怎么做（How）？

这是关于在怎样机智地执行某事。有可以得到同样结果的更轻松方法吗？这也是关于过程的：我们怎么样得到想要的结果，以及怎样提高？

3.为什么（Why）？

这是关于业务环境的、关于完全理解为什么需要开发某个特性并检查产品经理的方法是否是满足用户需求的正确方法。

来逐个看看更多细节。

What？ 做什么？

更快地提供某产品的唯一最好方法是：缩减范围。它需要拥有的特性是什么。

可以在此应用我的“5 个真的吗？”技巧：

产品经理：我们需要有所有这 10 个特性

100 倍价值工程师：真的吗？

产品经理：嗯。

100 倍价值工程师：真的吗？

产品经理：好吧，好吧，可能不需要第七个特性。但是剩下的都要。

100 倍价值工程师：真的吗？

产品经理：嗯，是的，我是这么想的……让我跟客户确认一下。

好吧，他们可能需要第四个和第五个特性，但是我们可以之后再做这两个。剩下的都是必须的。

100 倍价值工程师：真的吗？

产品经理：是的。

这可能听起来像个玩笑，但是产品经理常常会拿一张长长的必需特性清单出现。然后经过几小时、几天、有时是几个月的谈判后，你得到了一张几乎只有原清单四分之一的清单。这是自然的，想出要加上的新特性要比移除特性更容易。

另一个在将范围降低到较低水平的方法，是使用“帕累托法则”，二八法则。维基百科：

帕累托法则（也叫二八法则，关键少数法则，或者稀疏因子法则）表明，对很多事件来说，大约 80% 的影响来自于 20% 的原因。

该法则有很多应用，软件开发就是其一。往往有很多种实现某特性的方法，使用极少的精力（比如说 20%）就能带来大多数收益（例如 80%）。这点吸引人，不仅仅是因为更少的工作量，还因为你能更经济地彻底检查特性，并且只在这些特性有价值、使用过后才进行完全开发。

How？ 怎么做？

既然需要开发的清单已经减少到一小部分了，仍然要通过挑战特性的实现方法来获得机动空间和好处。一般来说，实现某特性有很多方法。一旦团队想出一种方法，很多团队就满意了。100 倍价值工程师总会进一步寻找替代方法，根据各自的优缺点评估所有选择。

“怎么做”也会被技术债务影响。经常有“变态的”方法来实现某些快、脏的特性，“合适的”方法来首先还清技术债务，再干净地实现特性。什么是最好的方法？100 倍价值工程师认识到不只有一个正确答案，并且这取决于不同情况和累积技术债务的费用。一个 100 倍价值工程师能在不同的情景中作出正确抉择，能在合适的时机和产品谈判来降低技术债务。

“怎么做”的另一个方面是过程。我对 Scrum 很喜欢的一点是，它能有效设定一个基础，如果用得合适可以鼓励 100 倍价值的行为：

•改进是讨论和挑战做什么、怎么做和为什么的好平台。产品所有者提出要开发的新特性，开发团队挑战做什么和为什么，来得到全面的背景，并相互挑战如何实现特性。

•Plannings 针对下一步冲刺（sprint）做什么的计划，计划也是通往“辉煌和头脑”的手段：记起到底需要做什么，并且计划团队如何合作来交付产品

•Retrospectives 回顾是团队提升的方法。在一次冲刺循环中，有些事情出错了，有些事情进展不顺利。回顾是 100 倍价值工程师挑战团队来提升、下次做得更好的时刻。回顾也能练习所有权。100 倍价值工程师不抱怨低产，不指向自己以外的其他人。

Why？ 为什么？

上周我和一个工程师聊了聊，他刚刚发现自己花了整整 3 个月时间实现某特性，后来有发现对用户来说同样的价值本可以在 3 日内实现。显然不会是同一种功能，但是实现的目标是一样的。

这种事情怎么会发生呢？

除非工程师退后一步、扩大视野、挑战为什么，这种事情就会发生。为什么要开发这个特性？用户想要实现什么？他们的需求是什么？产品经理往往会提出非常具体的特性要求，偶尔具体化程度会比较低。他们的出发点是好的。然而更可能的情况是：产品经理也是人，也会遗漏。此外，风险在于工程师不再挑战更基础的问题：为什么我们要这么做？不是还有用其他更少的精力实现同样结果的方法吗？

但是，等等

说起来容易做起来难。做起来也应该难，不是什么人都应该能跻身 100 倍价值工程师。然而，我们都可以渴望变得更好，并找到相应的方法。

因此，看看 100 倍价值工程师的技能集合是值得的。你会注意到，这与 10 倍价值程序员是非常非常不同的。

•沟通——这点几乎明显得不用提了，但是它是重要的一点。100 倍价值工程师有优秀的沟通技巧。沟通是拥有 100 倍影响力的关键部分。

•创造力——显然这在 10 倍价值程序员中是常见的，但是所要求的创造力不是关于算法的，也不是关于灵巧的类继承结构（class inheritance structures）的，而是关于想出更有效的方法来实现目标。

•同理心——在“挑战所有”的长篇大论中隐藏着“生产力挑战”。那么我这么说意味着什么？让我用我的大儿子做例子来解释一下。他 4 岁了。4 岁小孩最喜欢的问题是什么？“为什么！？”这意味着我儿子是个 100 倍价值工程师吗？不。为什么不呢？因为他总是问“为什么？”，无论时机正确与否，无论有没有意义，无论他是不是让他的父母想自杀。拥有知道该挑战什么、怎么挑战和何时挑战的同理心也是 100 倍价值工程师的重要技能。

•谈判——好主意被高估了。人人都有好主意，但几乎没人真正实现这些想法。你知道需要实现一个想法，实现它的一个重要因素就是谈判——与其他开发人员谈判，与产品经理谈判，与其他利益相关者谈判。解释为什么某个主意是个好主意，以及为什么需要时间执行它们。100 倍价值工程师知道怎么做。所以当他们在场时，所有事情都似乎有可能实现。

•技术——这是清单上的最后一点，但依然重要。虽然大多数提到的技巧都是“软实力”，但这并不意味着 100 倍价值工程师不需要技术。事实上，他（她）拥有领先的技术天赋是先决条件，原因有二：（1）挑战技术层面上的事情会产生巨大收益，也因此要求对技术有深层次的理解；（2）理念是重要的，如果 100 倍价值工程师没有高技术，就不会被同辈接受。你得是“我们的一员”。

…………

几个月后，“我想成为世界上最好的程序员”先生作为程序员工作得非常顺利。他有天赋、努力工作、高产而且非常聪明。他会成为世界上最好的程序员吗？我不知道。

但是私下里，我希望这不重要。

我希望某一天，不是现在，但是可能是几年后，他会想做更多事。那时他会调整他的理想，不仅仅要擅长这个叫“编程”狭窄领域，而且渴望拥有 100 倍价值工程师的影响力。