10X Programmer and Other Software Engineering Myths
blog.fogcreek.com
blog.fogcreek.com
I can agree with the specific observation that there is no consensus on concrete quantifiable data to prove "10x" with mathematical rigor.
Ok, let's set aside "10x" because many previous discussions about it have shown it to be a distasteful description to some. For those who do not believe in the "10x programmer", how do you feel about programmers such as John Carmack (Doom, Oculus)[1], Fabrice Bellard (ffmpeg, pi algorithm)[2], Linus Torvalds (Linux, Git), TJ Holowaychuk (node.js projects)?
If they are a league above other average programmers, what's an acceptable description that you'd use?
To me, the "10x programmer" was always a snappy rhetorical label and I was fine with it that way. I never sought a mathematical proof of the statement.
People need to stop obsessing over the term. It's awesome that great programmers exist. Stop being so insecure.
Think of it in this way. Most of us are smart people, and learned relativity in high school or college. Those that didn't, could have. It ain't that hard. But how many could have discovered relativity at that time in history? None of us, I suspect. Put it how you want, Einstein is a 10x, he is 6std outside the mean, or whatever.
Same sort of things in software in my experience. If you have something really hard to do at work, you know who to give it to, right? You give it to (say) Jessica, who will come back in 3 days not only with it complete, but with all the ambiguities in the spec fixed, with 4 enhancements that you never thought of, documentation, and a framework that lets others in the company extend the functionality into other company products.
Or, you could give it to Jacob, who will need to be prodded for status updates week after week, and he'll eventually 'deliver' 10x the number of lines of code (hence just as productive by SLOC estimates!) for a substandard solution that is unreadable and fails on all the edge cases.
I call that 10x, without worrying about the math or quantitative part.
To anyone that disagrees, why all the hand wringing about hiring? Just hire anyone that crosses your door, they will be fine, right?
My problem with the myth is the part that posits there are a bunch of programmers you can drop on anything and have them be more productive than the average. They exist, but they are very rare, just like Einstein-caliber scientists are very rare. In fact, you connected "10X" with "six-sigma"; that is about 4/1,000,000.
> To anyone that disagrees, why all the hand wringing about hiring? Just hire anyone that crosses your door, they will be fine, right?
I have complained many times in the past about the hand-wringing. I think you are creating a false dichotomy between hiring "10Xers" and hiring anybody. There is a gaping chasm between those positions, and in my opinion the proper place to set your bar depends on a serious assessment of your company and your needs. In this context the demand for "10X" engineers comes off at best as hiring voodoo and at worst as an excuse to not hire anybody like the company principals.
Jessica is not a "10X programmer". Jessica is a "10X $TASK programmer", where $TASK may or may not comprise an entire role. $TASK might even be as large as "web dev" or "enterprise dev". It is nearly impossible to screen for, though, unless someone has directly comparable work experience, where directly comparable includes intangibles like work environment.
A long, drawn out project is where real productivity difference will become evident though. Developers who don't mire themselves in technical debt can easily become 10x (or more) productive than those who don't.
Dedicated. These individuals have mastered their domain; they have spent years learning and practicing. They have built knowledge and skills that can be transferred to other domains. I think people need to stop focusing on the label, and start focusing on the process.
I don't believe a person is born a 10X programmer. It's only achieved through discipline.
A related concept is "general intelligence," which behavioral genetic research has shown to be highly heritable.
http://en.wikipedia.org/wiki/Fluid_and_crystallized_intellig...
My high school had an introductory programming class. Most students hadn't done any programming before, yet there were a couple of students who quickly understood the concepts and could solve weeks worth of assignments in a single day, whereas the rest of the class struggled. Those students, for whatever reason, were able to learn programming much more quickly than the average student, and I believe those students they'd see a greater return on their investment of hard work.
Here's another anecdote: do you know any experienced engineers who work 12 hours a day and still struggle to do relatively easy jobs? I do. Talent is an important piece of the puzzle. Hard work is also an important part of the puzzle. Both are important.
The NBA players are the top 1-in-1000000 world's best players.
A programmer only has to be 1-in-100 to be competent. The other 99-in-100 should find other careers.
Explain MVC to a 5 engineers with equal experience and language skills, and 1 might end up finishing your sentences and extrapolating to other domains, while musing about limitations and gotchas, another couple will just sort of follow along, and perhaps one fails to understand and keeps asking you to repeat yourself and explain in different ways. Engineer 1 will go back to their desk and spin out reams of productive code, whereas #5 will make a mess of it and create technical debt. #5 will put many more hours into it than #1, for whom this is effortlessly assimulated. People have differing abilities.
I am really good at programming. I am moved deeply by music, but my interpretations when I play are somewhat pedestrian and/or copied (I play classical guitar & piano). I don't even grok ballet. I don't get how the movements correspond to the music, I don't understand why person A is rated better than B, and so on. It's an alien language, and I could study for 10 years and it still would be. Yes, the greats (in performance and appreciation) worked harder than me at it, but even if I worked that hard I'd still be a ballet doofus (citation needed).
I think the supposition that all that is required is "discipline" is very difficult to accept for anyone who has ever seriously played competitive sports...
As an athlete you end up realizing pretty early that in spite of similar levels of training, practice and dedication, you just don't have the talent (raw or cultivated) for certain levels of performance. It's just not going to happen. For me, I _maybe_ could have made a Division III or Division II team, but there was no way I was going to get accepted at the Division I-level, not to mention Pro-level. It just wasn't going to happen.
But what is perhaps more distressing, is that you it's relatively easy to recognize the individuals that do. The ones that have that the "10x factor". Its the girl or guy that you get benched for so they can go in. They one that the team rallies behind to win. Because they _can_ win the game; they can make the shot, they can focus through the exhaustion, they can make the "play", see the big picture. It's a thing...
I think thats the real distinguishing characteristic of 10X ______ (fill in the blank): they have the ability, within a group of skilled peers, to _create almost unilaterally_. While the rest of us, require the support of the team to accomplish pretty much anything in that environment.
And its easy to ignore/forget about the vast majority; which haven't cultivated the skill/craft to perform any task beyond basic.
Also, the (rarely surfaced) assumption that whoever is doing the hiring can tell a talented programmer from an average one. This is rarely the case.
My favorite example of this is the -2000 lines of code story about Bill Atkinson (QuickDraw, MacPaint, HyperCard):
http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...
I don't question that those brilliance of the people you mentioned but as edw519 says, in his free ebook [1],
> I'm not suggesting that you'll go out and write Rails in 3 weekends. What I am suggesting is that the more I meet "famous" hackers and the more I meet people from this community (online and offline), the more I realize that there's not really all that much that separates us.
> Lot's of people are obviously brilliant. And even for those who are a little less brilliant, brilliance is only one part of the equation. Work habits, determination, perseverence, passion, and maybe most of all, belief, are just as important. Don't sell yourself short.
What I suggest is, a magical genetic gift, might not be the reason why those guys achieved so much. It might be because they were more "aggressive" and "focused" hackers. They insisted on building everyday and chose to work upon very challenging problems.
In some other situations/environments he might be even worse than his peers.
Right people, right place, right time, right behavior.
Maybe all programmers in the team have to build a website from scratch in Ruby, and he decides (and delivers) to build a web framework that allows his team to be 10 times more productive, not having to bother with the whole HTTP stack but only care about the application, i.e the added value of the team.
Maybe he created a new programming language that allows the logic to be expressed and deployed 10 times as fast, and allows the code to be X times more maintainable than before; that's where productivity booms and the team (and in the end, the company) can deliver real products in accordance to what the users want.
It does mean that the 10x programmer is better than others, but that's not the way this definition defines him: it only care how much he enables other to be more productive.
How do you measure productivity on your team? How do you arrive at the factor of five?
A lot of people comment on HN that there are no 10x engineers, which I find strange. How can you work in this industry and not be convinced of the huge gradient in productivity?
We measure productivity with #bugs, #points of features, etc. It's pretty crude, but better than lines of code. It really doesn't tell the whole story though, because most of what makes a 10x engineer is not solving problems faster, but solving the right problem in the first place.
Better to look at the situation including such bad performers...
It's often difficult for 3x programmers to make it at first because the 1x programmers will often gang up on the 3x programmer to protect their own jobs, although the behavior is often unspoken about between them. Many places will thus hire 3x programmers in bulk as a separate team, but many -0.5x programmers will slip in as well. A group of such 3x programmers will often put one of their own number to watch over, say, four of the -0.5x programmers, who will thus appear to be a 1x programmer, 3 + (4 * -0.5) == 1. 10x programmers can be groomed from a 3x programmer over time, but it's difficult for a business to pull off because the other 3x programmers will gang up on them, similarly fearful for their own jobs. And only big Silicon Valley names can hire 10x programmers in bulk.
Have you noticed how you have only listed programmers with skillsets that go beyond programming [except for the one I don't know know anything about, TJ]?
The first 3 of these are really programmers with management skills and the ability to build enough of a following to contribute to their projects. Their ability doesn't stem from a unique, magical "10x programmer" capability but rather the ability to get others to buy into their vision.
Linus didn't succeed because he was a better programmer than 99.9% of the population. Linus succeeded because he got other programmers to buy into his vision and was a good programmer.
You remember John Carmack more than Romero, not because of the skillset difference but because of John Carmack's ability to organize other programmers.
I understand there is a desire to honor these people due to technical skill alone but it isn't their technical abilities that made them famous. If it was, you'd be including a bunch of other people with some very impressive list of technologies to their name. Rather than people who are "well known". Its the social skills that allow people to achieve fame that cause you to remember them like this.
Even in this thread. Saying John Cormack is a "10x" programmer because he wrote Doom seems silly. (No offence to John Cormack.) There are lots of games out there. Why Doom? Or is it that anyone who wrote a game is a "10x" programmer. Or Linus Torvalds, why does writing Git make you a better programmer than writing Subversion? And what is "productivity" when writing code for yourself, versus writing code for your employer?
Einstein was not a "10x" scientist. He was a genius. The only problem is that there aren't many Einsteins out there. To make it your goal to only hire the Einsteins of the world, or to try to figure out how to 'make' more Einsteins, is short-sighted for an employer when there so many good, but non-genius programmers out there. But if that is your goal, at least be honest and say you are looking for geniuses.
The term "10x" is a literal measure of productivity. It defines the rate of output per unit of input. And that is why it is a myth.
OF COURSE there are 10x differences between programmers.
I feel like I'm relatively at the top of my game, and I know people who code circles around me. One of them has eidetic memory, and is also a genius to boot. He reads a manual to learn a new programming language. He's literally fluent in a programming language, and uses the correct idioms, in a matter of hours. Meanwhile, I'm copy-paste-modifying, doing everything like I would have in C++, for days or weeks.
An 18-year-old won Google Code Jam on his first try. I rest my frickin case.
Does there exist a programmer who is 10x as productive as another programmer, at a given task, given they both have the same amount of experience? OF COURSE ones like that EXIST.
If you want to talk about how common they are, how wide the spread really is, and underlying reasons, then yes, that warrants research.
But you don't need STATISTICS to prove something EXISTS. Anecdotal evidence is perfectly valid to prove something EXISTS.
The fact is, some problems are hard. Some problems are beyond the grasp of some developers. Even given unlimited time an individual may not ever accomplish the goal. I can certainly think of problem sets where that is true of myself.
In those specific circumstances, that person can be considered a "10x programmer" when compared with another.
It's a given that some people are more productive than others. They are faster typists, or they can architect a system of similar quality faster, or they can just write good code faster. But remember the idea of 10x came from studies of similarly experienced programmers. And supposedly, the order of magnitude comes from actual data, although I've never been able to see it.
For most trivial problems, or for a given domain, I think it's easier to say one programmer is qualitatively better than another. But that may change if the domain or code base changes, and in my experience as the problems you're solving get more and more complex, it becomes impossible (or at best just boils down to who you think can crank out a POC faster, which is itself probably a specific domain of programming).
I just have trouble accepting the argument that one person is literally, quantitatively, empirically ten times the programmer as someone else. Maybe that makes me one of the 1x's :)
How are we determining experience? If we are talking about years in the field, years with a given language, years using a given language in the same way? 'Experience' is fluid enough of a word that it would be crucial to have an agreed upon concrete definition before we could continue.
Perhaps a better way to look at this is to assume the average is 3X, and there exist developers at X, 10X, 0X, -X, and everywhere in between. And this productivity depends massively on circumstances like the size and makeup of the team, the established codebase, and the technical difficulty of the work.
I've worked with several individuals that are absolutely a 10x for a technically-difficult project where they are leading the architecture, but range from -1X to 0X as a regular contributor to a large project.
Also, I'm hiring. ;)
http://www.joelonsoftware.com/articles/HighNotes.html
His theory is that salaries are distributed fairly normally so the top of the heap might only demand 2x the salary of an average, and only 4x the salary of the bottom. But they might be 10x as skilled or productive. That means that they're actually cheaper. 10x work divided by 4x cost = 2.5x productivity.
* They aren't really devoting effort, not beyond setting up a skype recording and transcribing the result. The effort comes entirely from the author, Laurent Bossavit, they are interviewing. * The claim is against the existence of rigorous evidence that supports the idea that 10x programmers are around in sufficient quantity to be a practical consideration for people involved in the creation of software. Bossavit explicitly states that he's not saying that 10x programmers don't exist at all. He's not even saying that they aren't reasonably common. Just that there's not rigorous evidence that demonstrates the phenomenon, even though he's found many citations that misleadingly imply the existence of such evidence. * Joel's claims in the article are anecdotal, and don't appear to be meant as a rigorous proof, but as a feeling extrapolated from his personal experience. So there's really not a lot of disagreement between what Joel's claims and Bossavit's. * Even if there had been a direct disagreement, why should that preclude a Fog Creek blog from exploring ideas that are incompatible with one of the multitudes of ideas that their very opinionated founder has published? Fog Creek is very concerned with attracting developers as far to the right of the bell curve as they can manage. Forbidding the exploration of thoughts independent of those the founder has expressed is extremely counterproductive to that goal, since highly competent people tend to have their own ideas about how to do things. * Finally, even if we were to treat Fog Creek and Joel Spoelsky as the same entity, we should expect such thought leaders to entertain and grapple with thoughts that seem to be contradictory to their past opinions, especially when they come with a more thorough examination of the available evidence. Being a 'flip flopper' is only a disadvantage in politics. In reality humans have to make determinations under uncertainty, and therefore do not always get things right. It's a sign of intellectual maturity to be able to revise one's previously held/stated beliefs.
For starters, I've yet to see a good way to measure productivity.
In my experience, there are 10x programmers out there. I've known a couple in my 20 professional years who exceeded that.
The fact that there isn't research proving it only tells me that I don't know distribution of that kind of talent, not that it completely doesn't exist.
You could say similar things about the notion of "debunking" the exponential cost of defects.
In 1997 I think I could have done a web site 10x faster than most people, because I had been obsessed with it. At this point that's no longer true. Right now there are people that can do machine learning stuff 10x faster than other people because they are obsessed. Because they are experts and deeper into the 10,000 hours it takes to become an expert. The phenomena is more like that book outliers.
Speaking of myths... ;)
Not 10x, but also non-trivial for those of us who don't have Facebook-like dollars to throw at filling desks in an ever-larger open floor plans.
The most telling part, though, is where they take some of the lower-25% from cubicle farm/open office spaces and put them in private office spaces. Guess what happens?
1. Better programmers are more likely to have negotiating leverage.
2. Taking a poor programmer and moving him to a quieter space improves his productivity.
I'd still like to see a proper modern scientific study comparing office environments. It's very hard to do correctly, because there are too many variables.
Also, there really are 10x programmers. At my current job, the new programmer took a couple of weeks to do something that I thought would take a couple of days. (and I was already familiar with the codebase, so my estimate of how long it would take me to do it was probably accurate) That's only 5x, but he's be deficient in other ways, such as not noticing severe bugs until other people pointed them out.
Lets say the great senior was able to code 20 hours per week, and used the remaining time for email, a weekly blog, walk the dog and other recreations. He now has to lead a team of a few average coders, and as hiring hyped a lot of sub average people (1/4 of his own productivity), who are only working 8 hours effectively because the rest is wasted by powerpointless kickoff meetings, and recreational office coffee talk.
imho, the factor 10 comes not from the coder, but from the system. There are some companies where its 10 times more fun to work, likely those attract those who are 10 times more productive.
The software crisis for big projects is also a system crisis. Those projects start by big companies betting on a budget, without knowing whats really in the sack, and without knowing whom to choose to solve the problem from their pool of employees. Once one of them gets the projects, the middle management starts to fight each other. Trying to hire good coders from other projects, or trying to get bad people into the new budget. The resulting internal fluctuation will cause a mess on any project.
My guess is that it is because no two software projects are alike. Differences stemming from differing technology stacks, to domains or people skills, it is practically impossible to generalize anything across them.
Unless we all standardize on a one true way of software engineering, such folklores will continue to exists and there will be a dearth in repeatable conclusions.
PS: However, I do agree with Laurent that we can work towards aggregating numbers from several real software projects than rely on unsubstantiated folklore.
I'll admit that I only focused on the x10 programmer one, but nothing in the transcript dispelled the notion for me.
If you're interested in this stuff you could do worse than checking out Andy Oram and Greg Wilsons 'Making Software: What Really Works, and Why We Believe It' a series of literature reviews on various topics including the 10x programmer thing, different development methodologies and practices. It's not perfect but it's a good start and helped me to think critically about my own practice.
1. A large number of programmers. Statistical significance, also real development is done in teams.
2. A long time - conclusions valid for short snippets do not necessarily translate to large projects where people in a team have to cooperate.
3. Controlled environment - passively getting statistics from existing companies won't cut it.
So you need to pay a programmer's salary to a large number of people for a longish time which is expensive. Perhaps this could be worked around by having deals with existing companies to let you control some factors in their existing processes. Maybe not perfect but still better than anecdata.
It seems like software as an industry is very prone to myths, poor introspection, and no-true-scotsman methodologies that purport to solve or harness the resulting "insights".
> So this is the notion that there is a 10 fold
> difference between productivity and quality
> of work between different programmers with
> the same amount of experience.
> Is this fact or fiction?
Once you defined a measurement people could study for it. Someone who has memorized a gzip function is going to make a compressor 100x better than I am going to from scratch.
http://www.joelonsoftware.com/articles/HighNotes.html
[1] In the sense of https://en.wikipedia.org/wiki/Vector_(epidemiology)
10x chef
10x receptionist
10x writer
10x mechanic
SMH...
I also firmly believe copy-pasting should be disabled on sites like Stack Overflow.
If these are the kind of problems that you're experiencing then I think you need to find a more challenging environment where you're the worst developer in the team.