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?

#181

Post by jdlshore » Tue, Dec 08, 2020, 6:36 AM UTC

lucideer wrote: post #171

pydry wrote: post #119

Earlier quoted context omitted.

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…

> This sounds like a bad faith culture

Yes, that’s what blame culture is: a dysfunctional organizational culture where, when mistakes are made, the organizational priority is to find and punish those responsible. The consequence is CYA and finger pointing.

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

#182

Post by that_guy_iain » Tue, Dec 08, 2020, 8:17 AM UTC

temac wrote: post #178

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…

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

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

Well considering my assertion is the dev is just fast and producing the same quality as others. Carry on working.

> What happens when one of those fast-dev quit?

The company would need to replace them or have the team produce less work due to less works?

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

This seems like "What if, it is better that you don't do the job you were hired for but do a higher job without getting promoted and recognised for your skills?". Well one, is if a company wants their fast dev to teach others they should make them a coach or something along those lines. Secondly, just because they're fast doesn't mean they can teach, sometimes the reason they're fast is they have less interactions with people and therefore able to continually code without having to stop to talk to Jenny from Admin about how important a bug is (not actually a devs job, there should be product/project management for this).Maybe fast dev is fast because they've been there for longer and understand the system, then it's just a case of other devs need to ramp up. Lastly, maybe the fast dev doesn't want to do this other role and just likes programming.

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

#183

Post by that_guy_iain » Tue, Dec 08, 2020, 8:19 AM UTC

ben7799 wrote: post #173

Tehchops wrote: post #152

Earlier quoted context omitted.

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

Isn't that just how start ups code? You ship features fast and loose and then deal with the aftermath once the company is maturer? Wouldn't this be a case of the best business value is shipping fast and loose and a slow and careful dev with 10x less bugs but is 10x slower is not what the company needs?

There seems to be a time and place for everything.

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

#184

Post by qes » Tue, Dec 08, 2020, 8:34 AM UTC

AlanSE wrote: post #80

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

> old-hand developers have a "mental issue queue" that is enormous

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

Hello, friend, I see we know each other well.

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

#185

Post by WesolyKubeczek » Tue, Dec 08, 2020, 8:49 AM UTC

I worked once on a piece of software to track construction projects. The CEO was always grumbling about the pace of development, citing the example of programmers who added Gantt charts to it in two days, and why was I so much slower at “simpler” features.

Fast forward a couple of months, and we had a customer complain about the Gantt charts being off. I had a closer look at the thing, and it turned out that the bars on the chart had been drawn using the Math.random() function. They came out different each time you refreshed the page and were in no way related to the real thing.

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

#186

Post by hkt » Tue, Dec 08, 2020, 10:58 AM UTC

sova wrote: post #104

hkt wrote: post #94

Earlier quoted context omitted.

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

https://dl.acm.org/doi/pdf/10.1145/3386321 Check out pages 71:26 and 71:27 for "Codebase introduction and retention" between Clojure and Scala. I'd like to see more graphics like these to illustrate "lifespan of commits"

Those are great graphics. I really wouldn't mind my contributions being measured in this way - a sense I've never had a out commit metrics before.

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

#187

Post by notacoward » Tue, Dec 08, 2020, 12:36 PM UTC

temac wrote: post #179

notacoward wrote: post #166

Earlier quoted context omitted.

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

Well said. I guess it's a good example of how metrics can be useful but not definitive.

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

#188

Post by rendall » Tue, Dec 08, 2020, 2:24 PM UTC

giantg2 wrote: post #164

rendall wrote: post #130

Earlier quoted context omitted.

Why not?

Why won't I get back to that level? I have a kid, so I don't have any time to study outside of work or put in tons of extra hours. After years of being screwed over and passed over, I don't really have the drive/hope to get to that level since it wasn't rewarded the first time. Also, the work is very boring now and isn't transferrable to other groups or companies, so I don't have any interest in being an expert just…

> "... since it wasn't rewarded the first time"

Our industry, unfortunately, doesn't promote from within. We almost always have to leave the company to another that is willing to give you a better title and salary.

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

#189

Post by jl2718 » Tue, Dec 08, 2020, 3:28 PM UTC

I’m trying to understand the DevOps of this concept. Is everybody working in the same repo, or are these personal forks that get hammered until nice merged PRs can be submitted? Do devs complete whole features before submitting, or do they submit partial work that everybody else is trying to contribute to? Are multiple developers working on the same code modules, or have they been split out? Are there tests and interfaces written ahead of time, or do they do tasking by prose?

The goal of software management is to keep everybody productive. If you have an imbalance in commits or pull requests in the main repo/branch, that’s a strong sign of a broken process. Tasks should be given according to familiarity and skill so this doesn’t happen.

This also says something about software design. Good design is easy to split up. Bad design requires a ‘go to’ person. Therefore, a ‘go to’ person is by definition not a good software engineer, because their design was bad, and/or they never fixed it. And if it worked the first time, you wouldn’t have to ‘go to’ anybody.

The skill ladder of software engineering goes something like: watching, practicing, contributing, designing, teaching, leading. Every developer goes through this process from scratch in every project. Getting stuck is a problem (as is skipping steps). Preventing other people from progressing is a bigger problem.

Perhaps rethink this.

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

#190

Post by temac » Tue, Dec 08, 2020, 8:03 PM UTC

that_guy_iain wrote: post #182

temac wrote: post #178

Earlier quoted context omitted.

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

> What would those fast-dev do in a vacuum? Or with only clone of themselves coworkers. Well considering my assertion is the dev is just fast and producing the same quality as others. Carry on working. > What happens when one of those fast-dev quit? The company would need to replace them or have the team produce less work due to less works? > Final last thought: imagine you are actually a good fast-dev like you descr…

I'm not saying that the exact situation you describe can never happen, but I'm not 100% convinced it is all that frequent.

But if all your descriptions are precisely correct, then my opinion is that your conclusions broadly are too.

Simply, I will think and check a lot before projecting actual situations on that model. For now I don't have the feeling I've ever encountered anything like you describe. More often it was some of the variations I suggested, and maybe others.