The Myth of the Rockstar Programmer(hanselman.com)
hanselman.com
The Myth of the Rockstar Programmer
http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
25 comments
"Some people are stronger than you, some people are better coders than you - it's OK. "
What some people fail to get is that coders have over human powers. A strong person can't surpass human limits. He can't lift a car with his hands. But a person with a machine can.
You can't short all the words in a book as a person, but a machine can in less than a tenth of a second.
What some people fail to get is that coders have over human powers. A strong person can't surpass human limits. He can't lift a car with his hands. But a person with a machine can.
You can't short all the words in a book as a person, but a machine can in less than a tenth of a second.
Typo. Should be: You can't SORT all the words...
This isn't backed up by evidence or a sound argument, and comparing the capability of women to have babies with the productivity of programmers nicely sums up the intelligence of the argument.
Teams follow the 80/20 rule as well. 20% of the developers do 80% of the work (there is actually evidence in support of this, but I'm not going to look it up now)
Rockstar developers are a real thing. I work with some. I like to think I am one. I'm not talking about loud developers which the author seems to conflate with rockstar developers. I'm talking about the quiet thoughtful guys who have an amazing grasp of how everything fits together. They see the problem in amazing detail with all it's hairiness and then devise a simple, elegant solution for it.
Rockstar developers are the guys who solve the right problems. And there's an infinite gap between them and the bottom guys, because for some problems, the worst developers will never solve them. They tend to be around 10x as productive as above-average developers on the hardest problems. On easy problems there's a much smaller difference.
In my free time I work on a multi-threaded high-performance ACID relational database with concurrent algorithms, custom memory allocation and layout, hybrid index data structures and garbage collection algorithms. I don't know too many developers who can solve those kinds of problems, so I like to think I'm special. But all humans like to think that, so maybe I'm not actually a rockstar developer and I'm really just average-delusional. Who knows.
Teams follow the 80/20 rule as well. 20% of the developers do 80% of the work (there is actually evidence in support of this, but I'm not going to look it up now)
Rockstar developers are a real thing. I work with some. I like to think I am one. I'm not talking about loud developers which the author seems to conflate with rockstar developers. I'm talking about the quiet thoughtful guys who have an amazing grasp of how everything fits together. They see the problem in amazing detail with all it's hairiness and then devise a simple, elegant solution for it.
Rockstar developers are the guys who solve the right problems. And there's an infinite gap between them and the bottom guys, because for some problems, the worst developers will never solve them. They tend to be around 10x as productive as above-average developers on the hardest problems. On easy problems there's a much smaller difference.
In my free time I work on a multi-threaded high-performance ACID relational database with concurrent algorithms, custom memory allocation and layout, hybrid index data structures and garbage collection algorithms. I don't know too many developers who can solve those kinds of problems, so I like to think I'm special. But all humans like to think that, so maybe I'm not actually a rockstar developer and I'm really just average-delusional. Who knows.
> Reality is a normal distribution curve. Lots of good average senior developers, some amazing outliers and some junior folks with potential. (and some folks that suck.)
Strange, but this doesn't seem to be the case for me, or at least the people that I've had to interview and work with. I've run into far too many developers who have no business installing apache much less making anything of use for a client.
I don't consider myself a "rockstar," but when you put me next to one of these folks my productivity is going to be 10-fold better at least. On top of that, the things I build will be reliable and maintainable -- their will be a mess of technical debt that breaks every few days.
As a sidenote, I find this obnoxious:
> I hate Quora so I won't link to them, but here's a modification of a great answer from Nate Waddoups that was taken from some internal engineering paperwork:
"I hate Quora, so I'll just steal their content and post it here."
Strange, but this doesn't seem to be the case for me, or at least the people that I've had to interview and work with. I've run into far too many developers who have no business installing apache much less making anything of use for a client.
I don't consider myself a "rockstar," but when you put me next to one of these folks my productivity is going to be 10-fold better at least. On top of that, the things I build will be reliable and maintainable -- their will be a mess of technical debt that breaks every few days.
As a sidenote, I find this obnoxious:
> I hate Quora so I won't link to them, but here's a modification of a great answer from Nate Waddoups that was taken from some internal engineering paperwork:
"I hate Quora, so I'll just steal their content and post it here."
> As a sidenote, I find this obnoxious:
> "I hate Quora, so I'll just steal their content and post it here."
It's not Quora's content. Quora's TOS explicitly states that users retain ownership over their contributions. Quora only gets a non-exclusive license.
Scott Hanselman works for Microsoft. Nade Waddoups works for Microsoft, wrote an internal document at Microsoft, and then posted part of it to Quora as an answer.
Therefore: The copyright is held not by Quora, or even by Nate Waddoups -- but by Microsoft. And since Scott Hanselman is performing a PR function at Microsoft through his blogging, he has the right to post that content on his blog.
It's not Quora's content. Quora's TOS explicitly states that users retain ownership over their contributions. Quora only gets a non-exclusive license.
Scott Hanselman works for Microsoft. Nade Waddoups works for Microsoft, wrote an internal document at Microsoft, and then posted part of it to Quora as an answer.
Therefore: The copyright is held not by Quora, or even by Nate Waddoups -- but by Microsoft. And since Scott Hanselman is performing a PR function at Microsoft through his blogging, he has the right to post that content on his blog.
That's a little complex of an explanation. I could still argue fair use. Regardless, it's a coincidence that this guy works for MSFT. I don't know him. I just stumbled on the Quora post.
The link from my post also explains why Quora is evil, I'm detail, FWIW.
The link from my post also explains why Quora is evil, I'm detail, FWIW.
My theory is that the time taken for an engineer to solve a problem is a hockey-stick/exponential curve based on the complexity, something like __/
The key thing is the knee of the curve is in a different position for different engineers. Basically, up to a certain point, you can crank through a problem pretty well. But once problems reach a certain level of complexity you'll slow down. And at a higher level of complexity, you're just going to go in circles and not going to get anywhere.
The point of a "rockstar" is not that they are 10x faster on the flat part, but their curve is shifted so they are on the flat part while another engineer would be on the exponential part. In other words "rockstar" depends on the problem. Knuth is unlikely to build a basic CRUD application 10x faster than an average HN programmer, but if the problem is building a typography system, he's probably 100x as productive. Likewise, if I had to build a Javascript compiler engine, a self-driving car, Minecraft, or a translation system, I would be stuck around 0% productivity while a "rockstar" would deliver. But "rockstar" depends on the project: on a simpler project, many more people would be able to deliver well.
TL;DR: for a particular project, people who can do that project well are 100x more productive than people who are overwhelmed by the project. But this line moves depending on the complexity of the project.
The key thing is the knee of the curve is in a different position for different engineers. Basically, up to a certain point, you can crank through a problem pretty well. But once problems reach a certain level of complexity you'll slow down. And at a higher level of complexity, you're just going to go in circles and not going to get anywhere.
The point of a "rockstar" is not that they are 10x faster on the flat part, but their curve is shifted so they are on the flat part while another engineer would be on the exponential part. In other words "rockstar" depends on the problem. Knuth is unlikely to build a basic CRUD application 10x faster than an average HN programmer, but if the problem is building a typography system, he's probably 100x as productive. Likewise, if I had to build a Javascript compiler engine, a self-driving car, Minecraft, or a translation system, I would be stuck around 0% productivity while a "rockstar" would deliver. But "rockstar" depends on the project: on a simpler project, many more people would be able to deliver well.
TL;DR: for a particular project, people who can do that project well are 100x more productive than people who are overwhelmed by the project. But this line moves depending on the complexity of the project.
Each time something like this is posted to HN many are quick to come to the defense of the 10x engineer as not a myth. Since so many HNers are founders/CEOs/CTOs/whatever I wonder how many of them making comments that 10x engineers are "responsible for most of team's output" are actually paying their "rockstar" engineers ten times average.
The best baseball players make much more than the average player, the star of a Hollywood film makes far more than most actors, and true "rockstars" make a heck of a lot more money than the vast majority of musicians.
Anyone know any companies that pay their best engineers multi-million dollar salaries? (if so please let me know where to apply!)
The best baseball players make much more than the average player, the star of a Hollywood film makes far more than most actors, and true "rockstars" make a heck of a lot more money than the vast majority of musicians.
Anyone know any companies that pay their best engineers multi-million dollar salaries? (if so please let me know where to apply!)
> The best baseball players make much more than the average player, the star of a Hollywood film makes far more than most actors, and true "rockstars" make a heck of a lot more money than the vast majority of musicians.
It's sales and risk management problem. Given a rockstar and an aspiring novice rocker, you can sell concert tickets at 10x (or 100x) price mark when the former plays. The costs of infrastructure are high, but scale roughly with O(log(n)) which means econonmy of scale, and being rockstar means automatic, `free' marketing. It works a little bit different in the software world.
If you sell to corporate customers, it's sales and risk management (support, compatibility, etc.) problem. You need those costly sales reps. Due to risk management, corporation pay only slightly more for 10x better if it is built by small team -- they want a large, established vendor (risk management on their part). Which obviously pre-cludes all-star team. Unless you hit an acquisition jackpot :^)
If you sell software packages to consumers, it's marketing and margins problem -- there is always a middleman taking a cut; think Apple Store. Unless you become viral -- like Angry Birds did.
If you sell services to consumers, it's again marketing and scaling problem -- you'll end up needing huge backend, which means large team, which agains precludes an all-star team.
> Anyone know any companies that pay their best engineers multi-million dollar salaries? (if so please let me know where to apply!) GOOG, FB, etc. -- to the founders ;-)
It's sales and risk management problem. Given a rockstar and an aspiring novice rocker, you can sell concert tickets at 10x (or 100x) price mark when the former plays. The costs of infrastructure are high, but scale roughly with O(log(n)) which means econonmy of scale, and being rockstar means automatic, `free' marketing. It works a little bit different in the software world.
If you sell to corporate customers, it's sales and risk management (support, compatibility, etc.) problem. You need those costly sales reps. Due to risk management, corporation pay only slightly more for 10x better if it is built by small team -- they want a large, established vendor (risk management on their part). Which obviously pre-cludes all-star team. Unless you hit an acquisition jackpot :^)
If you sell software packages to consumers, it's marketing and margins problem -- there is always a middleman taking a cut; think Apple Store. Unless you become viral -- like Angry Birds did.
If you sell services to consumers, it's again marketing and scaling problem -- you'll end up needing huge backend, which means large team, which agains precludes an all-star team.
> Anyone know any companies that pay their best engineers multi-million dollar salaries? (if so please let me know where to apply!) GOOG, FB, etc. -- to the founders ;-)
Because it's notoriously difficult to measure programmer productivity, companies are generally going to be incredibly hesitant to offer "rockstar" programmers salaries that match their capabilities. There's no box office take or album sales or stadium-filling metrics to rely on.
"Rockstar" programmers generally need to go and (co-)found their own companies to make their multiples of millions. The great difficulty is that being a rockstar programmer doesn't always make you a good product/business person, and the best programming can't save a crappy business. But people like Gates and Zuckerberg are the ones who make it happen.
But if one day we find the holy grail of accurately measuring programmer productivity... (though I don't think that's possible...)
"Rockstar" programmers generally need to go and (co-)found their own companies to make their multiples of millions. The great difficulty is that being a rockstar programmer doesn't always make you a good product/business person, and the best programming can't save a crappy business. But people like Gates and Zuckerberg are the ones who make it happen.
But if one day we find the holy grail of accurately measuring programmer productivity... (though I don't think that's possible...)
That's another thing I've found funny...often the very same people who say measuring programmer productivity is difficult are the ones saying some devs are ten times more productive than others.
Isn't it obvious that the myth or reality of the 10x engineer has a lot to do with what the engineer is supposed to do?
Say that the engineer has to independently develop the general theory of relativity to solve a problem, then I'd say Einstein would have been about Inf times more productive than the average engineer at solving that particular problem.
If on the other hand it's the usual "migrate this crap code from that crap platform to this shiny new golden one" kind of work, then you'd have more of a bottleneck in how fast you can push the buttons on the keyboard...
You can't talk about productivity without defining the task, and software engineering is a field with extraordinary span in the difficulty of tasks.
Say that the engineer has to independently develop the general theory of relativity to solve a problem, then I'd say Einstein would have been about Inf times more productive than the average engineer at solving that particular problem.
If on the other hand it's the usual "migrate this crap code from that crap platform to this shiny new golden one" kind of work, then you'd have more of a bottleneck in how fast you can push the buttons on the keyboard...
You can't talk about productivity without defining the task, and software engineering is a field with extraordinary span in the difficulty of tasks.
> People love to say that a rockstar can do the work of 10 regular engineers. That's just nonsense. 9 women can't have one baby in a month, and 10 "rockstar" developers can't replace 100 regular ones.
This is completely unconvincing, and begs the question: why is software development a sequential fixed-time process like having a baby? Where is the evidence for that?
On the other side of things, there are lots of people - just look in the comments here and in previous related stories - of people that clearly say they have worked with devs that are 10x more productive then the average. Why does the author feel the need to deny that? That's the real question.
This is completely unconvincing, and begs the question: why is software development a sequential fixed-time process like having a baby? Where is the evidence for that?
On the other side of things, there are lots of people - just look in the comments here and in previous related stories - of people that clearly say they have worked with devs that are 10x more productive then the average. Why does the author feel the need to deny that? That's the real question.
The author is exactly backwards on the issue of team scaling.
Even if I grant his premise that 10x engineers don't exist (which I don't), let's just presume 2x engineers exist. So is a team of four 2x engineers equivalent to a team of 8 1x engineers? No -- the smaller team is vastly more effective, because of the n^2 communication problem.
This is why strong individual performers are so valuable. Give me my top pick of 10 developers, and we will ship the product at least as fast as any organization of any size. Bigger organizations can still work on more separate projects in parallel, but they won't out-develop us on any particular one.
Even if I grant his premise that 10x engineers don't exist (which I don't), let's just presume 2x engineers exist. So is a team of four 2x engineers equivalent to a team of 8 1x engineers? No -- the smaller team is vastly more effective, because of the n^2 communication problem.
This is why strong individual performers are so valuable. Give me my top pick of 10 developers, and we will ship the product at least as fast as any organization of any size. Bigger organizations can still work on more separate projects in parallel, but they won't out-develop us on any particular one.
"n!" communication problem, not just "n^2".
Well, you can't get into electronics and not hear about Bob Widlar, Jim Williams or Bob Pease..
There is such a thing as rockstar engineer. The thing they had in common though was that they're really good, yet are kind on others. They were also extravagent, but that's just who they were. Read about how Jim Williams behaved during his interview, and you'd see what I mean (for the less curious, he was in shorts and sandals, moved really close to the recruiter and started to interrogate him).
There is such a thing as rockstar engineer. The thing they had in common though was that they're really good, yet are kind on others. They were also extravagent, but that's just who they were. Read about how Jim Williams behaved during his interview, and you'd see what I mean (for the less curious, he was in shorts and sandals, moved really close to the recruiter and started to interrogate him).
"In fact, it's diversity of thought and experience in a team that makes a Rockstar Team" -- this, a million times this. You don't get rockstar results without deep thought and questioning everything. The most efficient way to do this, and the easiest way to create this in your company, is to build a diverse team.
I believe that this is the real secret behind Google.
I believe that this is the real secret behind Google.
The most important reason we have to insist on the "rockstar programmer" being a myth is that it takes attention away from the CEO that wants to be the rockstar. Rockstars also have more leverage, which chaffs the suits who want you to be just another drone that they can shuffle around like an office chair.
I suspect that the strong disagreements between people on this thread on whether 10x engineers exist or not say more about the diversity of HN'er team composition than anything else.
If you put a competent coder among a bunch of not-entirely-stupid, well willing, but mediocre programmers, he can quickly be 10x as productive. He will also clearly stand out as such. Put the same coder among other competent coders, and nobody will notice anything special.
If this is true, there can only be two options:
But anyway, no matter whether this idea makes sense, I believe that it never pays to try to hire "10x people". If you find that you managed to find one, it simply means that the most of your team has been underperforming. Get rid of them and replace by one or two other decent ones. Maybe the first mr 10x has some friends?
If you put a competent coder among a bunch of not-entirely-stupid, well willing, but mediocre programmers, he can quickly be 10x as productive. He will also clearly stand out as such. Put the same coder among other competent coders, and nobody will notice anything special.
If this is true, there can only be two options:
- Hanselman only ever worked with mediocre engineers
- Hanselman only ever worked with truly competent engineers.
But anyway, no matter whether this idea makes sense, I believe that it never pays to try to hire "10x people". If you find that you managed to find one, it simply means that the most of your team has been underperforming. Get rid of them and replace by one or two other decent ones. Maybe the first mr 10x has some friends?
The 10x programmer myth is all about relativity. I suggest there are no 10x programmers, only -10x programmers which make the normal ones look really good.
And people who say that 10x programmers do exist because they have worked with one, are in fact themselves the -10x guy.
And people who say that 10x programmers do exist because they have worked with one, are in fact themselves the -10x guy.
I never liked the words rockstar and programmer being associated together. The only valid use case for that is if a member of a very successful rock band, with fans and groupies becomes a programmer as a second job. Only then he's a rockstar programmer.
In my experience, Managers often mistake Cowboy Coders for Rockstars.
http://c2.com/cgi/wiki?CowboyCoder
http://c2.com/cgi/wiki?CowboyCoder
I would have preferred somewhat more content, but the article still had this absolute gem at the end:
> it's diversity of thought and experience in a team that makes a Rockstar Team
People who complement (and cover) one another's skills, are mostly self-directing and are not afraid to ask "stupid" questions - they are incredibly valuable, together more so than as individuals. I've had the joy of working with/in such teams twice in my career. Problems didn't just vanish, they very rarely materialised.
Eventually all good things must end. Projects end, priorities change, people move on and teams get disbanded. The reality check after such a joyful experience can be shocking.
> it's diversity of thought and experience in a team that makes a Rockstar Team
People who complement (and cover) one another's skills, are mostly self-directing and are not afraid to ask "stupid" questions - they are incredibly valuable, together more so than as individuals. I've had the joy of working with/in such teams twice in my career. Problems didn't just vanish, they very rarely materialised.
Eventually all good things must end. Projects end, priorities change, people move on and teams get disbanded. The reality check after such a joyful experience can be shocking.
In the same vain I responded to Shanley's post: this is missing one type of engineer that is common in our field:
* Average Engineer - Creates complex problems in response to simple problems...
This is where the desire for rockstars / 10x engineers comes from. One person to clean up the mess made by 10 others.
* Average Engineer - Creates complex problems in response to simple problems...
This is where the desire for rockstars / 10x engineers comes from. One person to clean up the mess made by 10 others.
That's exactly what I thought as well.
I'd very much prefer having the 10x engineer meme replaced by that of the 0.1x engineer: the one that gets the same task done with 10% of the code and effort.
The times I've felt by far most valuable is when I found a way to make that multi-month project simply obsolete by just changing a couple hundred lines of code in an unexpected place.
I'd very much prefer having the 10x engineer meme replaced by that of the 0.1x engineer: the one that gets the same task done with 10% of the code and effort.
The times I've felt by far most valuable is when I found a way to make that multi-month project simply obsolete by just changing a couple hundred lines of code in an unexpected place.
See also: http://folklore.org/StoryView.py?story=Negative_2000_Lines_O...:
"In early 1982, the Lisa software team was trying to buckle down for the big push to ship the software within the next six months. Some of the managers decided that it would be a good idea to track the progress of each individual engineer in terms of the amount of code that they wrote from week to week. They devised a form that each engineer was required to submit every Friday, which included a field for the number of lines of code that were written that week.
Bill Atkinson, the author of Quickdraw and the main user interface designer, who was by far the most important Lisa implementor, thought that lines of code was a silly measure of software productivity. He thought his goal was to write as small and fast a program as possible, and that the lines of code metric only encouraged writing sloppy, bloated, broken code.
He recently was working on optimizing Quickdraw's region calculation machinery, and had completely rewritten the region engine using a simpler, more general algorithm which, after some tweaking, made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code.
He was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000.
I'm not sure how the managers reacted to that, but I do know that after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied."
"In early 1982, the Lisa software team was trying to buckle down for the big push to ship the software within the next six months. Some of the managers decided that it would be a good idea to track the progress of each individual engineer in terms of the amount of code that they wrote from week to week. They devised a form that each engineer was required to submit every Friday, which included a field for the number of lines of code that were written that week.
Bill Atkinson, the author of Quickdraw and the main user interface designer, who was by far the most important Lisa implementor, thought that lines of code was a silly measure of software productivity. He thought his goal was to write as small and fast a program as possible, and that the lines of code metric only encouraged writing sloppy, bloated, broken code.
He recently was working on optimizing Quickdraw's region calculation machinery, and had completely rewritten the region engine using a simpler, more general algorithm which, after some tweaking, made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code.
He was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000.
I'm not sure how the managers reacted to that, but I do know that after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied."
I've seen engineers with consistently negative productivity: solve 1 bug by introducing 2.
He's empirically wrong because I've worked with 10x developers.
A few years ago I worked with a guy there whose output, productivity, and smart solutions combined with godlike C++ coding ability made him probably 100x more effective than anyone else in the place.
This was in the front office at Goldman Sachs, so the rest of us weren't completely useless. He was just in a different league though.
I have also worked with a 10x developer who carried a small company of around 50.
A few years ago I worked with a guy there whose output, productivity, and smart solutions combined with godlike C++ coding ability made him probably 100x more effective than anyone else in the place.
This was in the front office at Goldman Sachs, so the rest of us weren't completely useless. He was just in a different league though.
I have also worked with a 10x developer who carried a small company of around 50.
I understand where you're coming from -- there are some truly good engineers out there.
But I think he's right too. He's essentially arguing about the true meaning of the metric. Of course there are engineers who can spot bugs at 1/100th the time as an arbitrary engineer. Or fixes things 10x faster (being familiar with the code base certainly helps).
But to have the literal productive capacity of 10 people? That's much different, and that's what he means. Are you capable of replacing 10 arbitrary engineers with the rockstar? No? Then that's not a 10x engineer, by his definition.
But I think he's right too. He's essentially arguing about the true meaning of the metric. Of course there are engineers who can spot bugs at 1/100th the time as an arbitrary engineer. Or fixes things 10x faster (being familiar with the code base certainly helps).
But to have the literal productive capacity of 10 people? That's much different, and that's what he means. Are you capable of replacing 10 arbitrary engineers with the rockstar? No? Then that's not a 10x engineer, by his definition.
It's rare that anyone tries to replace 10 ordinary engineers with one 10xer. It's common, however, to try to replace one 10xer with 10 ordinary engineers, and find that they can't cope with the challenges.
I can confirm. I have also worked with a number of programmers who have been 5x as productive as an average programmer and one who was easily 10x, possibly more.
My old manager handed Mr 10x a company chequebook and said "write your own salary in there… just don't leave". He left. He wanted challenging work more than he wanted money.
These people exist in all fields: maths, art, music, literature, sport. It is amazing (and somewhat dispiriting) when you meet one, however working with one is, in my experience, only inspiring.
My old manager handed Mr 10x a company chequebook and said "write your own salary in there… just don't leave". He left. He wanted challenging work more than he wanted money.
These people exist in all fields: maths, art, music, literature, sport. It is amazing (and somewhat dispiriting) when you meet one, however working with one is, in my experience, only inspiring.
I've worked with someone like this during my internship at IBM.
He was an intern like me but he was carrying the whole team. Solving problems, implementing features left and right.
Never really did talk to the team, other than meetings, just did his work and locked himself in his cubicle.
During our internship he studied for and took a couple of scjp and c++ certifications just because he was bored not studying for exams.
I miss that guy. Not that sociable but really really fucking efficient as a developer.
He was an intern like me but he was carrying the whole team. Solving problems, implementing features left and right.
Never really did talk to the team, other than meetings, just did his work and locked himself in his cubicle.
During our internship he studied for and took a couple of scjp and c++ certifications just because he was bored not studying for exams.
I miss that guy. Not that sociable but really really fucking efficient as a developer.
> He's empirically wrong because I've worked with 10x developers.
I believe you meant "He's anecdotally wrong because I've worked with 10x developers."
To be empirically wrong, you'd have to contradict it with some empirical rather than anecdotal evidence.
I believe you meant "He's anecdotally wrong because I've worked with 10x developers."
To be empirically wrong, you'd have to contradict it with some empirical rather than anecdotal evidence.
It's a matter of sample size, not of principle.
If you're looking for a replicated controlled study, there's been something close:
http://www.joelonsoftware.com/articles/HighNotes.html
http://www.joelonsoftware.com/articles/HighNotes.html
Anecdotal evidence is empirical evidence. It's just not very convincing because it doesn't come with any information about how common experiences like those are, or what confounding factors might be at play.
Now, in this case, confounding factors probably aren't a problem, but if 10x developers are one in a million or one in a billion, an anecdote about how someone, somewhere actually met one once isn't very helpful to the rest of us.
Now, in this case, confounding factors probably aren't a problem, but if 10x developers are one in a million or one in a billion, an anecdote about how someone, somewhere actually met one once isn't very helpful to the rest of us.
Validity of the observation is a potential confounding factor. There are clearly people who impress their coworkers to the extent that those coworkers believe the person is a 10x-average programmer. That's what this kind of report establishes. But is the judgment of those coworkers correct? Is the person actually 10x more productive in any kind of rigorous, verifiable sense? Generally these reports don't come with enough evidence to establish that.
[deleted]
can I ask a few questions as I am struck by this comment
- How much of his contribution would you rate as technical vs understanding the domain, understanding of the systems and seeing through explicit requirements to the underlying need (you might see where I am leading).
actually that's several questions right there.
I am just fascinated by the idea of 10x: my personal assumption is it is like professional football stars - there are those who are paid 1000x, who probably win 10x but as athletes and players will be only a fraction of x better than the lowliest professional player and into the Sunday leagues.
However in these fraction of x cases other things come to play - like coach, team spirit, team quality, tactics etc. and in the software field I expect a similar disjunction to occur - knowing the system under maintenance perfectly, understanding / influencing the business requirements, as much as raw technical ability.
for example David Beckham is probably 10x player compared to say a professional in the first division. this does not mean he scores 10x as much or retains possession 10x or any other metric you like. but that teams with him in win 10x because of the leverage of the in tease in ability he does have.
and leverage is out of this world in software.
so just interested - is your ex-Collegue a david Beckham of c++ ? or is he truly a god?
- How much of his contribution would you rate as technical vs understanding the domain, understanding of the systems and seeing through explicit requirements to the underlying need (you might see where I am leading).
actually that's several questions right there.
I am just fascinated by the idea of 10x: my personal assumption is it is like professional football stars - there are those who are paid 1000x, who probably win 10x but as athletes and players will be only a fraction of x better than the lowliest professional player and into the Sunday leagues.
However in these fraction of x cases other things come to play - like coach, team spirit, team quality, tactics etc. and in the software field I expect a similar disjunction to occur - knowing the system under maintenance perfectly, understanding / influencing the business requirements, as much as raw technical ability.
for example David Beckham is probably 10x player compared to say a professional in the first division. this does not mean he scores 10x as much or retains possession 10x or any other metric you like. but that teams with him in win 10x because of the leverage of the in tease in ability he does have.
and leverage is out of this world in software.
so just interested - is your ex-Collegue a david Beckham of c++ ? or is he truly a god?
Allow me to retort: Fabrice Bellard, Linus Torvalds, John Carmack.
Pity...go to any job board, you'll see 50 of them needed on any given day
Those aren't the "rock stars" hiring companies are talking about. They don't need & couldn't afford Linus.
Rock star is just a label they slap onto the job description.
Those aren't the "rock stars" hiring companies are talking about. They don't need & couldn't afford Linus.
Rock star is just a label they slap onto the job description.
>Rock star is just a label they slap onto the job description ...
... often to arouse the ego of possible candidates.
I can't imagine why any recruiter wouldn't see the deliberate attempt at patronising candidates when they advertise "Looking for a Rock star programmer." Oh, hang on ... I know why: appealing to and strongly arousing ego is one of the quickest way to get responses.
The team matters more than the individual. Hiring with overt calls to rock stars is surely going to damage communication and collaboration with the current team.
... often to arouse the ego of possible candidates.
I can't imagine why any recruiter wouldn't see the deliberate attempt at patronising candidates when they advertise "Looking for a Rock star programmer." Oh, hang on ... I know why: appealing to and strongly arousing ego is one of the quickest way to get responses.
The team matters more than the individual. Hiring with overt calls to rock stars is surely going to damage communication and collaboration with the current team.
So they are all self-employed. Makes much more sense than a salaried genius. Shouldn't we discuss 10x managers as well?
I disagree strongly. I created a software company, I have an amazing team, I know a little about this.
Rockstars programmers exist and they do because they can do machines do work for them, instead of having five people do the work the can do the code 5x to 100x or 1000x faster.
They could automate almost everything, even coding(creating new languages when needed specially for the task) and debugging itself, creating testing code, making failures very hard to happen.
A normal programmer will create new problems, not solve it. She will put mechanisms in place in order for the company to depend on her. She could not be faster but she could certainly make the others to slow down to her level. Beware is she gets to manage Rockstars, she will do everything to put others down, pointing fingers. They are experts excuse makers.
If you look at all big software accomplishments you will discover a very small team of incredible rockstar developers.
What this man is saying is that you need a team, no divas. But who says that Rockstars can't create teams?
One thing you can't do of course is putting Rockstars at the orders of some mediocre person or even argue when you don't know what you are talking about(you need to do your homework first). It is not comfortable.
What this person is saying is that he fears managing a team of people smarter than him, so he just prefers having people that are "normal".
Rockstars programmers exist and they do because they can do machines do work for them, instead of having five people do the work the can do the code 5x to 100x or 1000x faster.
They could automate almost everything, even coding(creating new languages when needed specially for the task) and debugging itself, creating testing code, making failures very hard to happen.
A normal programmer will create new problems, not solve it. She will put mechanisms in place in order for the company to depend on her. She could not be faster but she could certainly make the others to slow down to her level. Beware is she gets to manage Rockstars, she will do everything to put others down, pointing fingers. They are experts excuse makers.
If you look at all big software accomplishments you will discover a very small team of incredible rockstar developers.
What this man is saying is that you need a team, no divas. But who says that Rockstars can't create teams?
One thing you can't do of course is putting Rockstars at the orders of some mediocre person or even argue when you don't know what you are talking about(you need to do your homework first). It is not comfortable.
What this person is saying is that he fears managing a team of people smarter than him, so he just prefers having people that are "normal".
If you think you're hiring abnormal developers, you either have a very distorted view of your candidate pool, or your hiring process borks somewhere in the middle.
There is at least one faulty assumption in your post; I don't think it disqualifies it, of course, but I believe it makes it hard to generalize your conclusion:
> they do because they can do machines do work for them, instead of having five people do the work the can do the code 5x to 100x or 1000x faster. They could automate almost everything, even coding(creating new languages when needed specially for the task) and debugging itself, creating testing code, making failures very hard to happen.
First off, the "they make machines do work for them" is a cliche. Please, don't use this to advertise your team. Unless it's a bunch of freshmen doing 100% quality original web design on freelancer.com.
Second, if most of your development process can be automatized, why exactly do you need a team of developers? Original work tends to require thinking and crafting. If you're cranking out Joomla websites and a hundred customized CRMs a month, sure, that works, but most of these mythical rockstar creatures would probably not touch one of those things.
What about processes that naturally don't lend themselves to being automatized, particularly like the DSLs you mention? Yes, you can automate some of the process (e.g. you can use flexx and yacc to generate some of the parsing logic) if the language is too complex to reliably code the respective parts by hand, but you're still a long way to go from there.
> A normal programmer will create new problems, not solve it. She will put mechanisms in place in order for the company to depend on her. She could not be faster but she could certainly make the others to slow down to her level.
This is not what a normal programmer does. If the programmers you normally hire are like this, your company has a serious problem.
There is at least one faulty assumption in your post; I don't think it disqualifies it, of course, but I believe it makes it hard to generalize your conclusion:
> they do because they can do machines do work for them, instead of having five people do the work the can do the code 5x to 100x or 1000x faster. They could automate almost everything, even coding(creating new languages when needed specially for the task) and debugging itself, creating testing code, making failures very hard to happen.
First off, the "they make machines do work for them" is a cliche. Please, don't use this to advertise your team. Unless it's a bunch of freshmen doing 100% quality original web design on freelancer.com.
Second, if most of your development process can be automatized, why exactly do you need a team of developers? Original work tends to require thinking and crafting. If you're cranking out Joomla websites and a hundred customized CRMs a month, sure, that works, but most of these mythical rockstar creatures would probably not touch one of those things.
What about processes that naturally don't lend themselves to being automatized, particularly like the DSLs you mention? Yes, you can automate some of the process (e.g. you can use flexx and yacc to generate some of the parsing logic) if the language is too complex to reliably code the respective parts by hand, but you're still a long way to go from there.
> A normal programmer will create new problems, not solve it. She will put mechanisms in place in order for the company to depend on her. She could not be faster but she could certainly make the others to slow down to her level.
This is not what a normal programmer does. If the programmers you normally hire are like this, your company has a serious problem.
> Rockstars programmers exist
Of course they do. The laws of probability ensure that. People and their traits usually follow a normal ("bell curve") distribution. Some individuals are at +2.5 standard deviations, and some even at +3.0 but they are rare.
Using the table from http://www.mathsisfun.com/data/standard-normal-distribution-... we can get some nice numbers to show just how rare they are.
A +2.5 developer is better than 99.38% of the entire population. (1 in 160)
A +3.0 developer is better than 99.87% of the population. (1 in 770)
That kind of talent can not be easy to find, let alone attract. So relying on getting such stars is gambling against some pretty bad odds. Some companies no doubt have found that they can improve the odds of attracting those off-the-charts developers, but for the rest of us mortals...
Of course they do. The laws of probability ensure that. People and their traits usually follow a normal ("bell curve") distribution. Some individuals are at +2.5 standard deviations, and some even at +3.0 but they are rare.
Using the table from http://www.mathsisfun.com/data/standard-normal-distribution-... we can get some nice numbers to show just how rare they are.
A +2.5 developer is better than 99.38% of the entire population. (1 in 160)
A +3.0 developer is better than 99.87% of the population. (1 in 770)
That kind of talent can not be easy to find, let alone attract. So relying on getting such stars is gambling against some pretty bad odds. Some companies no doubt have found that they can improve the odds of attracting those off-the-charts developers, but for the rest of us mortals...
You're mistaken about the laws of probability. The normal distribution arises from sums of the same distribution. This is most frequently found in sample averages, which is . More accurately, sample averages follow a student T distribution, which converges to a normal distribution as sample size increases to infinity.
In general, humans do not follow a bell curve for complex traits. For instance, it's common to see bimodal/multimodal distributions when there are major demographic differences in the population such as gender, race, economic class, etc. Standardized tests have bell-curves because they are "normed." Experimental questions are thrown out if they are not correlated very well with the result.
Also based on the Chebyshev's inequality, +2 std dev has a minimum percentile of 75%. +2.5 has a minimum percentile of 84%. +3 has a minimum percentile of 89%. +k has a minimum percentile of 1-(1/k^2)
In general, humans do not follow a bell curve for complex traits. For instance, it's common to see bimodal/multimodal distributions when there are major demographic differences in the population such as gender, race, economic class, etc. Standardized tests have bell-curves because they are "normed." Experimental questions are thrown out if they are not correlated very well with the result.
Also based on the Chebyshev's inequality, +2 std dev has a minimum percentile of 75%. +2.5 has a minimum percentile of 84%. +3 has a minimum percentile of 89%. +k has a minimum percentile of 1-(1/k^2)
> In general, humans do not follow a bell curve for complex traits. [...] Also based on the Chebyshev's inequality,...
Thank you, this was very helpful. After some quick searches and http://en.wikipedia.org/wiki/Chebyshev%27s_inequality I now also know where the "off by square root of sample size" rule comes from.
I stand corrected and very happily so.
Thank you, this was very helpful. After some quick searches and http://en.wikipedia.org/wiki/Chebyshev%27s_inequality I now also know where the "off by square root of sample size" rule comes from.
I stand corrected and very happily so.
Not only that, he seems to be conflating standard deviations with productivity multipliers (I'm not exactly sure how to translate his +2 to productivity, I could be misinterpreting), which is definitely wrong.
Heavens, no. That wasn't the idea, and certainly not my intention. It was merely a numerical standard deviance value, nothing more.
Granted, the people at the high end of the scale are probably more productive when facing more difficult problems but that's all. "How much more" is then an altogether different question. I'm not sure if one could even put a figure on it.
Granted, the people at the high end of the scale are probably more productive when facing more difficult problems but that's all. "How much more" is then an altogether different question. I'm not sure if one could even put a figure on it.
"Normal", really?
This sounds more like you have a hiring problem.
This sounds more like you have a hiring problem.
It doesn't take a "rockstar" or a "ninja" or "guru" or what-have-you to be a significantly above average developer.
Often the biggest hindrance to product quality (including performance, reliability, and usability) as well as to development velocity is technical debt. Having a team member who consistently churns out lots of new stuff of excellent quality is great but not nearly as important as someone who is sensitive to and adamant about eliminating technical debt. The cost of such debt balloons exponentially over time and becomes more and more difficult to pay down the longer it's allowed to grow. But even a fairly modest amount of effort consistently applied before technical debt grows out of hand can realize massive gains compared to the more typical scenario where the technical debt is allowed to grow until it threatens the viability of the entire product before it's addressed.
This may not seem very "rockstar" but ultimately it is such folks who keep the system clean who have the most disproportionately large impact on the quality, viability, market success, and total development cost of big projects.
Often the biggest hindrance to product quality (including performance, reliability, and usability) as well as to development velocity is technical debt. Having a team member who consistently churns out lots of new stuff of excellent quality is great but not nearly as important as someone who is sensitive to and adamant about eliminating technical debt. The cost of such debt balloons exponentially over time and becomes more and more difficult to pay down the longer it's allowed to grow. But even a fairly modest amount of effort consistently applied before technical debt grows out of hand can realize massive gains compared to the more typical scenario where the technical debt is allowed to grow until it threatens the viability of the entire product before it's addressed.
This may not seem very "rockstar" but ultimately it is such folks who keep the system clean who have the most disproportionately large impact on the quality, viability, market success, and total development cost of big projects.
Its the guys who layout the overall design, making it is easily extensible and not prone technical debt who make a software project. They may not be the most productive in producing code, but they allow others to be so.
It's usually the same guy going over others peoples code, and reducing technical debt.
It's usually the same guy going over others peoples code, and reducing technical debt.
Another thing, a lot of the most important work in development is relatively unglamorous. Most of the time it's better to have a craftsman at work than a diva steering your product in the wrong direction for the sake of looking cool in the moment.
My main takeaway from the rockstar/ninja programmer thing- many people seem to believe that the average programmer produces net negative value, i.e. causes more problems than they solve.
I'm still uncertain whether I believe this, although I'm sure we all feel like we are carrying the team some days. If it were true, it would mean that firing half of all programmers could be the biggest improvement to the software industry ever seen.
I'm still uncertain whether I believe this, although I'm sure we all feel like we are carrying the team some days. If it were true, it would mean that firing half of all programmers could be the biggest improvement to the software industry ever seen.
>>People love to say that a rockstar can do the work of 10 regular engineers. That's just nonsense. 9 women can't have one baby in a month, and 10 "rockstar" developers can't replace 100 regular ones.
A somewhat confusing attempt to use the 9 women analogy here - it doesn't prove the author's point in any way.
I've worked with rockstar coders and engineers and my empirical experience suggests he's wrong.
A somewhat confusing attempt to use the 9 women analogy here - it doesn't prove the author's point in any way.
I've worked with rockstar coders and engineers and my empirical experience suggests he's wrong.
After reading numerous posts on the subject of 10x software engineers, I reckon they fall mostly into two categories:
- `I have worked with / seen code of such ones' (often examples follow)
- `there were no such ones on any team I ever managed', with OP falling into this category.
Which is to say, the existence (or absence) of 10x software engineers appears to be party recognition problem -- managers do not want to believe one `rockstar' is responsible for most of team's output.
The other part, is the sampling bias: managers don't get to work with the Torvalds, Bellards, etc. Such software engineers often don't need to be, or aren't managed while producing their most important code. Neither they do respond to ``we are hiring rockstars'' types of job ads...
- `I have worked with / seen code of such ones' (often examples follow)
- `there were no such ones on any team I ever managed', with OP falling into this category.
Which is to say, the existence (or absence) of 10x software engineers appears to be party recognition problem -- managers do not want to believe one `rockstar' is responsible for most of team's output.
The other part, is the sampling bias: managers don't get to work with the Torvalds, Bellards, etc. Such software engineers often don't need to be, or aren't managed while producing their most important code. Neither they do respond to ``we are hiring rockstars'' types of job ads...
There also seems to be some ideological motivation for claiming rockstars don't exist.
The existence of rockstars provides fodder for individualist ideologies. Many people are more collectivist, so therefore feel the need to dispute the existence of rockstars. This is a little bit evident here - you need a rockstar team, with diversity. It's far more evident in the last post on this same topic.
(Not quite a dupe, but it might as well be. https://medium.com/about-work/6aedba30ecfe )
Amusingly, it's also a very corporate philosophy. "No programmer is worth more than any other, therefore to advance you must enter management." Tends to be self selecting in such corporations, since everyone who isn't mediocre leaves.
The existence of rockstars provides fodder for individualist ideologies. Many people are more collectivist, so therefore feel the need to dispute the existence of rockstars. This is a little bit evident here - you need a rockstar team, with diversity. It's far more evident in the last post on this same topic.
(Not quite a dupe, but it might as well be. https://medium.com/about-work/6aedba30ecfe )
Amusingly, it's also a very corporate philosophy. "No programmer is worth more than any other, therefore to advance you must enter management." Tends to be self selecting in such corporations, since everyone who isn't mediocre leaves.
> No programmer is worth more than any other
I don't think that's what's being said. IMHO the message is:
- No programmer is worth 10x the average. (though some might be worth 1/10 * the average).
- A high-functioning team is more important than a high-functioning individual, and these two are sometimes at odds if you give free rein to the "individualist ideologies".
Both are debatable and IMHO are often true, but "No programmer is worth more than any other", i.e. "all programmers have exactly the same worth" is not Hanselman's point. It is an corporate anti-pattern.
"each person has different strengths and weaknesses and is growing at their own rate" is recognised implicitly in a healthy working environment. Whether management gets it or not.
I don't think that's what's being said. IMHO the message is:
- No programmer is worth 10x the average. (though some might be worth 1/10 * the average).
- A high-functioning team is more important than a high-functioning individual, and these two are sometimes at odds if you give free rein to the "individualist ideologies".
Both are debatable and IMHO are often true, but "No programmer is worth more than any other", i.e. "all programmers have exactly the same worth" is not Hanselman's point. It is an corporate anti-pattern.
"each person has different strengths and weaknesses and is growing at their own rate" is recognised implicitly in a healthy working environment. Whether management gets it or not.
Both are debatable and IMHO are often true, but "No programmer is worth more than any other", i.e. "all programmers have exactly the same worth" is a straight-up straw man.
It's an exaggeration (I probably should have been more clear), not a straw man. Obviously big corporations have different levels of engineers, but many of them claim engineers top out at a certain point. Your claim that "no programmer is worth 10x the average" does imply this. If programmers max out at being only 3x better than average (or whatever the multiplier is), to get beyond that level one needs to be a manager.
Interestingly, tech companies, trading desks, and other places where technology really matters frequently don't view things this way.
It's an exaggeration (I probably should have been more clear), not a straw man. Obviously big corporations have different levels of engineers, but many of them claim engineers top out at a certain point. Your claim that "no programmer is worth 10x the average" does imply this. If programmers max out at being only 3x better than average (or whatever the multiplier is), to get beyond that level one needs to be a manager.
Interestingly, tech companies, trading desks, and other places where technology really matters frequently don't view things this way.
> Your claim that "no programmer is worth 10x the average" does imply this
Those claims are debatable and often true, not always true. As opposed to straw men which aren't even debatable.
I've seen less actual 10* engineers and more high-functioning individualistic coders who maintain whole systems on their own, and at some point leave the company (most people change jobs at some point, but in their case it was accompanied by "nobody understands what I do" noises) whereupon it's unmaintainable (in one case, running on their dev machine against explicit instruction with no source or login details).
Your company may hit the jackpot and hire a budding Linus Torvalds or John Carmack, but the odds are bad and the guy who thinks he's a rockstar is more likely to be a good coder, but an egotistical person. Lots of actual musician rockstars are assholes too.
A well-functioning team is a much better bet. Lottery tickets are a poor investment.
I know that trading desks may disagree, but IMHO that's a defect of the stock-market gambling culture that they come from (where someone's guaranteed to beat the market this year. Find them and call them a genius!). I've worked in various tech companies, and that mindset is not universal there. It's not even welcome to me.
Those claims are debatable and often true, not always true. As opposed to straw men which aren't even debatable.
I've seen less actual 10* engineers and more high-functioning individualistic coders who maintain whole systems on their own, and at some point leave the company (most people change jobs at some point, but in their case it was accompanied by "nobody understands what I do" noises) whereupon it's unmaintainable (in one case, running on their dev machine against explicit instruction with no source or login details).
Your company may hit the jackpot and hire a budding Linus Torvalds or John Carmack, but the odds are bad and the guy who thinks he's a rockstar is more likely to be a good coder, but an egotistical person. Lots of actual musician rockstars are assholes too.
A well-functioning team is a much better bet. Lottery tickets are a poor investment.
I know that trading desks may disagree, but IMHO that's a defect of the stock-market gambling culture that they come from (where someone's guaranteed to beat the market this year. Find them and call them a genius!). I've worked in various tech companies, and that mindset is not universal there. It's not even welcome to me.
You have somehow re-defined software engineer performance as a mere function of company bottom-line, and ended up measuring performance of individual software developers by proxy of long-term company performance. There are two problems with it.
First, not all software engineers actually do commercially work on commercial software -- as a quick example, Con Kolivas, who is an anaesthesiologist by day and kernel hacker in spare time. Others may work on commerical software by themselves, without any external team or management involved; think Colin Percival. I would even wager a guess that some of the best software was created in a non-commercial way, say, Linux kernel -- at least the early versions of it.
Second, the impact any software engineer has on company bottom line is much affected by other aspects of a company. In a symbolic notation, you could say:
First, not all software engineers actually do commercially work on commercial software -- as a quick example, Con Kolivas, who is an anaesthesiologist by day and kernel hacker in spare time. Others may work on commerical software by themselves, without any external team or management involved; think Colin Percival. I would even wager a guess that some of the best software was created in a non-commercial way, say, Linux kernel -- at least the early versions of it.
Second, the impact any software engineer has on company bottom line is much affected by other aspects of a company. In a symbolic notation, you could say:
BOTTOMLINE_IMPACT := RISK_MANAGEMENT(SALES(TEAM_MANAGEMENT(THE_SOFTWARE_DEVELOPER(EXISTING_CODEBASE)))).
> You have somehow re-defined software engineer performance as a mere function of company bottom-line,
Absolutely.
While everything you say is true, building the right thing is as important as building the thing right. If you are working for a company, and what you do doesn't benefit that company, you might as well go home.
Absolutely.
While everything you say is true, building the right thing is as important as building the thing right. If you are working for a company, and what you do doesn't benefit that company, you might as well go home.
There is a difference between linear extrapolation and the butterfly effect. That seems to be the part that many miss. Startups (by necessity) show sensitive dependence on initial conditions. Mature companies (by design) do not.
Is it your belief that no "high-functioning individualistic coder who maintain[s] [a] whole system on their own" can also produce a maintainable system? If one can, that's your 10x coder right there.
I'm getting the impression that you believe 10x coders exist but merely dislike them.
I'm getting the impression that you believe 10x coders exist but merely dislike them.
By "high-functioning" I meant "good enough to be recognised as above average, but not 10 * good". My point about maintainability is that long-term benefit can be a lot less than it looks in the short term, when "individualistic" people who "know they're very good" are involved.
> If one can, that's your 10x coder right there
It can happen, it's just not likely enough to stake your business on. What I dislike is the cult of rockstar programmers. If there are 100 job ads for rockstars, are there really 500 actual rockstars showing up for those interviews? No. All this cult is doing is encouraging harmful egoism.
It's all in the first few lines of the article:
> Myth of the Rockstar Programmer: Calling out rockstars demotivates the team. Telling someone they are a rockstar may cause them to actually believe it
> If one can, that's your 10x coder right there
It can happen, it's just not likely enough to stake your business on. What I dislike is the cult of rockstar programmers. If there are 100 job ads for rockstars, are there really 500 actual rockstars showing up for those interviews? No. All this cult is doing is encouraging harmful egoism.
It's all in the first few lines of the article:
> Myth of the Rockstar Programmer: Calling out rockstars demotivates the team. Telling someone they are a rockstar may cause them to actually believe it
In the observation that kicked off the meme, a 10x engineer was someone who was 10x more productive than the least productive members of the team, not 10x more productive than the average.
Yeah. If the least productive member of the team is clueless and gets nothing done, then a competent programmer is literally infinitely more productive than that. It's not a very well-calibrated metric.
It's pretty typical, I'd say, for the least productive member of a set of 10 programmers to have negative productivity...
That is a rigged comparison but too often that matches reality. Everyone in the team works on massive Big Balls Of Mud in C#, ASP.NET. One guy in the team builds a new app in Python with Django in one tenth the time it would take to do it in C#/ASP.NET. Is this guy a rock star? Or is this a symptom of a toxic IT environment created by incompetent management who simply have no concept of "accidental complexity" and "technical debt".
So many enterprise IT shops are effectively bankrupt due to technical debt and the only thing propping them up is the cash influx of the enterprise that owns them. This affects J2EE shops just as much as .NET ones.
And the multicore future, end of Moore's law, has effectively made all of their software, both built software and purchased software, obsolete. It is not a pretty picture, but we will see this all play out over the next few years. That is far more important than chasing after the fantasy of the 10x white knight who will save you.
So many enterprise IT shops are effectively bankrupt due to technical debt and the only thing propping them up is the cash influx of the enterprise that owns them. This affects J2EE shops just as much as .NET ones.
And the multicore future, end of Moore's law, has effectively made all of their software, both built software and purchased software, obsolete. It is not a pretty picture, but we will see this all play out over the next few years. That is far more important than chasing after the fantasy of the 10x white knight who will save you.
Exactly. Thanks.
[deleted]
[deleted]
+1. When you're concerned with ensuring every single developer can read, understand, and rewrite your code, you don't have a place for the best; because the average and worst devs won't grasp what the best does.
Often it is quite the opposite: when the best is finished the result is smaller and much more readable.
I am allowed to be opinionated, I have seen both forms in well paid consultant jobs.
I am allowed to be opinionated, I have seen both forms in well paid consultant jobs.
The best avoid tangled, excessively-layered code, but often are inclined to use reflection, multi-indirection, or other tools that mediocre programmers may not understand.
Agreed. And it is true 10x developers make complex problems disappear by realizing the code does not have to be written, by skipping intermediate steps, or by embracing the complexity if the problem and not code until the problem is understood instead of piling hack upon hack.
First, is important to search the truth. I think we are discussing if 1 + 1 is equal to 2 or not. 10X engineers exist (I would say that 100X ones too). If you found even one it is enough to probe this fact.
You can see similar distributions with scientists or other professionals.
You can see similar distributions with scientists or other professionals.
With so much mention of 10x on HN I'm surprised Grant Cardone isn't on here or at tech conferences selling his book. That brings me to my point, a car salesman selling 10 times as much cars as other salesmen is clearly 10x, how do you determine that for a developer? To me it seems like there are so many variables that such a distinction would always be incorrect.
When I see a developer that can work on a complex product alone in short time and almost no bugs, well this a developer in the 10X league.
Sure, if the idea is to make the 10 in 10x meaningless. My point was that saying something is 10X implies that it is quantifiable. That developer can be assumed to be above average but you don't know that he's 10x. Maybe he worked in the same domain for a long time or did exactly the same work before. I agree that if someone works in the same domain for a long time eventually they will be an expert but as a developer saying that he/she is 10x doesn't mean much. If I write social networks for 10 years then I can appear to be 10x for all things social but how productive am I outside of that? I guess the more appropriate discussion is what is a developer 10x in.
I agree. Now I am following you.
The discussion about what a 10x developer means is really interesting: specialization and long time commitment to specific fields pays a very important part. I don't think you can be a 10X developer in an unrelated specialty. We can compare this with experiments about chess masters playing a new game with modified rules, they are not masters anymore.
The discussion about what a 10x developer means is really interesting: specialization and long time commitment to specific fields pays a very important part. I don't think you can be a 10X developer in an unrelated specialty. We can compare this with experiments about chess masters playing a new game with modified rules, they are not masters anymore.
[deleted]
Not all men are created equal - I don't see why anyone would rail against that. Some people are stronger than you, some people are better coders than you - it's OK. Compare yourself with last year's you instead.