[Edit: deleted mistaken impression here.]
I also get Citogenesis. This also gets abused in many fields. Think Cargo Cults, and stories of performance improving every time the lights go on and off, and how we're all evil because people in lab tests electrocute their test subjects.
That said, it is hard for anyone who has been in the world for a while to disbelieve the 10x programmers. We all have met them. They really are that much better. And they really can solve problems that others can't. They may not be better for every situation (Example: Following a structured testing methodology that requires a lot of human input) but they do exist. It would take a lot of evidence to prove that they DON'T.
I'm about halfway thru reading it, some of the findings presented are that TDD studies either aren't very good or give inconclusive results; that a number of code complexity metrics don't predict bug rates any better than file size does; that bug rates are correlated with how well organizational structure matches code structure; and that competent PHP programmers do in fact exist.
I did like the paper on code size very much. The principle that code size is the best measurement of complexity and a good predictor of error rates is probably the finding I'd name if I had to answer my own "name one that isn't folklore" question. At least that one has multiple studies behind it. Even so, most of them (that I've seen) aren't very good.
Article author here. Agree with your first para, so the above has me puzzled, a bit.
Would you please expand: what impressions do you think the article gives, that are misleading? (And if possible: what do you see or hear that makes you think they are misleading?)
You place so much emphasis on dismantling the 10x claim (writing an entire book about it) rather than software research in general, that an observer might reasonably be left with the impression that there's something more "mythy" about that claim than others. If so, I'd say that's misleading.
Folklore isn't ipso facto false. If folklore gets repeated as persistently as 10x does, I'd say that speaks weakly in its favor. (Please note that I said "weakly".) Because of this, I don't think it's irrational to continue to favor that view, even after debunking those studies. For one thing, the opposite claim is even less supported by data. For another, it fits loosely with my experience and that of others I talk to. Experience in the field may not be controlled measurement, but that doesn't make it rational to dismiss it.
I do think there's something to the 10x claim about individuals; I think interaction between individuals is even more important—100x, one might metaphorically say—and that question is even less amenable to formal study. I doubt that we'll ever see convincing quantitative results on either of these things. Building teams will remain an art, and folklore and myth are the stuff that art is made of.
"Leprechauns" is by no means entirely about 10x developers.
In it I also tackle things like the "exponentially increasing cost of bugs" claim, the Cone of Uncertainty, the "software crisis", the successive mythical reconstructions of the Waterfall bogeyman, the limitations of the "empirically based software engineering" movement and specifically the problem of discipline envy.
If it had only been the 10x thing that turned out to be ill-supported I wouldn't have gotten my knickers all atwist. My beef is precisely that when you look closely most of software engineering looks awfully like pseudoscience.
This article is, in a way, Chapter 1 of the next book, in which I'd look beyond "academic" myths, and try to confront a broader picture of how the software community thinks about itself, and how that perpetuates some of the problems we've been bitching about for decades. (And some of these problems turned out to be non-existent; other very real ones barely rate a nod from academia. That is also part of the problem.)
I may have asked you this before, but do you know of any finding in the research literature that you don't consider pseudoscience? The only one I know of that might come close is research on code size. I've heard that the literature on code inspections is good, but that may just be another myth.