There are no 10x developers, but there are 1/10 ones

There are a small few very gifted people who are prolific coders, and there are a small few very terrible coders who manage to get a job but can't produce decent work.

But FAR more often than spotting either category "in the wild", in my own experience, I have watched poor management turn a productive developer into an unproductive one, or watched circumstance and luck turn someone who's not natually great into a central and productive team member.

I would say, blanket generalization, that at any company that has more than 5-10 developers, team dynamics and management are 10x more important than whether individual programmers are rock stars or duds.

I guess I don't get it. This Ph.D candidate was recommended by the previous CTO and was the one spearheading the framework transition...and then was fired after 2 weeks? But junior devs at the previous firm were given months to get up to speed?

I'm reminded of a paper [1] that "discovered a test which divides programming sheep from non-programming goats." The claim is that there are two distinct populations of people (those who can programming and those who inherently cannot). Each population has its own variance, e.g. as the OP mentions, the best programmer in each population might be 30-40% better than a lower-tier programmer in the same population. But the average programmer in the "can program" population is a magnitude better than the average progammer in the "can't program" population. This seems to closely match what the OP is describing.

[1] http://www.eis.mdx.ac.uk/research/PhDArea/saeed/

2 weeks vs 30 minutes is "a little slow"?

Sounding a bit mercenary but if the ROI on your investment is not high then you abandon the investment and find another one.

It sounds like this developer was not returning a good enough ROI (and believe me I hate using that term with regards to people) on the educational investment being made into him, maybe they needed him to get up to speed quickly and it just wasn't happening.

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. 1968. "Exploratory Experimental Studies Comparing Online and Offline Programming Performance." Communications of the ACM 11, no. 1 (January): 3-11.

Sheil, B. A. 1981. “The Psychological Study of Programming,” Computing Surveys, Vol. 13. No. 1, March 1981.

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.

(References from http://www.construx.com/10x_Software_Development/Origins_of_...)