Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

swecareer.substack.com

Post reply on HN
Print view View original

71–80 of 194 posts

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

#71

Post by waheoo »

sgtnoodle wrote: post #37
codegladiator wrote: post #30

Earlier quoted context omitted.

I worked as a contractor with some companies and peer coded with their engineers. What I found was that its not just procrastination. Many folks are just afraid to commit code, like literally scared and I could never get a real reason for that. At one point I added some code based on the direction what requirements were taking. But I could not convince him to commit it. So we finally agreed to let it be there comment…

Sounds about right! I think that's an indication of lack of sufficient regression test coverage, coupled with complacency/fatigue from working on the same code base for an extended period of time. Unfortunately, the most business critical pieces of code tend to be the least regression tested. It's the earliest stuff that was made before any test frameworks were matured, it's been hacked on countless times by half the…

Pretty much this. I suffer huge anxiety about committing code where I work.

The regression testing is flakey and the ci/cd procedure is rediculously complex and black box.

Very little transparency about what is or is not covered. Failures are common a, cryptic and intermittent.

The work where I know where the tests live I commit without hesitation.

Other random shit I happen across. Avoid it like the plague.

Doesnt help how big the sites are either.

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

#72

Post by ndepoel »

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.

I'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 "lesser" performers to actually investigate and fix all those issues, making us look less productive in the process.

In my opinion a better metric to quantify someone'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.

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

#73

Post by justanotherguy0 »

sgtnoodle wrote: post #54
sgtnoodle wrote: post #50

Earlier quoted context omitted.

That sounds miserable. I think, as a reviewer, it's important to keep in mind that most problems have many solutions. You have to be flexible and work with the person that did the hard work of implementing it. Everyone messes up and lets a bug slip through every now and then. That's what multiple layers of thorough testing is for. On my current team, I'm considered to be the most thorough code reviewer. Folk usually…

Also, it helps a lot to hammer out a lot of design and implementation details before writing any code. For any work project I start that I anticipate taking more than a few hours to code, I spend an hour or so writing an "architecture document" which I then distribute to anyone I think will have an opinion about it. That gives folk a place to ask questions and "bike shed" the problem long before I've invested any "ar…

Is that slide deck publicly available?

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

#74

Post by pydry »

ndepoel wrote: post #72

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. I'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, slop…

Most problems are multi causal and if you have blame culture will degenerate into a litany of finger pointing.

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

#75

Post by daxfohl »

cryptica wrote: post #61
atraac wrote: post #58

Earlier quoted context omitted.

That's why there's 'most' in the title. Noone here assumes that more commits = better, but the article simply points out a correlation that MOST top performers, tend to have most git activity, and I see a similar thing in my professional experience. That doesn't mean I think that anyone with a lot of PR reviews or commits is better than other people...

I disagree with the 'most' premise as well. Totally a false signal. In my view, the opposite is true. The top performers tend to commit less. People who are genuinely passionate about coding don't tend to put that much effort into the more pedantic aspects of the process; they're more focused on big ideas such as the structurally important parts of the architecture. The developers who make a lot of commits are often…

My experience is the same as the author's. If one defines top performer as you did, those who are "more focused on big ideas such as the structurally important parts of the architecture", and you run the numbers, you'll find most of these people will also be outliers in commit count.

This is true in just about every team I've worked in. And it makes sense too. The person who best understands the design would be the fastest to implement it. They can both do the design and implement 2/3 of it in the time it takes the other engineer to grok the design and fumble through the other third.

Frankly, I think the role of "design architect" is make-believe. A project only has so much "design work" to be done, so the top dev isn't going to be sitting around twiddling their thumbs through the implementation phase. Even people like Jeff Dean still write a ton of code, to my understanding.

What you describe in the second paragraph sounds like something that would occur only in a dysfunctional workplace with dysfunctional manager and dysfunctional colleagues. (And even then I have a hard time seeing it happen for long -- someone is going to get annoyed doing all those code reviews of pointless changes and put a stop to it).

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

#76

Post by notacoward »

OP mentions three things: staging their work, velocity, and sense of agency/ownership. All three are problematic. Often those who have worked with a component the longest and/or wrote significant parts of it become its maintainers, either formally or de facto. As a maintainer (I've been one myself) it's simply easier to get commits in, not necessarily because you're better at the work but because of the role itself. You never have to re-work your commits to conform to someone else's idea of how things should work. People trust you, so reviews are often cursory. Many maintainers return that courtesy by subjecting others' work to excruciating review, slowing them down. Sometimes it's intentional, sometimes not, but the result's the same. Also, a maintainer often has many commits that started off as someone else's idea but that person didn'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 "top performers" because of something that's part of the role seems a bit circular.

So much for velocity and ownership. As for the part about staging commits, I'd like to see some evidence. In my experience there's no difference, or sometimes the maintainers are even less 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'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.

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

#78

Post by kevinmchugh »

watwut wrote: post #43
codegladiator wrote: post #30

Earlier quoted context omitted.

I worked as a contractor with some companies and peer coded with their engineers. What I found was that its not just procrastination. Many folks are just afraid to commit code, like literally scared and I could never get a real reason for that. At one point I added some code based on the direction what requirements were taking. But I could not convince him to commit it. So we finally agreed to let it be there comment…

Cause reasons for fear are not something people would tell you. I was in similar state twice and neither time I would be eager explain that to someone external. I was "afraid" to commit in a team where code review evolved into huge micro-management with inconsistent requirements on what good code looks like. The reviewer iteratively forced you to change it again and again each time with "this is bad code cant go in"…

Obviously these are people problems. If my next team suffers from your first problem, I might try to ease it by introducing a code formatting tool like prettier. I don't always love the choices those tools make, but I do love eliminating that class of PR comment.

It doesn't eliminate the people problem, but it does limit its scope.

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

#79

Post by vasilakisfil »

Uehreka wrote: post #26
zug_zug wrote: post #6

Lol, when I worked at a unicorn one of my buddies got an award for "most testing code commits" He confided after drinks it was because he didn't know how to squash/amend his commits. So I'm not so sure about that metric....

Is that why people are always saying you should squash commits? To help with collecting metrics?! I view it as a clear antipattern (since the history within a branch can be valuable later if you need to cherry-pick apart a feature or find a bug with git-bisect) and have asked superiors in numerous places why they require it, and the response is usually a vague mention of “it cleans things up” and “history isn’t impor…

squashing commits make history important actually. The history how you reached the solution in your branch is not important, I am not interested in a wip commit which could indeed have a valid commit message, but still not final. Only the committed is interested into that.

So I think just before merging squashing the commits makes completely sense. Before that the committer is free to do whatever he/she likes.

Of course in the case the diff of files is so big that make multiple commits sensible, means that the PR is not broken correctly. Then, it's fine to have multiple commits, but the problem is elsewhere not in squashing them.

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

#80

Post by AlanSE »

> 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.

One consistent tension is that the old-hand developers have a "mental issue queue" that is enormous, but without fail, every time, they just can't be transferred.

These can'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'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't propose a solution that's any better.

Once you'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.

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.

EDIT: but fixing unrelated issues as you go is bad, don't do it!

Post reply on HN