Steve Jobs: the difference between superb programmers vs. average ones is 25:1
fastcompany.com
fastcompany.com
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.
Haha, what a perfect quote! Thanks
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 ?
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.
Excepting, there are also programmers and teams with negative productivity - work out the ratio!
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.
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.
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.
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.
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
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.
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.
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.
This is a massive problem in the Java space where you have these design pattern driven designs that are infinitely flexible but ridiculously complex.
"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")
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.
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.
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.
Edit: I mean 'you' in the general sense. Not you personally.
Programmers are just not an exception to this rule. Nothing to see here.
A fast construction worker will never be 25 times faster than a slow one.
Programming is fundamentally different.
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.
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 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.
Also 250% of all statistics make 66% sense -5% of the time.