Why do most top performers have the highest count of commits and pull requests? • Hacker News Board

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

#31

Post by Others » Mon, Dec 07, 2020, 7:19 AM UTC

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…

I think that squashing commits sometimes make sense. Like is it worth retain two commits if the second one is just fixing the formatting, logs, or metrics from the first one?

Also in open source I think it can be easier to keep track of the history if one commit == one PR.

I agree people kinda just cargo cult it though, good to be thoughtful about the trade offs for your team or project.

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

#32

Post by FeepingCreature » Mon, Dec 07, 2020, 7:21 AM UTC

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…

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.

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

#33

Post by skinkestek » Mon, Dec 07, 2020, 7:22 AM UTC

bch wrote: post #12

stevekemp wrote: post #10

Earlier quoted context omitted.

Which reminds me of this story: https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

Which reminds me of this (attributed to Bill Gates): Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

Fun fact: in at least certain parts of offshore construction mass is used as a very reliable indicator - not of completion but of cost.

A simplified version:

- higher weight means more raw materials means more materials cost and time to assemble.

- higher weight means fewer cranes will be competing for the lifting operations, again driving up cost.

- and tangentially: higher weight of equipment also drives higher weight of supporting structures.

Which means if you can save a ton in equipment it can make a huge difference.

AFAIK and IIRC experienced engineers who work with calculations will have worked through decades of projects (either as part of the teams at the time or by reviewing budgets and bools afterwards) to compile cost calculations, but roughly if you tell those guys the type of the construction and the weight they already have a fair idea of the cost.

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

#34

Post by caymanjim » Mon, Dec 07, 2020, 7:24 AM UTC

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…

Commits should be squashed to clean up iterative work, corrections, etc. I commit constantly while developing and testing, especially if I want/need to let a CI pipeline do builds during development. It's good to squash them all when the work is ready to be merged, so that there's a single, clean, clearly explained, atomic commit to add functionality. No one gains anything from seeing a dozen work-in-progress/cleanup commits. The history of how I got to the merge point isn't important. A single unit of new, tested functionality that's ready to merge only needs one clear commit in most cases.

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

#35

Post by yudlejoza » Mon, Dec 07, 2020, 7:27 AM UTC

> ... top performers ... highest count of commits and pull requests

> ... define top performers as ... a go to person

So circular logic. Got it.

In a related story, why employed engineers have code contribution to the company that's way higher (actually infinitely higher) than those who are not in the company.

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

#36

Post by reificator » Mon, Dec 07, 2020, 7:30 AM UTC

codegladiator wrote: post #30

sgtnoodle wrote: post #27

Perhaps some of the more productive workers are the ones that don't hesitate to make necessary code changes, test the changes adequately, and then move on to the next thing. 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…

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…

Have I been working in a bubble?

I'll give a coworker a hard time for making large infrequent commits, but I've never seen someone afraid to commit code. This sounds like the value proposition for version control hasn't really clicked for them.

Are they comfortable branching?

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

#37

Post by sgtnoodle » Mon, Dec 07, 2020, 7:35 AM UTC

codegladiator wrote: post #30

sgtnoodle wrote: post #27

Perhaps some of the more productive workers are the ones that don't hesitate to make necessary code changes, test the changes adequately, and then move on to the next thing. 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…

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 team based on shifting requirements to the point that no one understands it fully, and any future changes are such a high priority that it's "faster" to test it manually or in production.

I am of course guilty of that myself on some pieces of code. I try to prioritize cleaning up expensive tech debt, though. When folk are hesitant to modify a piece of code, it's a strong indication that the code is due for refactoring. It's always worth it as long as you implement regression testing in the process.

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

#38

Post by jfoutz » Mon, Dec 07, 2020, 7:35 AM UTC

I've worked with some amazing programmers that produce fabulous amounts of code. and, often, that's who you need. I have been envious of their prodigious production. I think, often, those folks solve problems by adding more code.

I think, sometimes that mountain of code starts to become a liability. I'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)

if you buy the adage "make it work, make it right, make it fast", you'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).

Anyway, I'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'm super pleased that I've deleted about 2x the amount of code I've added but, that's maybe me protecting my ego.

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.

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

#39

Post by andy_ppp » Mon, Dec 07, 2020, 7:44 AM UTC

jfoutz wrote: post #38

I've worked with some amazing programmers that produce fabulous amounts of code. and, often, that's who you need. I have been envious of their prodigious production. I think, often, those folks solve problems by adding more code. I think, sometimes that mountain of code starts to become a liability. I'm a little better at reading a lot of code, consolidating, and fixing bugs. Importantly, fixing bugs without breaking…

Deleting code saves so much money for your organisation as it’s deleted for every person who touches the codebase! I don’t think this is ego protection at all, maybe the people who write shed loads of code are protecting their egos just a little.

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

#40

Post by chrisandchris » Mon, Dec 07, 2020, 7:46 AM UTC

reificator wrote: post #36

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…

Have I been working in a bubble? I'll give a coworker a hard time for making large infrequent commits, but I've never seen someone afraid to commit code. This sounds like the value proposition for version control hasn't really clicked for them. Are they comfortable branching?

I think it‘s less about version control and more about that the change is then associated with the employees name and if something ever goes wrong, it would be possible (easy?) to blame him therefore he‘s being scared about doing something because it could cause trouble for him somewhen in the future.

And, imho, that goes back to not enough testing nd no safety nets to check for code errors (like code review, static analysis, ...).