众所周知，计数提交和拉取请求作为衡量工程效率的一个好主意。有很多不好的主意。游戏很容易。更重要的是，软件工程不仅仅是关于提交代码。通常，它不提交任何代码。
但是，根据我过去15年在该行业的众多团队的短暂经验，我发现其中一项功能始终保持最佳。他们的提交次数（或请求请求数）始终高于大多数队友。实际上，在大多数情况下，表现最好的人将排名第二的人的贡献提高了50％或更多。
在继续进行下一步之前，让我们解开此处“最佳表现”的含义。每个团队都有自己的要求和他们最看重的东西。因此，根据团队和环境的不同，表现最好的人会具有新的含义。在这种情况下，我将绩效最高的人定义为团队认为有关代码大多数问题的专家，也可以由PM依靠他们按时交付（根据他们自己的估计），并且不怕承担具有挑战性的项目。表现最好的人也为其他人树立了榜样。
我问自己一个问题：为什么如上定义的最佳表现者具有最高的承诺？我想到了一些想法：
他们擅长将大中型工作分解为较小的块，以便于检查工作进展顺利时易于检查和回滚。换句话说，他们知道如何＆＃34; stage＆＃34;他们的工作。带有大量文件更改的大型提交更难于审阅，并且增加了爬虫的范围。较小的拉取请求使事情更易于审阅，更自给自足，并且运送风险较小。
他们很快。总体而言，它们显示出较高的代码速度。这不是一整夜的事情。精通代码库需要花费数月和数年的时间。但是，您编写的代码越多，您所知道的越多，您变得越快。这是一个良性循环。您起初会很慢，但是随着时间的推移和练习，您会变得很快。
他们拥有更多所有权。如果他们一路发现问题，便记下该问题，然后再解决。否则他们可能会随即修复。他们离开代码库比发现更好。他们每天都会练习。由于速度，他们可以拥有更多所有权。由于他们起步很快，因此能够将改进和调整作为常规工作流程的一部分。他们不认为“哦，这是一个问题，但这不是我的问题”。他们拥有问题，并根据自己的最佳判断来解决问题。在此处阅读更多有关高级代理工程师的信息。
可能有人认为，成为一名熟练的编码人员会带来一些弊端，例如太忙而无法与团队中的其他人配对程序。或者可能对单打独斗感兴趣，而不参与帮助队友扩大规模。相反，我发现这样多产的编码员对他们的时间很慷慨。他们对代码库和速度的舒适度使他们能够花大量时间来帮助队友。
这可能表明某种形式的帕累托原理正在发挥作用。也许？我不确定。我认为，如果一个团队的运作使80％的输出来自20％的人员，那是错误的。使用提交作为度量输出的手段是错误的。我知道有几位世界一流的工程师，他们的团队中提交的次数最多。然而，它们对于团队的成功至关重要。而且他们的输出与顶级提交者一样有价值，有时甚至更有价值。
最后，如果作为团队的工程师，您发现自己钦佩表现出色的人的品质并感到被他们吓倒，那么可能会有助于找出原因背后的原因。可以被表现最好的人吓倒，并感到有些失落。但是请记住，当表现最好的人开始时，他们也有学习的弯路。那些花费时间来学习“如何”背后的“为什么”的人，能够在各种技术和语言中应用该原理，并随着时间的流逝获得丰厚的回报。