Live data from Hacker News

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

swecareer.substack.com

91–100 of 194 posts

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

#91
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…

I've seen this over and over too.

Put a Non-technical VP/Manager in charge. Maybe someone who started out as a UI designer or non technical PM and then somehow became VP of engineering because they were an early loyal employee.

Charismatic coders will take advantage and the manager will eat it up. The "rock stars" commit tons of code put create massive tech debt. They write their own buggy versions of stuff they should have just imported industry standard OSS versions of. Rule evaluation engines, broken file formats, broken home grown encryption, broken distributed job systems, heavily broken home grown DB frameworks.

They'll have a huge bias towards terse code that doesn't make a lot of sense. Abuse of functional code. Everything is the opposite of KISS.

Everyone else on the team is just constantly fixing their showstopper level bugs, of which there are always many.

They talk a good game and management constantly thinks the rock star is super smart and the rest of the team is deficient.

Then the tech debt reaches ridiculous levels, or you get bought and different management comes in and sees right through it. Managers get let go, new managers don't buy the rock star story. Rock star gets frustrated, leaves for another company where they can pull the same trick, and puts all this inflated stuff on the resume that they wrote all this stuff they shouldn't have written. A new naive manager falls for it think they must be really smart cause they're never going to find out how broken all the stuff was.

All this is WAY easier for a rock start to pull off post around 2010 because the office culture in tech has become so PC that no one can be blamed for anything. Lots of stuff that used to get someone shown the door in my early career would not even get called out today at all.

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

#92

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…

Commented out code is a terrible idea. It is the reason you look at source code and see it filled with garbage. When you have a developer who has no confidence in their code then you ask the usual question about requirements, testing, code review, etc. If it's still not committed then there's clearly a developer issue to workout with management. When a developer fails to follow through on their tasks and takes extra…

> Commented out code is a terrible idea.

I have no idea what your context for such a statement is but I can tell you in my career as both an IC and now as pseudo-Management (Product Manager), commented out code has saved me many a times.

Why? Very simple scenario. We hit issue X, dev Y has what they think is a fix... but they are not super familiar with the code base. They put the fix it, and keep the prior function/logic commented out. If dev Z needs to review this (assuming dev Y has left the org), the history is right there.

The inverse is I have had to contact former employees to help me/us understand X. And anyone worth their salt isn't going to consult for free :).

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

#93
post #84
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…

> praised by management for the amount of work they produced Management literally can't tell the difference, sometimes even if it is a former dev. There are many ways to ship code faster. -Don't test -Don't worry about sanitizing inputs--extra effort slows you down. -Optimize for writing, not maintaining -Take a tech-debt loan. Bolt your feature somewhere convenient it doesn't belong. -Put on blinders. Your n+1 query…

> Avoid refactors

On the contrary, small refactors are a great way to boost commit count! Management once tried to boost productivity by rewarding commits. Our team basically started manually committing automatic refactorings. We won by a landslide, but I don't think the company did. I got a nice prize out of it though.

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

#94
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…

Maybe a proxy for good contributions is the lifespan of their contributions rather than frequency?

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

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

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

#96
post #26

Earlier quoted context omitted.

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…

To me it's rebase > squash > merge. Nobody wants to read a commit history and see a page-long list of "fix audit", "fix typo", "retry ci", "test: change foo", "Revert: test: change foo", "Revert: Revert: retry ci"... That's why you rebase into a sequence of logical, if fictional, worksteps. But if you can't do that, squash is second-best.

My preferred is rebase (exactly as you describe) but keeping the original fork point, (unless it becomes necessary to depend on some other later work from another branch, the original base or not) and then merge.

So you end up with a cleaned-up branch history via rebase, and a master branch that's similarly clean, with a higher level view of 'logical commits' that 'merge X feature', 'merge Y bug fix'.

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

#97
post #84

Earlier quoted context omitted.

> praised by management for the amount of work they produced Management literally can't tell the difference, sometimes even if it is a former dev. There are many ways to ship code faster. -Don't test -Don't worry about sanitizing inputs--extra effort slows you down. -Optimize for writing, not maintaining -Take a tech-debt loan. Bolt your feature somewhere convenient it doesn't belong. -Put on blinders. Your n+1 query…

> Avoid refactors On the contrary, small refactors are a great way to boost commit count! Management once tried to boost productivity by rewarding commits. Our team basically started manually committing automatic refactorings. We won by a landslide, but I don't think the company did. I got a nice prize out of it though.

Hah! That's some top performer thinking! I tip my hat to your team!

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

#99
post #84
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…

> praised by management for the amount of work they produced Management literally can't tell the difference, sometimes even if it is a former dev. There are many ways to ship code faster. -Don't test -Don't worry about sanitizing inputs--extra effort slows you down. -Optimize for writing, not maintaining -Take a tech-debt loan. Bolt your feature somewhere convenient it doesn't belong. -Put on blinders. Your n+1 query…

> -Don't test

In an environment that rewards commits, unit tests can be a source of many little commits.

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

#100
post #84
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…

> praised by management for the amount of work they produced Management literally can't tell the difference, sometimes even if it is a former dev. There are many ways to ship code faster. -Don't test -Don't worry about sanitizing inputs--extra effort slows you down. -Optimize for writing, not maintaining -Take a tech-debt loan. Bolt your feature somewhere convenient it doesn't belong. -Put on blinders. Your n+1 query…

the converse is also true, occasionally. depending on the business model, some engineers are too comfortable with a slow, methodical process. often, just getting something to work, despite accrued tech debt, helps a team iterate toward a better solution. if requirements or the rest of the realized architecture was perfectly understood from the beginning, then slow and methodical is the minimal risk implementation. but in the real world, that’s rarely the case. what i’m saying is that true talent is able to intuit when one approach is preferred over the other.
Post reply on HN