The problem here is that the concept got off on the wrong foot and has stayed on the wrong foot since then. The conceptualization of software developers as some sort of industrial worker who churns out widgets all day long is simply ludicrous. In the days back when a lot of software development involved just doing the same thing repeatedly for hire the measurement of "productivity" based on "output" at least had some basis in reality. But that era didn't last long, modern software development is an incredibly automated endeavor. We use automation (compilers, linkers, IDEs, unit test frameworks, and so on and so on) to take out a lot of the drudgery that previous generations had to grapple with more directly. Today productivity in software development is not about churning out lines of code (even assuming it ever was) it's about building stuff that has a high value (to users/customers et al) and low cost (operationally, tech debt. wise, and so forth). And there, of course, the range in productivity spans not just one but
many orders of magnitude between the highest and lowest tier of coders.
There is a small group of folks (charitably tiny, uncharitably maybe like 1/4 of all devs) who on average contribute negligible or even net negative overall value vs. cost to the code base as they work. And there are some folks whose individual work has a value of upwards of several billion dollars. In between there are perhaps bunches but it would be a stretch to imagine that there were only one bunch where the vast majority of other devs were collected within a single order of magnitude in terms of the value of their work.
And, make no mistake, I'm not just talking about moving up the "hierarchy" or the management chain in terms of value. Even if you restrict your dev. sample to just individual contributors with more or less identical work responsibilities (instead of say, junior intern vs. principal architect or somesuch) you will still find many orders of magnitude difference in value and quality of work.
The reason why this isn't objectively obvious is that so much of software is invisible. Yes, you can in principle read all the source code but in practice that's not tenable. And we still do not have all of the tools, models, or even terminology to concretely break down the structure of complex software systems into representations that aren't extraordinarily handwavy and overly simplistic basically almost immediately (compare, for example, an electronics wiring diagram versus a UML diagram or a layer representation). That coupled with the fact that software development is a creative and even artistic endeavor where the value of some piece of work can vary greatly between otherwise very similar examples (which is much less true of, say, bridges or diesel generators) means that estimating the value of a given developer's work a priori is enormously difficult. Indeed, that also explains why hiring is such a constant struggle.