DEV Community

Is this the gate you want to keep?

Heidi Waterhouse on August 17, 2017

Today on Twitter, I said: Heidi @ home @wiredferret ...
Collapse
 
val_baca profile image
Valentin Baca • Edited

The original "x" was the worst developer and the "10x dev" was the best developer in comparison; on some metrics the best was 25x or 5x or 10x, so "10x" was chosen as a catch-all to indicate that there was an order-of magnitude difference.

Somehow in all the talk around the "10x dev" the "x" became morphed into the "average" or "mediocre" developer, which is just wrong.

The original study that found huge variations in individual programming productivity was conducted in the late 1960s by Sackman, Erikson, and Grant (1968). They studied professional programmers with an average of 7 years’ experience and found that the ratio of initial coding time between the best and worst programmers was about 20 to 1; the ratio of debugging times over 25 to 1; of program size 5 to 1; and of program execution speed about 10 to 1. They found no relationship between a programmer’s amount of experience and code quality or productivity.

Detailed examination of Sackman, Erickson, and Grant's findings shows some flaws in their methodology... However, even after accounting for the flaws, their data still shows more than a 10-fold difference between the best programmers and the worst.

In years since the original study, the general finding that "There are order-of-magnitude differences among programmers" has been confirmed by many other studies of professional programmers (Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000)...
Augustine, N. R. 1979. "Augustine’s Laws and Major System Development Programs." Defense Systems Management Review: 50-76.

Boehm, Barry W., and Philip N. Papaccio. 1988. "Understanding and Controlling Software Costs." IEEE Transactions on Software Engineering SE-14, no. 10 (October): 1462-77.

Boehm, Barry, et al, 2000. Software Cost Estimation with Cocomo II, Boston, Mass.: Addison Wesley, 2000.

Boehm, Barry W., T. E. Gray, and T. Seewaldt. 1984. "Prototyping Versus Specifying: A Multiproject Experiment." IEEE Transactions on Software Engineering SE-10, no. 3 (May): 290-303. Also in Jones 1986b.

Card, David N. 1987. "A Software Technology Evaluation Program." Information and Software Technology 29, no. 6 (July/August): 291-300.

Curtis, Bill. 1981. "Substantiating Programmer Variability." Proceedings of the IEEE 69, no. 7: 846.

Curtis, Bill, et al. 1986. "Software Psychology: The Need for an Interdisciplinary Program." Proceedings of the IEEE 74, no. 8: 1092-1106.

DeMarco, Tom, and Timothy Lister. 1985. "Programmer Performance and the Effects of the Workplace." Proceedings of the 8th International Conference on Software Engineering. Washington, D.C.: IEEE Computer Society Press, 268-72.

DeMarco, Tom and Timothy Lister, 1999. Peopleware: Productive Projects and Teams, 2d Ed. New York: Dorset House, 1999.

Mills, Harlan D. 1983. Software Productivity. Boston, Mass.: Little, Brown.

Sackman, H., W.J. Erikson, and E. E. Grant. 1968. "Exploratory Experimental Studies Comparing Online and Offline Programming Performance." Communications of the ACM 11, no. 1 (January): 3-11.

Valett, J., and F. E. McGarry. 1989. "A Summary of Software Measurement Experiences in the Software Engineering Laboratory." Journal of Systems and Software 9, no. 2 (February): 137-48.

Weinberg, Gerald M., and Edward L. Schulman. 1974. "Goals and Performance in Computer Programming." Human Factors 16, no. 1 (February): 70-77.
Collapse
 
wiredferret profile image
Heidi Waterhouse

Thanks for bringing the footnotes. It makes my lapsed-academic heart so happy.

Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

...to content development, who has compiled a wordlist for our reading game that is rivaling most textbooks. (Seriously, I would NOT want the job of any of my company's content developers. I do not know how they do what they do.)

Great article!

Collapse
 
blaketweeted profile image
Blake Campbell

You bring up some really great points. Often when examining Tech companies people get overlooked for how valuable they really are to the success of the company. Cars are useless without key components, same goes for Tech teams.

If you are not actively courting the best support staff money can buy and paying them enough to show you respect them, you are, flatly, a fool.
I disagree with this statement because paying someone lots of money !== respect. Respect is more about treating them as a valuable member. You don't need the best team money can buy, you need a good team with great leadership.

Overall I think you did great on writing about the importance of the team as a whole! Looking forward to more from you.

Collapse
 
rhymes profile image
rhymes • Edited

I think the gist of what she meant was the following: you can think I'm valuable but if I, as an employee, can't make ends meet to reach the end of the month, you're telling me I am not valuable enough, and hence you're not respecting me enough :D

It's not about the absolute amount of money you pay yes, on that we agree, it's about being paid enough.

The same goes with the pay gap. If you have two people of different genders with the same skills and responsibilities and titles and one of the two is payed substantially less than the other you're not valuing both the same way. Even if to their faces you are equally nice and respecting.

The second the person less paid finds out is going to think you don't value them enough, and that's true.

I find very Basecamp's pay structure a very interesting experiment: m.signalvnoise.com/how-we-pay-peop...

Collapse
 
blaketweeted profile image
Blake Campbell

Yeah, that makes a lot more sense with that context.

Basecamp's pay is a great example of how compensation should be handled. I love how they pay the same regardless of location, that's amazing. Thank you for linking that!

Thread Thread
 
rhymes profile image
rhymes • Edited

Yeah Basecamp's strategy is very cool. The only minor flaw I can imagine is that people living in places in the world that are wildly more expensive than Chicago could be discouraged from applying but I reckon they are not that many and as you said, pay is not everything and Basecamp seems very transparent from day one ;-)

Collapse
 
wiredferret profile image
Heidi Waterhouse

Money does not substitute for respect, but it's a good proxy for how much a company values your contribution. Great leadership can only do so much about morale and retention in the face of knowing that you're paid half as much as the person on the other side of the room.

Collapse
 
weswedding profile image
Weston Wedding

I've poked around the Google for a bit and I'm having trouble really understanding what an "under-indexed coder" is.

Collapse
 
wiredferret profile image
Heidi Waterhouse

A person who belongs to a group that is under-represented in technology. If technology were really a level playing field, we would expect the representation of people of color, white women, disabled people, etc, to be about the same as in the general population. Since it's not, something is weird with both the pipeline and retention that is causing people to drop out at different rates. Many people prefer this to "minority", because, for instance, there is a tiny majority of women in the world, just not in tech.

medium.com/@duretti/how-to-get-eng...

Collapse
 
weswedding profile image
Weston Wedding

I understand now, thanks!

Collapse
 
antonfrattaroli profile image
Anton Frattaroli

I met a woman who was a QA tester. Together we made a 10x team. I married her. We don't work together anymore, but now my life is 10x for sure.

Collapse
 
wiredferret profile image
Heidi Waterhouse

A+ life choice.

Collapse
 
ben profile image
Ben Halpern

Great post. I totally agree and I think you articulated it wonderfully.

Can I ask a tangential question? What, in your mind, is the "tech industry" and what is a "tech job"?

Collapse
 
wiredferret profile image
Heidi Waterhouse

If this were an easy definition, we'd have less confusion. I think the tech industry is people who are making software (for the most part) and web/app stuff. If you ask someone what their company makes, and they say "an app that lets you", they're in the tech industry.

Tech JOBS are much bigger, because there are coders, ops people, UX, DBAs, etc doing technology-oriented jobs in manufacturing, sales, insurance, transportation, etc.

That said, when we say "people in tech", we generally (and wrongly) mean "people who make the internet".

Collapse
 
ben profile image
Ben Halpern

we generally (and wrongly) mean

I'm satisfied by this way of saying it. I'm annoyed by some of the semantics in the same way I'm kind of annoyed by the word "serverless" in relation to that computing trend. But I also need to accept that's what folks settled on and language is hard to control.

Again, great piece above.

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
weswedding profile image
Weston Wedding

You imply she is jealous, upset, or in denial. You make it personal.

You could have simply addressed her on a factual basis, but you decided to turn your response into a personal attack in many ways. Why is that?

Collapse
 
Sloan, the sloth mascot
Comment deleted
 
weswedding profile image
Weston Wedding

You made a neutral point about how software being developed literally couldn't exist without developers and that, therefore, there was a basis for valuing developers more than a manager. You made a rational argument.

That is a very different thing than going after her personally. Which is what you did by calling her jealous and upset and telling her she's in denial. All of these things which are entirely speculative and unarguably insulting.

Collapse
 
robdwaller profile image
Rob Waller

Good post.

Do you think this can depend on where you're doing tech and code? Say a product company based in Silicon Valley vs an agency based in London?

Collapse
 
wiredferret profile image
Heidi Waterhouse

It can, but I've worked with people from New Zealand to Bangalore to Boston, and it's a pervasive theme. Better some places, worse others, but never great.