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?

#51

Post by est31 » Mon, Dec 07, 2020, 8:53 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…

> I think, often, those folks solve problems by adding more code.

Indeed I think this is a big component in differences in how many lines someone is adding. Some people solve problems by copying code and them modifying it, while others try to come up with general solutions to remove duplication. It's two different styles, both with their advantages and disadvantages. I think duplicating gets you to an initial prototype more quickly, while general solutions are more maintainable as you only have to fix a bug at one position.

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

#52

Post by jayd16 » Mon, Dec 07, 2020, 8:54 AM UTC

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"…

I know I've been testy with a coworker or junior before but its so counter productive to have a workplace with fear. Process can lead to trust and confidence so I try to focus on identifying and improving that (as well as mentoring around risky patterns and such.) Test, reviews, tooling etc. If simple mistakes are effecting the team, its really a process failure.

Fear driven development is toxic.

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

#53

Post by jayd16 » Mon, Dec 07, 2020, 9:05 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 its just people protecting their egos and hiding their dev process. I've never been reading the commit history and thought, "boy I wish these were squashed." Much more often I wish commits were in smaller more reviewable bites.

I understand why its there. People want to sweep the details away. I feel it about my own commits as well. However, if I have to go back and read the history, I'd much rather read the ground truth.

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

#54

Post by sgtnoodle » Mon, Dec 07, 2020, 9:10 AM UTC

sgtnoodle wrote: post #50

watwut wrote: post #43

Earlier quoted context omitted.

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"…

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 "artesianal coding energy". By the time the code reviewer looks at the code, they know what it's supposed to do and why it was written that way. As a pleasant bonus, I usually code about 3x faster when I have the document to reference.

I try to get new hires into this habit as early as possible to varying degrees of success. The folk that embrace it tend to be very productive; I don't know if it's causation or just correlation though. I have a slide deck to emphasize function over form, titled "Writing Mediocre Architecture Documents". It's a cult classic hit.

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

#55

Post by grey-area » Mon, Dec 07, 2020, 9:44 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…

No, that's not why.

If your workplace requires just 1 commit per change, no matter what the scope, that doesn't make a lot of sense, but there's a lot of room between never squashing and squashing all changes always to 1 commit. Both those extreme approaches don't make much sense to me. Some history is important, some is not.

Squashing commits doesn't have to mean turning 50 commits into 1. It can mean reordering, squashing some commits, tidying up commit messages and generally editing until the set of changes is clear and coherent. This lets you commit early and often during development on an unpublished branch without concern, then tidy that up into a coherent set of changes for readers (including your future self). The absolute numbers don't really matter, for me at least it's more about reorganising and editing changes to read coherently and be properly separated. For example if you need steps 1,2,3,4 to make a change, keep those separate but don't include 2a,2b,2c which were exploring 2 and finding a few places you missed a change when you tested it.

I see it as basic respect for future readers, much as you might revise and edit an essay or novel before publication, revising and editing your code changes at least once often makes them better and clearer.

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

#56

Post by m_rpn » Mon, Dec 07, 2020, 9:57 AM UTC

I hope that someday this "version control craze" 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 "HISTORY", and amend each misdoing as you see fit. We need to remember what is our job: writing software that makes sense, not commiting code.

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

#57

Post by NotAnAccountNO » Mon, Dec 07, 2020, 10:23 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?

What do you consider to be large and infrequent? I see so many micro-commits that I start to wonder if some competition is going on...

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

#58

Post by atraac » Mon, Dec 07, 2020, 10:47 AM UTC

cryptica wrote: post #46

Wow, the premise of this article is very wrong; it's deeply concerning that people are falling for this. Those who make a lot of commits are not top performers, they are mostly engineers who are overly concerned with their 'optics'; they are engineers who are good at projecting themselves as 'top performers' but if you actually look at the results of their work a few years down the line, you will see that they are in…

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

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

#59

Post by jfoutz » Mon, Dec 07, 2020, 11:00 AM UTC

est31 wrote: post #51

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…

> I think, often, those folks solve problems by adding more code. Indeed I think this is a big component in differences in how many lines someone is adding. Some people solve problems by copying code and them modifying it, while others try to come up with general solutions to remove duplication. It's two different styles, both with their advantages and disadvantages. I think duplicating gets you to an initial prototy…

Uh, kinda.I think I get what you're saying, but I think you're framing it in a fairly shallow way.

I think someone good will avoid just copy and pasting the code. Shallow similarity makes it easy to thread a boolean or do something tricky with dependency injection. What I'm getting at is folks who are very capable, very fast programmers. if things aren't easy to reuse, they'll just go ahead and implement a whole new subsystem with different logs, metrics and error conditions.

I guess an example might be a type checker versus a compile time evaluator. They have a lot in common. But they're different. Adding another traversal of the AST isn't that big of a deal, really. But, there will come a time when all those passes start to be an issue, they have a lot in common. Maybe it's better to fold them all up into one or two passes.

Sometimes things are complicated. Sometimes you need to hold all that complexity in your head at once and really pick out the commonality. But that's rare. Just adding more code is a great answer for a long, long time.

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

#60

Post by jariel » Mon, Dec 07, 2020, 11:02 AM UTC

lmm wrote: post #8

jariel wrote: post #2

Not to take away from the premise offered in the article ... 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 'productive' and 'leave the code better', which lends us to believe 'top performers'. Surely, this might be true but I think within a specific context. If find solving new or novel problems invol…

Why not? Doing experimental things that might not work out, or need radical revisions, is exactly when VCS helps the most.

Because the scratch code is usually pointless, it's the 'key notes' that matter.

200 lines of crazyballs scratch code is not 'the insight' really 'the insight' was that the API works 'really slowly upon first iteration, but very quickly after n iterations' - which implies x, y, z possible courses of action.

I suppose you could jam it in the VCS but I've never personally cared.

Now that I think about it ... it's interesting because that's definitely not what a VCS is for, though it could absolutely be used in that way.

A VCS really is not that great to store arbitrary, secondary related activity and notes wherein 'the code' really isn't the important thing.

What's missing here is really a form of document/information sharing that just hasn't caught on very well. Or perhaps I'm still caught up in the ridiculous Confluence/Atlassian garbage, which is the worst wiki ever made.