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?
They did nothing, essentially they don't care of customers, they only care for two things: 1. Having good relations with the technicians. 2. Having good relations with their managers.
> They must have had some way they measured work
They didn't care, a task that would require 1 hour could last one month, sometimes more.
> were the other people faking reports or something
There were no reports at all, hence why I was tasked to trace the technician activities with computers.
> was it more that their definitions of work varied?
I guess everybody knew what was going on, the upper hierarchy was happy that a relative outsider like me was involved. There was also a curious discrimination between technicians, some of them (the well-paid) worked little, and others who had a harder task were paid less.
All the technologies involved were shrouded in mysteries. Many people in management had the impression that the job required a high level of qualification (it did not) and that qualified people were rare.
"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.
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?
> What was their manager doing?
They did nothing, essentially they don't care of customers, they only care for two things: 1. Having good relations with the technicians. 2. Having good relations with their managers.
> They must have had some way they measured work
They didn't care, a task that would require 1 hour could last one month, sometimes more.
> were the other people faking reports or something
There were no reports at all, hence why I was tasked to trace the technician activities with computers.
> was it more that their definitions of work varied?
I guess everybody knew what was going on, the upper hierarchy was happy that a relative outsider like me was involved. There was also a curious discrimination between technicians, some of them (the well-paid) worked little, and others who had a harder task were paid less.
All the technologies involved were shrouded in mysteries. Many people in management had the impression that the job required a high level of qualification (it did not) and that qualified people were rare.
Is there another source for this information that isn't twitter with infographic style posts?
They've got a different paper at https://arxiv.org/abs/2409.15152 ... is there an equivalent for the ghost engineers data?
"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.