Levels of programmers (2009)(codinghorror.com)
codinghorror.com
Levels of programmers (2009)
http://www.codinghorror.com/blog/2009/04/the-eight-levels-of-programmers.html
14 comments
But then Ken Rockwell has made rather a career out of making little sense himself, so a parody almost needs to be entirely self-contradictory in order to register as a parody. (Basic JPEG on a D70 is good enough for anybody, but you really do need a Hasselblad. Er, come again Ken? I have to fix photographers who try to believe everything he writes.)
The one you linked is also a parody, maybe you meant this one? http://www.kenrockwell.com/tech/7.htm which was later "distilled" to just 2 levels http://www.kenrockwell.com/tech/2-kinds-of-photographers.htm
I'm quite glad he says "tongue firmly planted in cheek", because the idea that a successful programmers are "Programmers who are both well known and have created entire businesses – perhaps even whole industries – around their code." is just plain silly.
I think what he means by success is "money", which might well work for him, but doesn't for many others.
I think what he means by success is "money", which might well work for him, but doesn't for many others.
I thought this was pretty insightful:
These programmers have given themselves the real freedom zero: the freedom to decide for themselves what they want to work on.
That is what it means to be successful. If you don't decide for yourself how you work, what you work on, and when, you're not a successful person. Perhaps as a statement about the shoddy state of our society, he includes the assumption that one has to be a business owner-- and rich-- to get there (which is not strictly true, as Valve is establishing with the success of open allocation).
These programmers have given themselves the real freedom zero: the freedom to decide for themselves what they want to work on.
That is what it means to be successful. If you don't decide for yourself how you work, what you work on, and when, you're not a successful person. Perhaps as a statement about the shoddy state of our society, he includes the assumption that one has to be a business owner-- and rich-- to get there (which is not strictly true, as Valve is establishing with the success of open allocation).
I'm pretty sure I'd consider Richard Stallman and Linus Torsvald to be "successful", without being business owners.
Right, and I acknowledged that in mentioning Valve. What you need is the freedom to work on what you want. Those guys are sufficiently well established as to have it. But that's very rare.
Knuth isn't dead.
He doesn't have email.
How much more dead do you want to the programming world? :-P
How much more dead do you want to the programming world? :-P
I guess that falls under Very few programmers ever achieve this level in their own lifetimes.
It's still bad, though.
It's still bad, though.
Eh, I needed that shot of wakeup adrenaline anyway.
Ditto. I did a panicked wikipedia check to make sure I hadn't missed something. Phew.
[deleted]
'Immortal Programmer' might have been a better title for that section.
And neither is Alan Kay.
not everyone wants to be a "Rockstar Programmer!!!11!!"
I want to know what I'm doing and why I'm doing it and why it works or doesn't work.
I don't want to be a rockstar, I want to be confident in my current abilities and in my ability to always learn more.
I want to know what I'm doing and why I'm doing it and why it works or doesn't work.
I don't want to be a rockstar, I want to be confident in my current abilities and in my ability to always learn more.
From my experience, 'Where do you see yourself in 5 years?' actually helps me quite a lot. The jokers are obvious, the money-chasers are obvious and the people who genuinely love what they do are obvious.
As an example, here are two two extremes of answers I've heard: "perhaps leading my own team, perhaps even starting my company" and "doing what I love: computers". The first one tells me that the candidate isn't interested in sticking around for long, the other tells me that this person will excel because they are naturally interested in computers and not just chasing the money. The second candidate is still here and doing really well, by the way.
The pattern I've noticed in response to this question is that those who mention something intrinsic related to the job, such as "doing what I love: computers" or "being the best programmer I can possibly be", usually do much, much better. On the other hand, the candidates chasing external rewards tend not to last long.
As an example, here are two two extremes of answers I've heard: "perhaps leading my own team, perhaps even starting my company" and "doing what I love: computers". The first one tells me that the candidate isn't interested in sticking around for long, the other tells me that this person will excel because they are naturally interested in computers and not just chasing the money. The second candidate is still here and doing really well, by the way.
The pattern I've noticed in response to this question is that those who mention something intrinsic related to the job, such as "doing what I love: computers" or "being the best programmer I can possibly be", usually do much, much better. On the other hand, the candidates chasing external rewards tend not to last long.
When I consider what my own answer to that question might be, I think the "doing what I love: computers" answer is a given. It's completely obvious to me that I'll still be doing what I love in 5 years. I usually take the question to mean, "Where do you expect to progress to in 5 years?"
Surely I'll still be doing what I love, but I hope I grow to take on more responsibility. If I'm not growing in my ability, then I might just be a bad programmer, and I probably don't love it anyway.
If I answer with "perhaps leading my own team", does that mean I don't love computers? (Nope.)
Surely I'll still be doing what I love, but I hope I grow to take on more responsibility. If I'm not growing in my ability, then I might just be a bad programmer, and I probably don't love it anyway.
If I answer with "perhaps leading my own team", does that mean I don't love computers? (Nope.)
One big problem with the laddering system (I know he doesn't intend to promote it) is that it encourages people to try to build the next Ruby-on-Rails. Whereas in the majority of cases, both the individual and the society are better off by taking an existing tool and doing gradual improvements to it.
No one gets to be "successful" by updating someone else's idea, though.
http://www.jwz.org/doc/cadt.html "going through the bug list isn't fun; but rewriting everything from scratch is fun"
No one gets to be "successful" by updating someone else's idea, though.
http://www.jwz.org/doc/cadt.html "going through the bug list isn't fun; but rewriting everything from scratch is fun"
I don't like the framing in some of this. Distinguishing "famous" from "successful" (and putting the latter above it on the ladder) seems to be missing the point. It's all well and good to celebrate Carmack and DHH, who are worthy of praise. But kicking, say, Fabrice Bellard or Tridge down a level purely because of what they choose to work on seems to be missing an awful lot of value...
Is it really necessary to "score" the life-work of programmers? People change and go through stages of life and career. Everyone starts out as a "bad programmer" and/or has stretches of professional problems in their career. It just seems crass to attempt to categorize this into "levels" like on a video game or something.
My guesses on how to be a Level 1 programmer based on the examples:Do a lot of Math and stay in academia.
I felt like the results should have been ordered in reverse (least successful to most successful), with 'amateur' ranking before 'unknown'. It seemed like it started with the best, and just gave me worse options the further I read.
I'm curious where Atwood currently scores himself on this scale.
"Very few programmers ever achieve this level [1, the dead programmer] in their own lifetimes."
That's because they're dead.
While the name says 'dead programmers,' he doesn't specify that a programmer must have died to reach that status.
2 of the examples he provides are living.
2 of the examples he provides are living.
I am currently an average programmer, as judged by this scale.
It seems to me that average programmer and working programmer overlap quite a bit. I might never be a great programmer but there are still plenty of jobs out there I can do well as an average programmer and I always have work.
If you're not a 'working programmer' (i.e. improving things by being there) you may just be a 'Bad Programmer'. IMHO.
Unless you happen to work for a company/department with awesome, stable practices and quality output I guess.
Unless you happen to work for a company/department with awesome, stable practices and quality output I guess.
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 "<Company> 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.
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 "<Company> 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.
If you removed the years of experience to achieve X from your definitions and added criteria you expect, then these "achievement levels" would have much more merit. I am pretty sure I am familiar with the types of individuals you are talking about here, but years of experience is one of the worst measures of, well experience.
Years of experience is one of the larger generalizations we make in our industry. One that is almost always worthless because it has negative connotations on both ends, while given little to no idea of what value lies in the middle. The only time it can be useful is as a barrier to entry to new graduates.
Years of experience is one of the larger generalizations we make in our industry. One that is almost always worthless because it has negative connotations on both ends, while given little to no idea of what value lies in the middle. The only time it can be useful is as a barrier to entry to new graduates.
As an HR-ism, "years of experience" is a stupid metric. I agree.
I only included such criteria for the 2.0 and 2.5 level, which characterize the top 1-2 percent (or less) of programmers. I should add that while I've never seen people reach 2.0+ without programming for 10 years (even if they weren't holding a professional-level job during all that time; they might have started at 14) I am not saying it can't happen. But 2.0+ engineers are uncommon and it has to be very rare for someone to get there without the Gladwellian "10,000 hours".
If you're looking to hire 2.0+ engineers, you're not using HR-isms. You don't pay attention to the standard HR bullshit about "must have Ph.D." or "must have 5 years of experience". You're often trying to fill the roles through referrals, because those people aren't on the job market for very long, and they tend to have very high requirements with regard to the jobs they take. You don't find these people using an HR checklist and filtering thousands of off-the-street CVs.
Most people aren't trying to hire 2.0+, because the work that a 2.0+ engineer will find interesting is uncommon and few companies even have use for that high a level of work.
I've been programming for 6 years, and have been aggressively managing my career in the direction of optimizing for learning, sometimes quitting jobs solely on account of boredom, and other times "stealing an education" from jobs, and I'm only 1.7-1.8. The 2.0's are rare and I've never met one under 30 (although it's certainly possible).
I only included such criteria for the 2.0 and 2.5 level, which characterize the top 1-2 percent (or less) of programmers. I should add that while I've never seen people reach 2.0+ without programming for 10 years (even if they weren't holding a professional-level job during all that time; they might have started at 14) I am not saying it can't happen. But 2.0+ engineers are uncommon and it has to be very rare for someone to get there without the Gladwellian "10,000 hours".
If you're looking to hire 2.0+ engineers, you're not using HR-isms. You don't pay attention to the standard HR bullshit about "must have Ph.D." or "must have 5 years of experience". You're often trying to fill the roles through referrals, because those people aren't on the job market for very long, and they tend to have very high requirements with regard to the jobs they take. You don't find these people using an HR checklist and filtering thousands of off-the-street CVs.
Most people aren't trying to hire 2.0+, because the work that a 2.0+ engineer will find interesting is uncommon and few companies even have use for that high a level of work.
I've been programming for 6 years, and have been aggressively managing my career in the direction of optimizing for learning, sometimes quitting jobs solely on account of boredom, and other times "stealing an education" from jobs, and I'm only 1.7-1.8. The 2.0's are rare and I've never met one under 30 (although it's certainly possible).
10 years of experience does not equate to a great violinist, but I don't know any great violin players without it.
I started writing code at a young age, got a CS degree, and after graduating my first 3 months I was more productive than some people I have worked with with 5 years experience. I created something that a significant fraction of people I have worked with would have been unable to think of. However, I had just been writing code not reading it. After working on many projects both short and long term, I would cringe if I had to maintain the code I wrote back then.
Comments are a probably the perfect example where you need to be bitten by a stale comment a few times to really understand what's important.
I started writing code at a young age, got a CS degree, and after graduating my first 3 months I was more productive than some people I have worked with with 5 years experience. I created something that a significant fraction of people I have worked with would have been unable to think of. However, I had just been writing code not reading it. After working on many projects both short and long term, I would cringe if I had to maintain the code I wrote back then.
Comments are a probably the perfect example where you need to be bitten by a stale comment a few times to really understand what's important.
You don't need 10 years, you need 10,000 hours. However, 10,000 hours alone is still a useless metric unless you know it was spent learning. 10,000 hours fixing bugs in the same system won't introduce you to enough new concepts to provide the same value of 10,000 hours of building products.
All of your levels above High Worker are really unappealing to me; they sound like the Peter Principle at work. You're a skilled computer scientist, so you must be good at handling people too, right?
That's precisely the point. Non-programmers are largely uninterested in the technical abilities separating 90th percentile coders from 99th percentile coders. It's only when you simultaneously demonstrate worth on an orthogonal axis (e.g. management) that people start to assume you're a top-tier dev.
I really like the multiplier vs adder differentiation. I would also acknowledge the solid global adders, as those who contribute to respectable open source projects.
Global adders, I would argue, are multipliers because high-quality software makes a lot of people more effective.
Yes, but that would break the meaning of the multiplier. That's why there is the global in front. So, global adder is a solid adder (or perhaps a rising multiplier) who regularly works on significant open source projects, e.g. webkit, apache, mozilla, etc.
He's just replaced some of the words; the result makes no sense.