Steve Jobs: the difference between superb programmers vs. average ones is 25:1(fastcompany.com)
fastcompany.com
Steve Jobs: the difference between superb programmers vs. average ones is 25:1
http://www.fastcompany.com/1836987/steve-jobs-the-payoff-of-a-great-employee
7 comments
who cares if he pulled the number out of his ass? The point is that great devs are not just 10% better than mediocre ones. They are many times better for all kinds of different reasons. That is a very valid point, an important one to consider for anyone hiring, and it doesn't matter if the number is 5, 10, 25, or 100.
I was planning to make a similar comment.
I don't doubt that a great engineer outperforms a mediocre one in productivity, ingenuity, innovation, whatever, but living by this as your mantra, and making hiring decisions around it as if it were a scientifically-proven study seems incredibly dangerous.
I don't doubt that a great engineer outperforms a mediocre one in productivity, ingenuity, innovation, whatever, but living by this as your mantra, and making hiring decisions around it as if it were a scientifically-proven study seems incredibly dangerous.
> Steve wasn't exactly a man of science. He pulled that number out of his ass and everyone here seems to think it smells great!
Haha, what a perfect quote! Thanks
Haha, what a perfect quote! Thanks
I mean what would Steve Jobs know. He surely hasn't met many decent developers managing the Macintosh or NeXT teams or as CEO of an IT company with 100K+ employees.
Did it ever occur to you that 25:1 number might come from being in a unique position to compare the relative output of multiple engineering teams of similar sizes at Apple ?
Did it ever occur to you that 25:1 number might come from being in a unique position to compare the relative output of multiple engineering teams of similar sizes at Apple ?
As I said, why not 10:1 (a commonly repeated, equally unsupported ratio) 50:1 or 100:1? So no, the 25:1 number came from being in the unique position to spout precise-sounding, unsubstantiated numbers in an environment where nobody would argue with him. What did occur to me is there are no significant digits in that number.
Being pedantic, but I definitely have seen developers with zero productivity: so everyone else productive is infinitely better...
Excepting, there are also programmers and teams with negative productivity - work out the ratio!
Excepting, there are also programmers and teams with negative productivity - work out the ratio!
Yes. But 25 is a suspiciously round number.
He might have done a quantitative study, but there's no indication that he did. If he'd shown his working and described his methodology then I'd believe him, but since he doesn't I estimate that he probably pulled that number ex anum.
There aren't any useful metrics for coder productivity anyway. You can measure lines per day, but that's not telling you what you want to know. The best programmers aren't best because they do simple tasks twenty-five times faster than the average programmer, they're the best because they do really difficult tasks in ways that the average programmer would never, ever do.
There aren't any useful metrics for coder productivity anyway. You can measure lines per day, but that's not telling you what you want to know. The best programmers aren't best because they do simple tasks twenty-five times faster than the average programmer, they're the best because they do really difficult tasks in ways that the average programmer would never, ever do.
My boss tried to pull this quote out when he was trying to justify his defense against me saying we need to unit test.
His question to the developers was "why does it seem like when we make small changes things seem to break?"
My answer "we do not test, we need to cultivate a culture of testing. It takes some upfront effort, but it saves in the long run."
His response "that is what separates average programmers from rockstars..."
I cut him off because I knew he was going in the wrong direction, "yeah, the good ones unit test."
Him: "Well you should be able to know that if you make a change, it will have an affect on everything else, so you should test that out manually"
Me: "Unit tests cover every possible case that we can think of programatically. We can easily push a button and see if my change broke some obscure piece of code somewhere."
Him: "The difference between ...."
I tuned him out and lost a little respect. Oh, we develop a mess of a php app.
His question to the developers was "why does it seem like when we make small changes things seem to break?"
My answer "we do not test, we need to cultivate a culture of testing. It takes some upfront effort, but it saves in the long run."
His response "that is what separates average programmers from rockstars..."
I cut him off because I knew he was going in the wrong direction, "yeah, the good ones unit test."
Him: "Well you should be able to know that if you make a change, it will have an affect on everything else, so you should test that out manually"
Me: "Unit tests cover every possible case that we can think of programatically. We can easily push a button and see if my change broke some obscure piece of code somewhere."
Him: "The difference between ...."
I tuned him out and lost a little respect. Oh, we develop a mess of a php app.
Your boss must be a good developer right? So he should be able to manually go through the code of 25 developers and know what changes are going to affect everything else. If that seems naive, stupid or obviously unreasonable, this is what your boss is asking for, EXCEPT he's also asking you to produce code.
It's hard enough doing this with your own code, let alone collaborating with others. I'm taking the verbose route to say the same as the other replies:
Quit.
It's hard enough doing this with your own code, let alone collaborating with others. I'm taking the verbose route to say the same as the other replies:
Quit.
Quit.
It's a shame to hear horror stories (yes, I'll call it that), especially when it involves PHP (my bread and butter).
Luckily, our CEO trusts me and my team to retain everything good we build, and that's done via unit tests.
Found a bug that saved the company thousands? Fix it and write a test. The odds of losing out on that again are near zero. :)
Ultimately, it dose come down to culture. Good leadership understands humans are error-prone and can't retain everything we touch.
If you're into Symfony2 and dig remote work, ping me sometime.
Luckily, our CEO trusts me and my team to retain everything good we build, and that's done via unit tests.
Found a bug that saved the company thousands? Fix it and write a test. The odds of losing out on that again are near zero. :)
Ultimately, it dose come down to culture. Good leadership understands humans are error-prone and can't retain everything we touch.
If you're into Symfony2 and dig remote work, ping me sometime.
Check for better jobs in your area/remote. There are tons of places who want people who want to test.
Quit.
Quit.
One of the Jobs 25:1 people - Jean-Marie Hullot. A French Lisp Programmer who studied at INRIA under Gerard Huet. He invented Interface Builder.
http://en.wikipedia.org/wiki/Jean-Marie_Hullot
EDIT: For the backstory on Steve Jobs, NeXT, Jean-Marie Hullot, Interface Builder, Tim Berners-Lee, and the WWW this is a good read http://fds.oup.com/www.oup.co.uk/pdf/0-19-286207-3.pdf
http://en.wikipedia.org/wiki/Jean-Marie_Hullot
EDIT: For the backstory on Steve Jobs, NeXT, Jean-Marie Hullot, Interface Builder, Tim Berners-Lee, and the WWW this is a good read http://fds.oup.com/www.oup.co.uk/pdf/0-19-286207-3.pdf
I like Avie Tevanian (one of the original developers of Mach kernel and CSTO of Apple) and Dave Hyatt (architect of WebKit). Both have really helped change the industry.
I like Bill Atkinson, creator of QuickDraw and HyperCard. I don't debate that Steve Jobs was able to find and get the best work out of highly talented people, I just think the 25:1 ratio is nonsense.
This has long been known about the programmer/developer profession, that the standard deviation of performance between practitioners is extremely high compared to many other fields.
The more interesting part to me is why don't wages for this profession follow this spread. Except for the rare cases of striking it rich on equity, the compensation spread between mundane developers and excellent top notch ones with the same skill acronyms and seniority is 3-4x at best and that is probably an extremely generous estimate.
The more interesting part to me is why don't wages for this profession follow this spread. Except for the rare cases of striking it rich on equity, the compensation spread between mundane developers and excellent top notch ones with the same skill acronyms and seniority is 3-4x at best and that is probably an extremely generous estimate.
I think it's simply that code written to be 25x cleaner, shorter, and faster, will not bring 25x the revenue to the company. Coding skill is only one factor in the ultimate fate of a product.
A company I worked at has this business model where they recruit extremely cheap interns (mostly from France) and have them develop products. In their eyes it's not profitable to pay more for a better coder, since the quality of the final product doesn't have much impact on their bottom line; they sell to big business so there's no review site rating their products and clients don't talk to each other.
A company I worked at has this business model where they recruit extremely cheap interns (mostly from France) and have them develop products. In their eyes it's not profitable to pay more for a better coder, since the quality of the final product doesn't have much impact on their bottom line; they sell to big business so there's no review site rating their products and clients don't talk to each other.
You can also be a 25x developer and have net-negative product designers and biz dev people on your team that completely negate or at least greatly attenuate the value you contribute.
Besides people, you also have the value of the solution as well. A top developer creator an overkill solution for a trivial problem doesn't create much value either. The value of a solution is proportional to the cost of the problem.
Besides people, you also have the value of the solution as well. A top developer creator an overkill solution for a trivial problem doesn't create much value either. The value of a solution is proportional to the cost of the problem.
gahhhhhhhhh... I hate autocorrect. It results in typos that make you look like a non-native writer in the language and produces more interference in the mind of the reader, not less, because it's easier to read over a simple typo than incorrect diction.
"A top developer creator an overkill solution..." would have read better had whatever typo that had lead to "creator" instead of "creating" had remained in my original text.
At least red underlines instead of autocorrect highlights the error and prompts you to go back and choose the correct word (<-- perfect example... while writing this previous sentence, "word" originally had a typo and was changed to "work")
"A top developer creator an overkill solution..." would have read better had whatever typo that had lead to "creator" instead of "creating" had remained in my original text.
At least red underlines instead of autocorrect highlights the error and prompts you to go back and choose the correct word (<-- perfect example... while writing this previous sentence, "word" originally had a typo and was changed to "work")
This is so true. A "top" developer can often be a terrible development lead or software architect. Often because they try and build generic solutions to specific problems.
This is a massive problem in the Java space where you have these design pattern driven designs that are infinitely flexible but ridiculously complex.
This is a massive problem in the Java space where you have these design pattern driven designs that are infinitely flexible but ridiculously complex.
I don't think that's the right way to look at it.
If we go by simple math, developers who are 25x better/faster can launch a new product in 2 weeks instead of a year. That can make the difference between owning an entire market and not even being a participant.
Or you can take a team of 75 developers and instead use only 3. The overhead and cost and difficulty of coordination and communcation between 75 developers can just be too much for a project to succeed, but with only 3 amazing developers it becomes easy.
Also, software projects tend to reach points where they become overly complex or unmaintainable. Developers who are 25x better prevent that from happening, keeping everything working smoothly.
So it's not about bringing 25x revenue. It's about bringing revenue period, or maintaining competitiveness to continue that revenue.
If we go by simple math, developers who are 25x better/faster can launch a new product in 2 weeks instead of a year. That can make the difference between owning an entire market and not even being a participant.
Or you can take a team of 75 developers and instead use only 3. The overhead and cost and difficulty of coordination and communcation between 75 developers can just be too much for a project to succeed, but with only 3 amazing developers it becomes easy.
Also, software projects tend to reach points where they become overly complex or unmaintainable. Developers who are 25x better prevent that from happening, keeping everything working smoothly.
So it's not about bringing 25x revenue. It's about bringing revenue period, or maintaining competitiveness to continue that revenue.
"Also, software projects tend to reach points where they become overly complex or unmaintainable. Developers who are 25x better prevent that from happening, keeping everything working smoothly."
Actually, I think this is the heart of the issue in the productivity debate - I view my biggest challenge as writing code/architecture that can be maintained, easily debugged, etc, my devs (or future devs) are as a constituency for my software as well as my users.
But this is, in a big org, extremely hard to monetize, as disasters/chronic bleed avoided are not even entered into the balance sheet.
Actually, I think this is the heart of the issue in the productivity debate - I view my biggest challenge as writing code/architecture that can be maintained, easily debugged, etc, my devs (or future devs) are as a constituency for my software as well as my users.
But this is, in a big org, extremely hard to monetize, as disasters/chronic bleed avoided are not even entered into the balance sheet.
I'm pretty sure you can find a 25x spread in developer compensation at Google, and that's within a pool of great developers. But they are an exception. In general, the skill difference is too hard to quantify, and the pay disparity would cause political problems. If you think you're a 25xer the best way to capture the extra value you create might be to join or start a startup.
This is actually the conclusion I came to a long time ago and have been acting on it since. Still haven't captured that value, but it has been fun trying & haven't given up yet.
[deleted]
It was bad enough listening to this myth when it was 10x. Now it's up to 25x. Gimme a break. When you figure out how to measure programmer productivity, then you have the right to put a precise number on it. Not before.
Edit: I mean 'you' in the general sense. Not you personally.
Edit: I mean 'you' in the general sense. Not you personally.
Actually, though I can't footnote it, the meme in the early 90's being pushed by Gates & Simonyi at M'soft was 100:1 or so "orders of magnitude" iirc correctly, so actually, Jobs is a downward estimate from that.
Valve probably has the best system I've heard of for capturing this value. Each employee is peer reviewed on their value to the company and then their score gives them a relative rank in the company. That rank determines their pay. I don't know what the scale is like, but I know Valve has profit sharing to some degree, so I bet it's pretty good if you're at the top of the list.
So you have a source for this? It sounds equal parts insane and amazing. Certainly adds to the Valve mythos though.
This sounds dreadful to me.
Your peers will judge you based on THEIR ability and knowledge. Which in the IT industry is a problem because most developers are overly confident about their abilities. So you will end up with good developers being given poorer rankings.
I much prefer developers being judged on their ability to meet business outcomes.
Your peers will judge you based on THEIR ability and knowledge. Which in the IT industry is a problem because most developers are overly confident about their abilities. So you will end up with good developers being given poorer rankings.
I much prefer developers being judged on their ability to meet business outcomes.
95%'ish of every professional in every profession are just tired demotivated people who just wanna get whatever done and go back home. They'll just do the bare minimum that won't get them fired.
Programmers are just not an exception to this rule. Nothing to see here.
Programmers are just not an exception to this rule. Nothing to see here.
A good waiter will never be 25 times better than a bad waiter.
A fast construction worker will never be 25 times faster than a slow one.
Programming is fundamentally different.
A fast construction worker will never be 25 times faster than a slow one.
Programming is fundamentally different.
> A fast construction worker will never be 25 times faster than a slow one.
I actually sort of doubt this. Fields like construction often require quite a bit on-site problem-solving and quick thinking, simply because making large physical objects stick together in an ordered way is fairly complicated. When you consider also that construction work is a team-oriented profession, it becomes imaginable that the right worker could make the whole team far more effective.
And actually, even the waiter example, I'm not sure. A great waiter makes the customer feel like an honored, highly-ranked guest of royalty. A bad one fills people with hatred for the restaurant and anyone involved in it.
I actually sort of doubt this. Fields like construction often require quite a bit on-site problem-solving and quick thinking, simply because making large physical objects stick together in an ordered way is fairly complicated. When you consider also that construction work is a team-oriented profession, it becomes imaginable that the right worker could make the whole team far more effective.
And actually, even the waiter example, I'm not sure. A great waiter makes the customer feel like an honored, highly-ranked guest of royalty. A bad one fills people with hatred for the restaurant and anyone involved in it.
If construction workers are anything like carpenters or other craftsmen this rule might even go to 1:50.
Ever had a carpenter fix something in your house? The difference between a good carpenter and a bad one is enormous. A good one comes in and fixes the shit in a day or two. A bad one can delay a small project for months, they don't show up, you can never reach them, the final bill is 5x the quotation, they leave your entire house dirty, they come in, punch a few nails then they have to drive pick something up - on your expense of course. And once it's done it's not better than anything you would have been able to do yourself. Once you find a good carpenter you simply stick to him, attempting to hire a new one is too big of a risk.
Ever had a carpenter fix something in your house? The difference between a good carpenter and a bad one is enormous. A good one comes in and fixes the shit in a day or two. A bad one can delay a small project for months, they don't show up, you can never reach them, the final bill is 5x the quotation, they leave your entire house dirty, they come in, punch a few nails then they have to drive pick something up - on your expense of course. And once it's done it's not better than anything you would have been able to do yourself. Once you find a good carpenter you simply stick to him, attempting to hire a new one is too big of a risk.
A good waiter will probably be 100x better than a bad waiter. If you've never had a truly good waiter though, you'd never know just how good a skilled server can be.
A fast construction worker can easily be 100x faster than a slow one. This includes knowing how to do something, when to do it, how to prevent errors that must be corrected, managing physical tools and physical supplies, and conducting inspections. Finally, the difference between a fast construction worker and a slow one is that the fast one shows up the day he's scheduled to show up, and finishes on or before the scheduled completion date. The slow worker shows up a few months later, without all of the necessary supplies, and drags the project along for weeks or months.
A fast construction worker can easily be 100x faster than a slow one. This includes knowing how to do something, when to do it, how to prevent errors that must be corrected, managing physical tools and physical supplies, and conducting inspections. Finally, the difference between a fast construction worker and a slow one is that the fast one shows up the day he's scheduled to show up, and finishes on or before the scheduled completion date. The slow worker shows up a few months later, without all of the necessary supplies, and drags the project along for weeks or months.
This 25x thing correlates well with the "reality distortion field"
Also 250% of all statistics make 66% sense -5% of the time.
Also 250% of all statistics make 66% sense -5% of the time.
Steve also says in this recording that he thinks the talent gap is only about 2:1 for hardware engineers. I'd like to hear from anyone in that field on whether or not they agree.
Really bad hardware engineers make very expensive, hard to test, shitty designs that fail intermittently. I think HOW horrible productivity comes out in HW is different than software.
I'm pretty sure you can find 100x spread in developer compensation at Google. The ones who got in early vs. the ones who came after the IPO. They got in early because they were amazing, not because they were lucky. Not.