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?

#171

Post by lucideer » Mon, Dec 07, 2020, 9:02 PM UTC

pydry wrote: post #119

lucideer wrote: post #83

Earlier quoted context omitted.

I'm not sure what "blame culture" is, but any professional software team should ideally have some kind of "accountability culture". Whatever the fallout from people feeling "blamed" may be, attrition of all of your genuine programming talent due to tech-debt-machine peers being promoted ahead of them is not exactly an ideal outcome either. What's more, very often genuine potential in naturally talented new programmer…

Blame culture is when bugs, downtime, etc. happen and people both look for somebody to blame and simultaneously look to exculpate their own behavior. It leads to CYA behavior, backstabbing and massive risk aversion. It can also lead to or be a result of a toxic work environment. In multi causal bugs it can lead to people downplaying causes which they had something to do with and exaggerating the effect that co-worker…

This sounds like a bad faith culture in general: i.e. "paying a price for mistakes", rather than "owning postmortems". Treating a mistake as an opportunity for punishment (be it purely social or otherwise), rather than for learning, is more about how you treat staff & peers than how you deal with mistakes.

> Accountability culture" sounds like it could be the same thing.

Can I ask what specific part of my description of accountability culture sounded like it lined up with your description of blame culture?

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

#172

Post by ericb » Mon, Dec 07, 2020, 9:02 PM UTC

mandeepj wrote: post #156

ericb wrote: 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…

^^^ It will only work where no one else is reviewing your code

I'm not so sure.

When you disagree in a code review with the "top performer with all the commits" it gets escalated to management, who sides with the "top performer" because they are a "top performer."

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

#173

Post by ben7799 » Mon, Dec 07, 2020, 9:15 PM UTC

Tehchops wrote: post #152

that_guy_iain wrote: post #143

Earlier quoted context omitted.

> 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. This is o…

> a good dev is someone who produces the most business value this this this. More code might equal more bugs, but if it's a net gain in business value everything else is a secondary concern. It doesn't mean you can just ship crap all the time. If customers start complaining/seeing errors/bad performance, business value decreases and there are going to be some $discussions. If developers are rewarded for shoveling gar…

This, there are company cultures where crap is shoveled and the investors buy it for a while.

The rock star thrives in this environment. The bugs don't catch up to them till later.

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

#174

Post by reificator » Mon, Dec 07, 2020, 9:26 PM UTC

chrisandchris wrote: post #40

reificator wrote: post #36

Earlier quoted context omitted.

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…

Clearly I am living in a bubble, because I cannot imagine working somewhere where I would rather be seen doing literally nothing than to do the exact thing I was hired for.

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

#175

Post by reificator » Mon, Dec 07, 2020, 9:32 PM UTC

sgtnoodle wrote: post #42

reificator wrote: post #36

Earlier quoted context omitted.

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?

By commit, I think the intended meaning is "put on a path that will ultimately affect production". For my current project, merging bad code typically means breaking a bunch of regression test suites for any coworkers that cut their branches at the wrong time. In more nefarious outcomes, it means a delayed software version release and, potentially, damaged UAV hardware at our test site. For my previous project, mergin…

If individuals are fearing the repercussions from doing their jobs on a safety critical system like that, then the process has already failed.

Your process needs to be so bulletproof that everyone involved feels absolutely sure that a defect will be caught. If there's any doubt in their minds then that part of the chain needs to be addressed and corrected.

I'm not saying that people shouldn't take it seriously or should get sloppy, but if you're worried that making a commit could end in disaster then you're moving too fast.

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

#176

Post by vnlmk » Mon, Dec 07, 2020, 9:35 PM UTC

ikiris wrote: post #159

ben7799 wrote: post #91

Earlier quoted context omitted.

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

Upvoted and then retracted due to the PC bullshit at the end. You had great points, you shouldn't ruin it with your bitterness about having to be professional.

"bullshit", unfounded accusations of bitterness, using "professional" as a euphemism for letting pushy people do what they want.

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

#177

Post by [deleted] » Mon, Dec 07, 2020, 9:59 PM UTC

kevmo314 wrote: post #93

ericb wrote: 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.

[deleted]

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

#178

Post by temac » Mon, Dec 07, 2020, 10:50 PM UTC

that_guy_iain wrote: post #143

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…

> 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. This is o…

Yet you can do a few simple thought experiments.

What would those fast-dev do in a vacuum? Or with only clone of themselves coworkers.

What happens when one of those fast-dev quit?

--

If everything is/would be fine, then yes, they are truly rockstars (in all the good meanings of that word and none of the bad). Or maybe merely decent among mediocre ones.

Otherwise, there is a free-rider aspect in their approach.

--

Also it can work only depending on the criticality level of the industry.

Ship broken crap quickly (but fix it quickly too)? Good if you are creating yet another social website maybe. Less good for e.g. medical devices.

--

One more point: the business value approach is not necessarily the only one to apply esp. if there are tech infrastructure components in what you ship. You can easily be stuck in local optimums too far from global ones, and fossilize some aspects of your product. See for example the classical http://blog.zorinaq.com/i-contribute-to-the-windows-kernel-w... that includes some example of death by thousands cut.

What I mean is that moving fast is partly in the eye of the evaluator. Maybe you implement what PM wants quickly, and that's cool, but maybe also doing only what PM wants is not the best thing for the project.

--

If you are easily able to plan things, have a good data model, and can develop quickly, probably you don't have a real code quality problem to begin with. At least not in the parts you contribute to. I don't actually distinguish the data model from "code" that much: it's all design.

--

Final last thought: imagine you are actually a good fast-dev like you describe, and your colleagues are less good, but imagine a case where the whole organization would actually benefit from you slowing down a bit and working on developing better way to work more efficiently with others or making them improve, overall yielding even more business value at the end. This can happen too.

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

#179

Post by temac » Mon, Dec 07, 2020, 10:57 PM UTC

notacoward wrote: post #166

temac wrote: post #131

Earlier quoted context omitted.

OTOH I'm tired of people who don't "have the time or knowledge to complete [their ideas]". Ideas are cheap. Show me the code. Asking, explicitly or implicitly, for others to "implement/finish" their ideas is easy. I would even call never finishing / polishing anything very disrespectful: I'm not (should not be) here to cleanup after "talented" individuals. This is detrimental to my own "ideas." So at least, if not an…

> Ideas are cheap. Show me the code. I mostly agree with you, but also don't want to be too developer-centric. Sometimes the ideas come from people who aren't primarily developers - production engineers, system architects, etc. Let's say an idea from such a person is fundamentally good and will benefit the project but they lack the time or skill to do more than prototype it. What should happen? (a) Drop it on the flo…

I kind of agree with you.

I was thinking of people perfectly able to do/finish the job. If that's not their job to begin with, they have another one, and can be evaluated on it. If it's just that their time is too precious to do it (and it can even be!) and they will actually bring value in another way, then so be it, but let's not overestimate the value on dev on that project compared to people actually doing the work. Because we are not talking about design vs production, we are usually talking about rough-high-level-design vs high level refinement/debugging + all-level-design + QA + iterating, rince and repeat...

And like I said: ideas are cheap. Fundamentally. Well, most ideas, but this would need a case by case judgment to recognize remarkable ones out of the mass, so I'll continue with my simplification that "ideas are cheap." If I say that a micro kernel still makes a lot of sense and should be the future of new OS / VMs / etc, well it is controversial, and maybe Linus won't agree, but maybe if just enough people put some efforts to develop an excellent and very successful system from that, maybe Hurd done right, while I simply get to my next idea, maybe if the system is eventually successful I should not be overly praised for that. Maybe the people who did the work should. The mere idea bringers will be judged on other aspects anyway, and it does not retire anything from all their contribution everywhere, maybe other activities, etc... I'm not trying to declare the superiority of development vs other things. I'm trying to explain that development is to be judged by development criteria.

And so in the end, counting the number of commits (or whatever), yes it is kind of an idiotic metric but maybe not as much as some people seem to think. I see it more like the estimation of complexity via the number of LOC approach: it's rough, you may need to apply various adjustments here and there if you look more closely, it may be biased by various non optimal feedback loops, it may lead to a few false positives and negatives, but it is still an interesting metric to begin to understand what is happening in a project.

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

#180

Post by temac » Mon, Dec 07, 2020, 11:31 PM UTC

strogonoff wrote: post #16

“Top performer” here means “top performer in a team, relatively to teammates”, which narrows the definition substantially. There are mysterious geniuses who can deliver a great piece of software just as an experiment/PoC out of the blue, but they don’t tend to shine in such environments—they could be founders or indie consultants, or it could be their side-project persona. (I.e., stating the obvious, if you are inten…

3 years latter good commit messages are extremely useful, and most of the time very short ones and/or giant commits are mostly useless.

I occasionally read back multiple pages commit message I wrote and wished I dumped even more info from my brain at the time.

If you work on small and short projects, you can do pretty much anything though.

Of course it can still be unreasonable, but that's quite like anything else. But if in doubt, I would say write more; because if you really track your time in a detailed way, you will see that the marginal additional time is often shorter than you feel. And it taking 1/3 of your time may even be justified in some cases (but maybe you should write some doc in another way then).

And I would not be so sure about it not magically making you better though: it is sometimes extremely useful to just write things down, quite like it is useful to explain a bug to a rubber duck.