I actually thought this piece was pretty well-crafted. The fact that it's a parody of an artist hierarchy only makes it better, in my view. I like the fact that, for the most part, the hierarchy has little to do with actual coding competence and a lot more to do with reputation and business acumen. (I like it in the sense that I might Facebook "Like" an article on a natural disaster. I don't like the fact that it's true, but I like the fact that he had the insight to say it.)
Software is a pyramid, but it has a competence pyramid and a respect/autonomy pyramid, and they aren't always the same. To the extent that they line up, it has more to do with respect begetting competence (because you get better projects and learn more) than the other way around.
I came up with what I think is a good representation of the competence levels here: http://michaelochurch.wordpress.com/2012/01/26/the-trajector... . The short explanation of it is:
0.5 - 0.9: Rising adders, or people who are learning the ropes and developing the ability to contribute, in minor ways, to software projects. However, they'll perform poorly without structure and mentorship. Most college students are in this range.
1.0 - 1.4: Solid adders, who reliably can create software. They can fix bugs, add features, and solve almost all technical problems, although it might take a lot of time to do it, and the solutions might not jive with the rest of the architecture. Most professional programmers are in this tier.
1.5 - 1.9: Rising multipliers, who make other people more productive, have architectural sense on account of experience, and usually know more than one programming language and framework (and can compare different approaches). At 1.5, we're talking about the 90th percentile of professional programmers.
2.0 - 2.4: Solid multipliers. Very rare: perhaps 1 to 2 percent of professional programmers. These are people you could trust, if needed, to unilaterally lay out the architecture for a technology company. (You'll want to hire specialists at some point, but a 2.0-level generalist can take you into the tens of millions of dollars in revenue.) It takes 10 to 15 years, with very little slack or redundancy in the experience, to get here. Most people never do.
2.5 - 3.0+: Global multipliers. Very few people can even evaluate talent at this level, which usually takes 20+ years to attain. At this level, most programmers have become expert in multiple specialties and developed, at the least, a world-class interdisciplinary knowledge (i.e. they might not be the world leader in X and Y, but there's no one out there who exceeds them on a project that involves both).
The success/respect hierarchy is somewhat different. I'd say it looks like this. Since business people have a huge say in where one actually lands, it diverges from the competence ladder as one goes up. The first number is where one generally needs to be on the 0.0-to-3.0 competence scale and the second is where one is perceived to be, mostly by business types.
Amateur (0.6 / 0.5): knows a few things about computer science, but not yet employable as a professional programmer. You might let this person transition to an engineering role over 12 months if they already work at your company in good standing.
Low worker (0.9 / 0.8): Can program, but with no real autonomy. Given tiny go-for projects with same-day deadlines, in addition to stuff that no one wants to do. Usually gets non-programming grunt work. It's nearly impossible to improve from this low-prole status, because you won't get decent work.
Mid worker (1.2 / 1.0): Average professional programmer. This is where the "5:01 engineers" who carry out their assigned work but don't make extra efforts to learn more will usually end up.
High worker (1.5 / 1.2): Above-average programmer. Usually has a title like "Senior Software Engineer". Capable of working with high levels of autonomy; usually trusted to work with low (but nonzero) levels. Still involves no influence over tools, product direction, or architecture. This is a frustrating level, because your actual competence is 1.5-2.0+ (top 10%) but you're still treated like a 1.3-ish Java jockey.
X Who Programs (?? / 1.5): Engineer who develops a credibility that is independent of software and thereby improves his software career. Data science (X = statistics) is one way to do this. Another is to become a PM, a startup founder, or a financial quant. This step has little to do with engineering per se. It's what you do when you realize that leveling up as an engineer isn't possible unless you get the highest quality of work, and that you need an engineering-independent credibility in order to convince bosses that you're capable of high-quality software work.
Manager-equivalent (?? / 2.0): To get to this level and beyond, it's no longer necessary to improve as a software engineer-- it will help, in the long run, to be competent, but it's not required-- because you can shut down people who know better than you. You don't need to be at 2.0 or higher, but executives will assume that you are. At this level, management considers you to be one of the best programmers in the company, but adopts you as "one of us". Your title is usually something like "Staff Software Engineer" or "Principal Architect". You've probably reached something that looks like "Freedom Zero": you're considered too valuable to fire, so you can work on whatever you want. However, there are still soft social pressures to suit the needs of management, and if you ignore those, while you won't be fired, you'll be out of "the club".
Executive-equivalent (?? / 2.5): Very rare. There might be five thousand 2.5+ software engineers in the world, and there are about few hundred people (with some overlap, and some discrepancy on both sides) who can reliably make themselves be perceived as 2.5+. Your title is now ultra-prestigious, like " Fellow". Millions of dollars are routinely bet on your ambitions. Your name is frequently substituted into Chuck Norris jokes. You answer directly to the CTO and have the right to direct as much of the engineering organization as you wish. It's like being the VP/Eng, but with an added benefit, which is that you have an excuse (you're still an engineer) to code if you want to.