I think those numbers are probably based on source code contributions. I can believe those statistics, what is missing is the why.
Some people just aren’t good programmers. I knew some of those, one turned out to be great at testing instead. Junior programmers, new programmers (to the project/company or language or field) are slow and they might get better. Then you have burnout. There was a story here about a guy that didn’t contribute much because he mentored and pair programmed and did other tasks to make the life of other programmers easy.
There are a lot of good reasons so before you go optimizing on numbers, check the why.
> those numbers are probably based on source code contributions
The other part of that is a "more senior developers tend to do things outside of things seen with git commit." Meetings, commenting on code reviews, and documentation are the first three "not tracked in git" that come to mind.
Other things like proof of concepts may not find their way to the actual project repos (and thus has little visibility in the report).
That said, there are certainly developers who are at the 0.1x median even when they spend their full time working on solving that problem. They just work really slowly.
A long time ago I was tasked to trace technicians' work, especially those who where called during the night because of some urgency on French telecom networks.
Astonishingly before that time, it was not known who worked, how many times and what was the outcome of the intervention.
It turns out that only 5 people were working on the 15 in the team.
I remember a union member pleading with me with tears in his eyes to recruit more people because there was too much work. Indeed he was one of the five people who worked hard.
Curiously those five never complained about the others' behavior, on the contrary, the team reacted strongly against attempts at putting some light on what was going on.
> Curiously those five never complained about the others' behavior, on the contrary, the team reacted strongly against attempts at putting some light on what was going on.
What was their manager doing? They must have had some way they measured work, were the other people faking reports or something, or was it more that their definitions of work varied?
I don't think there is another paper - that's the only one linked from their participation portal. The grandiose claims and lack of documented process make me very skeptical here. I've done some similar analysis as part of acquisitions, and almost all of the work was in ensuring data quality - did I actually cover every repo everyone commits to, does a person use multiple git configs with different emails, etc.
"We have data on the performance of >50K engineers from 100s of companies."
Sounds to me like "we have some very common performance metrics on a huge number of people...the great majority of whom are old hands at gaming metrics".
If you are looking to downsize - the first places to look are both ends of the bell curves for well-known metrics, both ends of the pay curve, and upstream from the worst of the bad decisions, drama, and tensions.
johntdaly|1 year ago
Some people just aren’t good programmers. I knew some of those, one turned out to be great at testing instead. Junior programmers, new programmers (to the project/company or language or field) are slow and they might get better. Then you have burnout. There was a story here about a guy that didn’t contribute much because he mentored and pair programmed and did other tasks to make the life of other programmers easy.
There are a lot of good reasons so before you go optimizing on numbers, check the why.
shagie|1 year ago
The other part of that is a "more senior developers tend to do things outside of things seen with git commit." Meetings, commenting on code reviews, and documentation are the first three "not tracked in git" that come to mind.
Other things like proof of concepts may not find their way to the actual project repos (and thus has little visibility in the report).
That said, there are certainly developers who are at the 0.1x median even when they spend their full time working on solving that problem. They just work really slowly.
JPLeRouzic|1 year ago
Astonishingly before that time, it was not known who worked, how many times and what was the outcome of the intervention.
It turns out that only 5 people were working on the 15 in the team.
I remember a union member pleading with me with tears in his eyes to recruit more people because there was too much work. Indeed he was one of the five people who worked hard.
Curiously those five never complained about the others' behavior, on the contrary, the team reacted strongly against attempts at putting some light on what was going on.
acdha|1 year ago
What was their manager doing? They must have had some way they measured work, were the other people faking reports or something, or was it more that their definitions of work varied?
shagie|1 year ago
They've got a different paper at https://arxiv.org/abs/2409.15152 ... is there an equivalent for the ghost engineers data?
itsdrewmiller|1 year ago
bell-cot|1 year ago
Sounds to me like "we have some very common performance metrics on a huge number of people...the great majority of whom are old hands at gaming metrics".
If you are looking to downsize - the first places to look are both ends of the bell curves for well-known metrics, both ends of the pay curve, and upstream from the worst of the bad decisions, drama, and tensions.
unknown|1 year ago
[deleted]