[geekjock]

I'm a developer and am right there with you. But if you're a decades-old corporation with 10,000 engineers, you need some set of signals to help guide improvements to tools and processes, right? This benefits developers, and there should be a set of signals to enable this.

[closeparen]

You need objective, measurable signals if you are concerned that developers might be confused or lying. Otherwise you can just ask us. Most people are happy to tell you what the pain points are in their workflow and how they compare to last year's. Maybe you need metrics to quantify specific complaints like "slow" or "crashes a lot." But I feel like most organizations doing this kind of measurement are looking for some kind of Freakonomics "developers think they want X, but what makes them better is actually Y" when they haven't even bothered to ask about, let alone implement, X.

[impute]

> You need objective, measurable signals if you are concerned that developers might be confused or lying. Otherwise you can just ask us

In an organization with hundreds or thousands of developers, there will be people either lying about how productive they are or genuinely think they are performing above average when they are not. It's like how 80% of people think they're above average drivers.

On the other hand, you may have excellent developers that are overly modest or not loud enough to sell themselves. They are truly exceptional and above the curve and should be rewarded for that. Some of the 20% of drivers that don't think they are above average may actually be above average.

Objective, measurable signals help to find the outliers at the ends of the curve that may otherwise be missed.

[closeparen]

It doesn't matter what percentile developer you are to guide improvements to tools and processes. It matters what slows you down.