Why do most top performers have the highest count of commits and pull requests?

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.<p>I&#x27;ve had to deal with plenty of colleagues who moved very fast, committed extremely often, and were praised by management for the amount of work they produced. But in reality their work was rushed, sloppy, riddled with issues and a nightmare to maintain. And it would inevitably fall upon us &quot;lesser&quot; performers to actually investigate and fix all those issues, making us look less productive in the process.<p>In my opinion a better metric to quantify someone&#x27;s performance is to count the amount of problems they solve vs. the amount of problems they create. I bet that many of the rockstar programmers out there would land on the negative side of that particular scale.

Being considered the go-to person means you are first in line to make small tweaks (and config changes in code).<p>This increases the change count.<p>If there is a review process where another engineer has to approve work, this exacerbates the gap, as the go-to person can get their reviews done quickly. If they&#x27;re trusted, the reviews might not be thorough.<p>This increases the rate at which changes go in.<p>These and other factors suggest that it&#x27;s hard to split cause and effect here. Being seen as productive increases change count :)

Perhaps some of the more productive workers are the ones that don&#x27;t hesitate to make necessary code changes, test the changes adequately, and then move on to the next thing.<p>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. For hard problems, that discussion is necessary and beneficial, but lots of problems just need someone to open up the text editor and get it done.

There&#x27;s a pretty subtle pitfall that teams can fall into here.<p>Let&#x27;s say a team has 2 developers. Josh is 20% &quot;better&quot; than the John, or simply started earlier and has more context on the code base. So initially, Josh is 20% faster, but now John has to spend an extra 20% of his time reviewing Josh&#x27;s code in a pull request (or understanding Josh&#x27;s code so he can make a change) instead of making forward progress. So now, actually John is even 20% less effective than he can be, and he has less time to actually code. And since he&#x27;s even less productive, Josh has __more__ time to code, so he&#x27;s even faster, which means he writes more code. It kind of compounds, and even an initial slight advantage in speed or context for one developer can amplify itself over time.<p>A good engineering manager or senior engineer can detect when that&#x27;s happening and try to correct the balance. But often the team kind of settles into a mode where Josh is known to be better and more productive and everything is funneled to him.

&gt; 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.<p>One consistent tension is that the old-hand developers have a &quot;mental issue queue&quot; that is enormous, but without fail, every time, they just can&#x27;t be transferred.<p>These can&#x27;t be made into issues and farmed out to other people. Inconsistencies in the data model, for instance, might exist, but a better solution isn&#x27;t obvious. You can hand it to someone fresh, and after significant effort (on both of your parts) they agree with the inconsistency, but they won&#x27;t propose a solution that&#x27;s any better.<p>Once you&#x27;ve contributed enough of the main functions of a code base, you just never lack for something to do. All code is bad, because the business focus is on expansion of responsibilities over refinement of the existing ones.<p>Those ghost issues are best communicated with a code change, at which all observers say WOW WHY DID WE NOT SEE THIS?! But the issue without the code change gets gawking blank stares.<p>EDIT: but fixing unrelated issues as you go is bad, don&#x27;t do it!

Lol, when I worked at a unicorn one of my buddies got an award for &quot;most testing code commits&quot;<p>He confided after drinks it was because he didn&#x27;t know how to squash&#x2F;amend his commits.<p>So I&#x27;m not so sure about that metric....

“Top performer” here means “top performer in a team, relatively to teammates”, which narrows the definition substantially. There are mysterious geniuses who can deliver a great piece of software just as an experiment&#x2F;PoC out of the blue, but they don’t tend to shine in such environments—they could be founders or indie consultants, or it could be their side-project persona.<p>(I.e., stating the obvious, if you are intensely working on something on your own, magically starting to atomically commit each change with a thoughtful message will not make you better but can easily eat 1&#x2F;3 of your time. It’s OK for your commits to be “fat” as long as you yourself manage to keep track of your work in meantime.)

OP mentions three things: staging their work, velocity, and sense of agency&#x2F;ownership. All three are problematic. Often those who have worked with a component the longest and&#x2F;or wrote significant parts of it become its maintainers, either formally or de facto. As a maintainer (I&#x27;ve been one myself) it&#x27;s simply easier to get commits in, not necessarily because you&#x27;re better at the work but because of the role itself. You never have to re-work your commits to conform to someone else&#x27;s idea of how things should work. People trust you, so reviews are often cursory. Many maintainers return that courtesy by subjecting others&#x27; work to <i>excruciating</i> review, slowing them down. Sometimes it&#x27;s intentional, sometimes not, but the result&#x27;s the same. Also, a maintainer often has many commits that started off as someone else&#x27;s idea but that person didn&#x27;t have the time or knowledge to complete them, so those are kind of low-hanging fruit that inflate the numbers. A mediocre maintainer will usually still have more commits than even the most talented non-maintainer. Calling them &quot;top performers&quot; because of something that&#x27;s part of the <i>role</i> seems a bit circular.<p>So much for velocity and ownership. As for the part about staging commits, I&#x27;d like to see some evidence. In my experience there&#x27;s no difference, or sometimes the maintainers are even <i>less</i> likely to break up commits. This can be because maintainers are often charged with making commits with lots of internal dependencies that make them harder to break up, or because it&#x27;s easy to get a stamp even on a questionable commit from people who are dependent on their goodwill to get their own commits in.

I&#x27;ve worked with some amazing programmers that produce fabulous amounts of code. and, often, that&#x27;s who you need. I have been envious of their prodigious production. I think, often, those folks solve problems by adding more code.<p>I think, sometimes that mountain of code starts to become a liability. I&#x27;m a little better at reading a lot of code, consolidating, and fixing bugs. Importantly, fixing bugs without breaking other stuff (usually. coding is hard)<p>if you buy the adage &quot;make it work, make it right, make it fast&quot;, you&#x27;d probably buy that most people fall into one of those categories and excel (there are rare jewels that are amazing at all three. Carmack maybe is a good example).<p>Anyway, I&#x27;m not a top performer. I have my moments of glory, and I think I deliver good value. I try to avoid git stats. I peek from time to time, and I&#x27;m super pleased that I&#x27;ve deleted about 2x the amount of code I&#x27;ve added but, that&#x27;s maybe me protecting my ego.<p>Everybody needs code, some people need code to be right, even fewer people need code to be fast. Different people bring different skills to the table. Be real careful about how those different aspects play into reaching goals.

`git shortlog -sne --oneline --since=&#x27;Jan 1 2010&#x27;`<p>I like running the above command because it gives a good sense of coding productivity at the very least. And then you can dig into specific people to understand why exactly they have lots of commits or not. Most people use Git in a very similar fashion so you can very quickly make a generalization about how they commit if you look through their last N commits.<p>Some &#x27;high commit count&#x27; people have lots of low value commits, e.g. lots of &#x27;fix it&#x27; commits.<p>Other &#x27;high commit count&#x27; people are very productive but mix in a lot of atomic commits, e.g. lots of &#x27;another commit to change this comment&#x27;, leading to a PR of 9 super small commits + 1 real commit, that&#x27;s readable alongside their actual work.<p>Others are actually just more productive than other people. That might be because their code changes are simpler, or in an area that&#x27;s easier to be productive in and write lots of code. Or they just work more. Or they work at a higher velocity because they understand the codebase and domain better.<p>Definitely don&#x27;t _only_ use these metrics because some people just code slower and put out 1 large PR, but I can definitely believe a pattern of people at the top end of productivity who put out both small and large PRs at a higher velocity than the &#x27;less productive&#x27; people.<p>I would honestly just attribute those high value, high commit count people to being stronger developers overall, in my limited experience. Overall as in, not weak in any particular area, and quite strong technically in every area. The people you can put in any situation in the domain and they&#x27;d probably succeed. Because they&#x27;re strong across the entire codebase, their productivity is just generally higher no matter what they&#x27;re doing.

I’m somewhat self conscious about the sheer volume of commits that I make. The reason there are so many is that I want each atomic unit to be distinguishable.<p>Part of that is motivated by the will to save often in case something goes wrong. Part is to let continuous integration validate with high granularity. Part is to allow for binary search on revision history to reproduce rare bugs and isolate the specific change which introduced it.<p>These considerations may explain the correlation with “top performing” - although for what it’s worth I try to make commits which remove more lines of code than they add whenever possible.

Top performers do more work (generally, not always). This is contrary to the HN conventional wisdom that lines of code are a bad metric, and I see where those people are coming from. But generally people capable of writing more code faster are also capable of writing the right code.

IDK I&#x27;ve made PRs with multiple trivial commits within an hour. I&#x27;ve also spent over 30 hours on PRs with only 3 commits. It&#x27;s a useful heuristic but doesn&#x27;t map very well to work invested.

For me at least. I am the most productive when I can do many SMALL commits and able to push them to prod.<p>You have to be able to make your change; either a refactoring or a functionality change and get it through the QA, review, deploy process. Now days I spent a lot of time, dealing with multiple branches and deployment environments and my productivity is in the floor. In a previous job I was able to deploy 2 or 3 changes a day in prod. It was very full filling.

In the olden days they used to measure performance by SLOC, Source Lines of Code.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Source_lines_of_code" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Source_lines_of_code</a>

I was a top performer on my team in the past for a couple years. It was nice being an expert, but they never promoted me and were always playing games. I think it&#x27;s better just be a average or below average person and not have to deal with the BS that comes with being a top performer. At this point in my career I doubt I&#x27;ll ever make it back to that level of skill anyways.

The problem lies in the question. In the worst circumstances, it&#x27;s indicating survivorship bias, and in the best circumstances the only truths it reveals are tautological. Using number of commits to measure productivity is the new version of thinking that the more number of lines of code that a programmer writes, the better.<p>Not that this will stop a segment of the industry from flushing a non-trivial amount of resources down the drain learning this lesson, and inevitably leaving a chunk of stalwarts who never really learn anything. It was clear that was going to happen when the &quot;social coding&quot; site that everyone was flocking to put so much emphasis on activity measured in number of commits, forks, and other administrative details. Things which were only any good for advertising the site&#x27;s own user engagement in its pre-IPO&#x2F;-acquisition phase, and too many people mistaking it as a measurement of something else.

Because they are willing to take the risk of publicly being wrong.<p>Committing your source code to the company git makes it very easy for others to point at you later, if things break. And it&#x27;s pretty much impossible to undo once someone else has pulled your change.<p>In my opinion, many top performers are simply people who do what needs to be done, and when it&#x27;s needed.

I don&#x27;t disagree this could be true and the reasoning (makes sense)™ but it would be nice to have some hard data when making such assertions.

Because most people don&#x27;t do anything at all.<p>Even trying to do something puts you in the top half, even if it&#x27;s poor quality, because a huge fraction of people are completely useless and don&#x27;t ever do anything productive at all.

Not to take away from the premise offered in the article ...<p>But is there a selection bias here? Some kinds of work invariably involve more github activity, small fixes and the like. Those things are generally, unambiguously &#x27;productive&#x27; and &#x27;leave the code better&#x27;, which lends us to believe &#x27;top performers&#x27;. Surely, this might be true but I think within a specific context.<p>If find solving new or novel problems involves a lot of work that is hacky, experiemental, quick trial, often the kinds of things that in most cases don&#x27;t even get checked in.

If you look at it from a slightly different viewpoint, there&#x27;s nothing remotely surprising or controversial about this. You wouldn&#x27;t be surprised to hear that the best factory workers tend to produce the most widgets per hour, or that the best butchers process the most meat per hour. Productive output is definitely highly correlated with job skill, almost tautologically so. Yes, a code commit isn&#x27;t exactly the same thing as a widget, but it&#x27;s similar enough in broad strokes to still be a useful measurement.

I’m trying to understand the DevOps of this concept. Is everybody working in the same repo, or are these personal forks that get hammered until nice merged PRs can be submitted? Do devs complete whole features before submitting, or do they submit partial work that everybody else is trying to contribute to? Are multiple developers working on the same code modules, or have they been split out? Are there tests and interfaces written ahead of time, or do they do tasking by prose?<p>The goal of software management is to keep everybody productive. If you have an imbalance in commits or pull requests in the main repo&#x2F;branch, that’s a strong sign of a broken process. Tasks should be given according to familiarity and skill so this doesn’t happen.<p>This also says something about software design. Good design is easy to split up. Bad design requires a ‘go to’ person. Therefore, a ‘go to’ person is by definition not a good software engineer, because their design was bad, and&#x2F;or they never fixed it. And if it worked the first time, you wouldn’t have to ‘go to’ anybody.<p>The skill ladder of software engineering goes something like: watching, practicing, contributing, designing, teaching, leading. Every developer goes through this process from scratch in every project. Getting stuck is a problem (as is skipping steps). Preventing other people from progressing is a bigger problem.<p>Perhaps rethink this.

In a mature project, the number of removed lines is a stronger proxy to productivities.<p>It is related to the unavoidable tech debt that any project has and only the strongest people see it and work on it.

Once you are the top-committer in a project, you have the advantage. You know most of the code, even if it doesn&#x27;t have tests. It&#x27;s easy to figure out where reported bugs are, that you have introduced. Meanwhile, the rest of the team is busy reviewing your code and rebasing their PRs.<p>I have seen this pattern so many times. It&#x27;a a good strategy to be recognized by management.<p>Also what happens when the top-committer leaves, suddenly the rest of the team can breath and flourish.

One reason not mentioned (or maybe it&#x27;s only me):<p>If I&#x27;ve got bunch of problems, I&#x27;ll work on the easiest ones first, saving the hardest for last. This clears my mind from the drag from the easier problems, and as a side effect I wind up committing more.<p>There&#x27;s no particular correlation between how hard a problem is to solve vs how much time it takes to solve them. So hit the easy ones first and make your users happy!

Top performers are motivated and do more work. But that does not necessarily translate into real progress. If you shit the bed and clean it up, its not real progress. Unfortunately, management doesnt see that way.<p>I wont consider myself a top performer. But I have my moments of glory. Most of my impactful commits were deleting unwanted code and needless libraries in the codebase.

Old maxim: &quot;If you want something done, give it to a busy person&quot;

&gt; ... top performers ... highest count of commits and pull requests<p>&gt; ... define top performers as ... a go to person<p>So circular logic. Got it.<p>In a related story, why employed engineers have code contribution to the company that&#x27;s way higher (actually infinitely higher) than those who are not in the company.

My theory: simply put, a large number of commits (without considering excess&#x2F;cheating for the sake of themselves) can indicate lots of qualities of a good software engineer: order, planning, precision and capacity of partitioning a problem in smaller units.

&gt; &quot;<i>the top performer&#x27;s commits out number the second highest by 50% or more. [...] This might indicate some form of Pareto principle at play. Perhaps?</i>&quot;<p>Price&#x27;s Law?<p>&quot;50% of the work is done by the square root of the total number of people who participate in the work&quot; -&gt; &quot;You are working on a team, and there are the superstars who do most of the work or seem to produce most of the outcomes and then there is everyone else.&quot;<p><a href="https:&#x2F;&#x2F;expressingthegeniuswithin.com&#x2F;prices-law-and-how-it-applies-to-everything&#x2F;" rel="nofollow">https:&#x2F;&#x2F;expressingthegeniuswithin.com&#x2F;prices-law-and-how-it-...</a>

The two top performers in my organization definitely don&#x27;t have a lot of commits. Instead, I would say their strongest skill is written communication; in emails, log messages, code review comments, and chat messages.

I worked once on a piece of software to track construction projects. The CEO was always grumbling about the pace of development, citing the example of programmers who added Gantt charts to it in two days, and why was I so much slower at “simpler” features.<p>Fast forward a couple of months, and we had a customer complain about the Gantt charts being off. I had a closer look at the thing, and it turned out that the bars on the chart had been drawn using the Math.random() function. They came out different each time you refreshed the page and were in no way related to the real thing.

When you have a lot of commits you are working off yourself while everyone else needs to get caught up on what you did and then contribute after. Its essentially twice (or whatever) as much work as a laggard. It becomes 1 persons project and the others are observing. For better or worse because just running with something is often faster than deliberating at every turn. But also can backfire in many ways. Its similar to group projects in college.

I hope that someday this &quot;version control craze&quot; will end, this perpetual race where everybody is urging to fire PRs to up his stauts in the team, this sensation that before being a good engineer you have to know git dark arts to the core, in order to rewrite &quot;HISTORY&quot;, and amend each misdoing as you see fit. We need to remember what is our job: writing software that makes sense, not commiting code.

This is inline with my experience as well. I know it is the common wisdom to not measure performance with lines of code or number of commits. But in a large picture it&#x27;s always the top performers that make the most commits.<p>If I was a manager and asked to lay off X percent of the engineers, I would totally take into account number of commits among other signals.

One important point missed:<p>- Top performers tend to be motivated.<p>- Just because someone is a &quot;top performer&quot; in one project&#x2F;team&#x2F;company doesn&#x27;t mean this person will be one in another project&#x2F;team&#x2F;company. Reasons can be manifold, motivation can play a big role between someone being a good and someone being a top performer.

“top performer” is meaningless unless you’re looking back with enough distance to quantify all manner of contributions.. the people who generated the most complexity the fastest are just as likely to be dangerous forces of chaos.

That&#x27;s plainly not true.<p>There are top performers that do not produce the largest number of commits and PRs.<p>They produces the most difficult ones to get right.<p>There are mediocre performers that produces an awful lot of commits and PRs, confusing volume with substance.

Could not disagree more. The article&#x27;s main argument is wrong and dangerous to an extent! A software engineer&#x27;s productivity depends on the quality of his thinking that goes on between his two ears - not on the number of lines of code (LOC), number of commits and some other meaningless measure. I don&#x27;t think the author knows&#x2F;understands what it takes to operate at a Senior&#x2F;Staff level and beyond. Yeah, may be for someone just out of school productivity can be measured in terms of lines of code. OTOH, if a Principle Engineer in the team comes to me and says that he feels great just because he added 500 commits&#x2F;30k lines of new code to the code base I will just say one thing: &quot;run for your life&quot;! as soon as possible.

Quality is usually how fast they can complete features with least bugs for a faster release while navigating feature changes they go. That’s where rubber hits the road.

Another interesting characteristic I&#x27;ve seen over the years from top performers is that they also have deleted the most code.

Maybe, just maybe... the person you think is a Top Performer is not actually the Top Performer and you are creating a fake correlation to their high number of commits and pull request. Maybe we need to define who is the Top Performer in the first place.

I suspect that it&#x27;s nearly impossible to separate one&#x27;s definition of a top performing developer from some sense of how often they commit. For better for for worse.<p>I&#x27;ve worked on teams where I had colleagues who were incredibly deliberative. They would spend lots of time working with stakeholders to deeply understand their problems, and then produce elegant solutions that made their jobs drastically easier. Small changes with huge payoff. But management, and even most other team members, didn&#x27;t recognize this. They just saw a slow programmer. Credit tended to go almost exclusively to other teams, when their members started using those tools to radically improve their own processes. The company&#x27;s dev org largely didn&#x27;t care about that effect, because it didn&#x27;t positively influence their own KPIs.

Obligatory: <a href="https:&#x2F;&#x2F;github.com&#x2F;artiebits&#x2F;fake-git-history" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;artiebits&#x2F;fake-git-history</a> (does just what it says on the tin)<p><i>&quot;I don&#x27;t encourage people to cheat. But if anybody is judging your professional skills by the graph at your GitHub profile, they deserve to see a rich graph&quot;</i>

Wow, the premise of this article is very wrong; it&#x27;s deeply concerning that people are falling for this.<p>Those who make a lot of commits are not top performers, they are mostly engineers who are overly concerned with their &#x27;optics&#x27;; they are engineers who are good at projecting themselves as &#x27;top performers&#x27; but if you actually look at the results of their work a few years down the line, you will see that they are in fact low performers of the worst kind because they tend to add a lot of unnecessary complexity and technical debt because they don&#x27;t think through things enough and just implement.<p>I&#x27;m absolutely shocked to learn that people are falling for this.