It’s largely known that counting commits and pull requests as a measure of engineering productivity is a bad idea. There are many reasons why it’s a bad idea. It’s easy to game. More importantly, software engineering is not just about committing code. Quite often its about not committing any code.

Yet, in my short experience of the last 15 years in the industry across numerous teams I have found one feature constant among the top performers. Their number of commits (or pull requests) is consistently higher than most of their team mates. In fact in most instances the top performer's commits out number the second highest by 50% or more.

Before we go any further, let’s unpack what “top performer” here means. Every team has their own requirements and what they value most. So top performers take on new meanings depending on the team and circumstances. In this case I define top performers as someone the team considers a go to person for most questions about the code and also can be relied on by PMs to deliver things on time (by their own estimates) and are not afraid to take on challenging projects. Top performers also set a high bar for others to emulate on the team.

A question I asked myself was: why do top performers, as defined above, have the highest commits? Some thoughts that come to mind:

Staging their work

They are good at breaking up large or medium sized work into smaller chunks that are easily reviewable and easier to roll back in case things go south on production. In other words, they know how to "stage" their work. Large commits with a ton of files changed are harder to reviewer and increase scope for bugs to creep in. Smaller pull requests make things easier to review, are more self contained and less risky to ship.

Velocity

They are quick. Overall they display high code velocity. This is not an over-night thing. It takes months and years to become proficient with a codebase. But the more you code, the more you know and the faster you become. It’s a virtuous cycle. You will start out slow, but overtime and with practice you will become fast.

Ownership & Agency

They take on more ownership. If they find an issue along the way, they make a note of it and come back to fix it. Or they might fix in as they go. They leave the codebase better than they found it. And they practice this on a daily basis. They can take on more ownership because of velocity. Since they are quick to begin with, they are able to include improvements and tweaks as part of their regular workflow. They don’t think that “oh here’s an issue, but it’s not my problem”. They own the problem and use their best judgement to solve the problem in the moment. Read more about high agency engineers here.

One might think that being a proficient coder comes with its cons such as being too busy to pair program with others on the team. Or perhaps being interested in solo work and not engaging in helping teammates scale up. On the contrary I have found such prolific coders to be very generous with their time. Their comfort with the code base and speed allows them to carve our good amount of time to help their teammates.

This might indicate some form of Pareto principle at play. Perhaps? I am not sure. I think that if a team functions such that 80% of the output comes from 20% of the people - something is wrong. Using commits as a means of measure output is wrong. I know several world class engineers who do not have the highest number of commits in their team. Yet they are crucial to their teams success. And their output is as valuable or sometimes more valuable than the top committers.

Lastly, if you, as an engineer on a team, find yourself admiring the qualities of the top performer and feel intimidated by them, it might help to figure out the whys behind the how. It’s ok to be intimidated by top performers, and feel a bit lost. But remember that when the top performer started, they too had a learning curve. Those that spend time to learn the “why” behind the “how”, are able to apply that principle across technologies and languages, reaping rich rewards over time.

Hacker News Discussion

I posted this article on Hacker News and it generated a bunch of great discussion. Here are some comments that resonated with me:

The thing to note here is that this is a one-way correlation: top performers tend to produce lots of commits. That does not mean that people who produce a high amount of commits are the top performers in your company. (link)

I have noticed that pretty much every software engineer to some degree has problems that they procrastinate on. Folk can spend 10x more time talking about doing something than it takes to do it. (link)

Fast dev produces 5x more code than normal devs and produces 5x more bugs. Which means the ratio is the same but it feels different because they're producing so much more code. (link)

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit swecareer.substack.com