Construx

Is this list intended to imply that a so-called 10x programmer does not have these qualities? Or has the opposite qualities? Do 10x programmers kill puppies?

In 40 years working as a programmer I have never heard a programmer call themselves “10x” except ironically, as a joke. The term seems to come from management, and maybe recruiters, as a shorthand for the obvious (and often large) differences in programmer productivity (according to multiple metrics) observed in both studies and in practice. Steve McConnell wrote a good article about it, you can find several others.

https://www.construx.com/blog/the-origins-of-10x-how-valid-is-the-underlying-research/

Although no programmers go around calling themselves 10x or wearing an exclusive patch or tattoo this subject keeps coming up, as if the mere 1X programmers were oppressed and offended. In actual programming teams and projects everyone contributes in different ways, some people have more experience and skills than others, and we usually recognize the stars and the less-skilled. Programmer productivity is highly situational: I may work 10x faster than a colleague on project A, but change things up and I may be the junior on the team.

Perpetuating this imaginary class system as if there’s a 10x caste pushing everyone else down, and consoling those who imagine oppression with feel-good lists like this can only cause more friction and resentment among programmers, when teams work best when everyone works together and helps…

Well, if the author kindof hasn't seen it, I guess I should ignore this stuff:

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, 1981. Software Engineering Economics, Boston, Mass.: Addison Wesley, 1981.

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.…

Certainly, experience is a reasonable way to evaluate ideas, but that doesn't mean the evaluation is valid. I agree that the bloodletting example was meant to undercut the assertion. I also think the assertion - judging only on experience - is incorrect, and that the example is a valid one. We have many examples where experience lead to incorrect conclusions.

By experience, Aristotle argued that things in motion come to rest. Everyone knew that ... until Galileo, further codified by Newton. One's experience can be wrong. Hence the reason for software usability research. See "Making Software", edited by Greg Wilson, for lay results of some of that research. Here's an example of a more direct, empirical study: http://neverworkintheory.org/2011/10/24/an-empirical-comparison-of-the-accuracy-rates-of-novices-using-the-quorum-perl-and-randomo-programming-languages.html .

You write "human beings rely on experience at all times to evaluate." We also use comparison testing, as with that paper link I gave you. A hope is to minimize preconceptions based on one's experience. We see this in the medical field all the time, where we find that even single blind testing can unduly affect the results.

We also use prediction to evaluate. Einstein predicted a certain bending of light around the sun, which wasn't based on experience.

Therefore, I place a weak meaning to "human beings rely on experience at all times to evaluate." We use it to guide our understanding, but also use other…

Tom DeMarco, of Peopleware fame, wrote a book called "Controlling Software Projects: Management, Measurement, and Estimation". He has, in some ways, rejected his ideas in that book.

In this article, "Software Engineering: An Idea Whose Time Has Come and Gone?" http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf he states:

"My early metrics book, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982), played a role in the way many budding software engineers quantified work and planned their projects. In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no."

The tl;dr of his article is that the software projects that require tight cost control are the ones delivering little or no marginal value. That is,

"To understand control’s real role, you need to distinguish between two drastically different kinds of projects:

■ Project A will eventually cost about a million dollars and produce value of around $1.1 million.

■ Project B will eventually cost about a million dollars and produce value of more than $50 million.

What’s immediately apparent is that control is really important for Project A but almost not at all
important for Project B. This leads us to the odd
conclusion that strict control is something that…

I appreciate the overall point of the article, but have a gripe. The author (and others) gets it wrong on the original meaning of 10x. A 10x engineer isn't someone who is 10x as productive as their peers, they are 10x as productive as their worst performing peer. The original study the author links to compares the difference of work between the fastest code and the slowest code. The fast debugger and the slow debugger.

When we talk about 10X, it should be about comparing it to the least productive team member - the 1X. There is always going to be a 1X person on the team. That's not bad if the team average is 1.5-2X, but if the average and discrepancy gets large enough, you're going to have the 10-100X team member who gets a lot done.

Also, not all work is equal. The 10X engineer who is only 10X in programming may be a 1X in collaboration or documentation. That's not a good dynamic, either. Again, appreciate the point of the article, "build great teams", but we need the 10X person in each task to do that. If the build pipeline is slow and costing us money, I need the best people on the team to go figure that out. And, I need our worst engineer who is still learning to be involved so that they can grow their skills. Become a 1.1x, 1.2x, etc.

Hat tip to these articles on 10x engineer studies: https://jasoncrawford.org/10x-engineers https://www.construx.com/blog/productivity-variations-among-software-developers-and-teams-the-origin-of-10x/

Putting aside all the ad-hominem and everything-is-terrible, I think I learned a lot from following the references Tef makes in this talk.

Some references (sorry for the formatting, if this becomes a thing I'll do the wiki and the logo):

Slides:

https://github.com/tef/emfcamp2012/raw/master/programming_is_terrible.pdf

Blub Paradox:

http://www.paulgraham.com/avg.html

http://c2.com/cgi/wiki?BlubParadox

Perl and 9/11:

http://www.paulgraham.com/hijack.html

10x:

http://hfs.sagepub.com/content/16/1/70.short

http://www.construx.com/10x_Software_Development/Origins_of_10X_%E2%80%93_How_Valid_is_the_Underlying_Research_/

http://www.construx.com/10x_Software_Development/Productivity_Variations_Among_Software_Developers_and_Teams__The_Origin_of_10x/

Waterfall (same pdf, linking from 2 sources):

http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf

Conway's law:

http://en.wikipedia.org/wiki/Conway%27s_law

Unrelated, Pournelle's Iron Law of Bureaucracy (I just like this law):

http://www.jerrypournelle.com/reports/jerryp/iron.html

X-Y Problem:

http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem

Atwood, Don't Learn to Code:

http://blog.codinghorror.com/please-dont-learn-to-code/

Wason selection…