A while back, Rahul Thathoo, Engineering Lead at Square, posted an article saying that most top performers had the most commits and pull requests.. Interestingly, that doesn’t align with my experience from small companies but in particular from my time in a consultancy.

At one point, as is almost inevitable, management tried to tie performance to “contributions”. Since I was convinced that that was misguided I spent some time to look at the numbers. In the end, except for one team member, what management considered contributions, namely commits and merged pull requests, negatively correlated to performance.

Here are my findings at the time.

Top performers squashed their commits

After a pull request was done, the experienced people often squashed commits. In fact, it was not unusual for a PR to end up being a single commit.

My guess is that this is a combination of being familiar with git enough to know that it exists and understanding that work consists of more than just writing the code.

Devs who knew how to squash also cared about the history and wouldn’t have 10 “test” commits in a row.

They had fewer total pull requests that got accepted more often

More experienced devs tended to stick to one PR and work on it till it was done. Less experienced people tended to abandon PRs and open new ones as a clean slate.

The more experienced devs usually worked on larger features. They’d often complete a project with less than ten pull requests that implemented complex core functionality that they had to work on for much longer.

A junior person, on the other hand, often had twenty PRs for a single project. But they were all for smaller features.

They’d often get less feedback in PRs so would have fewer revisions

Seniors often got less feedback per PR relative to it’s size. So, even if they didn’t squash their commits they would still have fewer.

They were involved in things other than code

A top dev would almost always only be writing code but would be involved in several other things as well.

Firstly, they were involved in the project architecture.

They were more involved in code reviews. They tended to post more and more detailed comments.

They also mentored and did pair programming with juniors.

And they often conducted training and workshops with clients as well.

In conclusion

I find the differences between Rahul’s experience and mine interesting. I would very much like to understand the exact causes. I have three hypotheses that all come with a caveat that I don’t know exactly how Square runs their dev.

Scale

A part of the discrepancies can probably be accounted for by the difference in scale between Square which employs ~5500 people versus companies I’ve worked for that are all in the 10-20 range. Data from 500 senior devs is definitely more reliable then from just 5.

Specialization

The other factor that might come into play might be that top developers in a consultancy are valuable for skills other than programming. They’re often very much involved in the design (visual and otherwise), DevOps, testing and even with dealing with clients as the technical lead. Square almost definitely employs specialists for those other roles.

In a small shop work is heavily optimized for the senior devs time

In a small consultancy work is heavily optimized for the senior devs time. It’s senior devs time that effectively determines the capacity of the company. In turn, it’s very closely correlated to profitability of an individual project and the company as a whole.

While keeping in mind that I am assuming a lot about how Square runs their dev, here are some examples:

1. In a small consultancy you don’t want to use your high leverage senior dev to work on simple features. You want them to do the high impact things. Especially since you only have a couple of them, their time is much more valuable. Square probably has a lot more employees who’d be considered senior from my perspective so they can just round-robin the work.

2. In a consultancy the objective is to deliver the project on time and on schedule. There is little benefit to delivering the project too early. It’s more advantageous to optimize for the cost of devs, in particular senior ones, instead. As a result, the senior devs would take care of the most complex functionality. They would then work on something else including things other than code mentioned above. This effectively increases the company’s capacity while not increasing headcount. On the other hand, Square probably has teams that run projects but they probably are incentivized to finish the entire project as quickly as possible. Because of that, once the senior dev is done with the complex functionality they’re likely to work on the smaller simpler parts where they can be much quicker then a junior.

3. In a consultancy, there is a often a maintenance period after the project has been delivered. Here the senior devs are often involved in the investigation but the fixes are often done by the juniors. This is again to optimize the seniors time. But it also allows the juniors to learn to deal with clients in a less stressful context. Square probably doesn’t as heavily optimize who the bug fixes are assigned to.