This article got voted Best “Everything Else” Article of May 2015 on CodeProject.
It trended on Reddit, where it generated an at times heated discussion.
If you have ten programmers, the best one is probably at least five times better compared to the worst one. No shit.
Define better: he works faster, produces less bugs and writes more readable, logical and maintainable code.
Programmers aren’t bricklayers or carpenters, but they are often treated as such. (not that there’s something wrong with these occupations)
“Why would I get a senior when I can get two juniors for the same price?”
“This feature takes three months for one programmer? Let’s just put two more on it so we can have it in a month.”
And why is that? Because there’s no decent, fool-proof way to measure the productivity of a programmer, I guess? Whatever can’t be measured, gets ignored. I’ve seen it too many times. [Tweet]
Also: would you rather have two juniors deliver your baby, fix your car, perform a lumbar puncture, or would you rather have one senior? Despite popular belief, the act of producing code is not a commodity. [Tweet]
The best programmers are up to 28 times better than the worst programmers, according to “individual differences” research. Given that their pay is never commensurate, they are the biggest bargains in the software field.
Robert Glass, Facts and Fallacies of Software Engineering
If you really want to compare, then I’d say programmers are more like writers.
Some writers can produce a page turner that goes on to sell millions, while another might produce something that is so boring it extinguishes the fire it’s thrown in!
Yet, they both produced a book and thus they’re both writers, and you wouldn’t know the difference unless you’d really start reading the book.
Programming managers have long recognized wide productivity variations between good programmers and poor ones. But the actual measured magnitudes have astounded all of us. In one of their studies, Sackman, Erickson, and Grant were measuring performance of a group of experienced programmers. Within just this group the ratios between the best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements!
Fred Brooks, The Mythical Man-Month
Let me give you an actual (yes, IRL) example
(Names have been changed to protect the innocent.)
The Company (no, not the CIA, just some software company) needs to implement a new module in their flag product. Mr. Lousy is free at the moment; great, let him start right away!
After four months of tinkering, Mr. Lousy is finally finished. The QA team finds loads of bugs and inconsistencies that need to be reproduced and reported back to Mr. Lousy. He then spends two weeks fixing those bugs and finally delivers a new version! Those are damn annoying bugs and Mr. Lousy often thinks about them while he stares into the distance.
This test/fix cycle is repeated two or three times.
The users have been promised this new module. Sales will be able to sign with some new customers that have been waiting for this module. There’s considerable pressure to just get it out there and it gets incorporated in the next release. Hurray! Champagne for everyone!
Unfortunately, the new module is still rather buggy. Customers are excellent at finding previously undetected bugs. So they contact support. The support team tries to find out what’s going wrong, whether the customer’s confused about the feature, whether they’re confused themselves, or whether it’s just a bug and can be reproduced. Yada, yada, yada. They decide to file a bug report. Unfortunately, Mr. Lousy is wreaking havoc—oh, I mean he is working on another project at this time, and he can’t just drop everything to fix them pestering bugs.
(And we haven’t even talked about whether the code is maintainable, logical and documented. Because sooner or later someone else will need to make enhancements, add features, etc.)
But, uh-oh…there are some bugs that Mr. Lousy can’t seem to fix. Also, new bugs turn up and no one is sure if they are indeed new, or just weren’t discovered before. Support gets pestered. Sales are getting annoyed, because those new customers find the module is too unreliable for day-to-day work and want to cancel their contract!
And, finally, the boss asks Mr. Rockstar Developer to take a look at the code.
Mr. Rockstar isn’t really able to make heads or tails of it and sees lots of senseless constructions. He advises to rewrite the code, thinking it’ll take about a month. He gets to work and hands over the finished module in just a few days longer than his original estimate (he’s Mr. Rockstar, not Mr. Perfect). Besides some minor bugs that are quickly detected by the QA team, everything works as expected. The QA team starts to worry: if they’d all be like him, they’d be out of a job. Mr. Lousy thinks that Mr. Rockstar is an arrogant twit, but this isn’t really relevant.
The revised module gets released. Everybody is happy because it finally works. Hurray!
Congrats! Rejoice! Champagne again!
By this time, it’s usually forgotten that Mr. Rockstar managed to do in about one month what Mr. Lousy couldn’t in 7-8 months.
The huge difference between these two developers only surfaced here because they performed the exact same task.
By writing less code that does more, and by writing maintainable code that has fewer bugs, a good developer takes pressure off of the QA staff, coworkers, and management, increasing productivity for everyone around. This is why numbers such as 28 times productivity are possible and might even seem low when you look at the big picture.
Phil Haack, 10 Developers For The Price Of One
Now, what is the worst that could happen here?
Mr. Rockstar eventually notices that he’s considerably more productive than Mr. Lousy. And, don’t be fooled, he doesn’t need to get the same task to find out. This is his job; he’s damn good at it and he easily recognizes bad code written by a bad programmer. Still, he’s pretty sure (or absolutely sure) that Mr. Lousy is earning more or less the same amount of pay. He gets disgruntled and/or he quits. And you’ve just lost a considerable amount of production power for your development team.
Even if he doesn’t quit, how do you think he’ll feel when a release/project is running late and the whole team is ‘punished’ with overtime? This is the inevitable waiting to happen.
If you’re really out of luck, he’ll be replaced by another Mr. Lousy.
So, why does this go unnoticed so often?
Because it’s easier to ignore this issue than to fix it—at least up to a certain point, and also because no one likes to rat on colleagues and be the cause of someone losing his job; because Mr. Lousy has three kids and just bought a new house; and, most importantly, because it’s very hard to measure a developer’s productivity, unless you’re really able to compare them both doing the same task as in the above story.
Are you a developer? Do you agree? Please let me know in the comments. Almost all non-tech people think ‘one developer day’ is an exact measurement. [Tweet]
Now, I’ve been thinking a lot about this: measuring a developer’s productivity. I’ve often been jealous of salesmen because their remuneration is based on their accomplishments. I’ve got some ideas (still ripening) on how to separate the wheat from the chaff. I’ve also been thinking about and will be posting about how to identify, attract and retain the Mr. Rockstar developers.
Sign up here to get notified about these and future posts via email.
Related articles:
10 Developers For The Price Of One
What Makes Bad Programmers Different?
What Makes Great Programmers Different?
Discussion on StackExchange: A good programmer can be as 10X times more productive than a mediocre one
Who am I and why am I telling you this
I’ve worked as a professional developer (that is, getting paid for it during a daytime job) for over 10 years. I made my first commercial product (a game) in 1989. Although this didn’t make me rich, it still felt great (I was 16 at the time). A couple of years later, I sold the idea of one of my games, and it eventually got released on the Nintendo Gameboy (and other formats) by Bandai! I can tell you from experience that it’s very satisfying to see something you thought up (including the name) actually being sold in a shop.
In 2008, I took a non-tech job at a very technology-driven company. I wanted to learn about running a business in general, about the sales process,… everything non-tech that happens in business. Well, my tech chops probably got me hired and are still very useful, but they are no longer an essential part of the job.
I don’t program for a living anymore (or rather: at the moment), but often tinker with various new technologies in after-hours projects. To me, it’s the same as reading a good book—exciting and relaxing at the same time.
In my current role, I often encounter people who express certain misconceptions or who lack basic knowledge of the development process. In their role (often CxO), this basic knowledge could make a huge difference.
Enlightening them isn’t on our agendas during these encounters and I usually just leave it at that. When appropriate, with the CxOs who I know on a more personal level, I’ve tried to convince them of their incorrect or incomplete view of the software development process (usually to no avail).
Now, because I like to think via writing, and I really think I can provide value here, I’m making a series of blog posts about the various clichés and misconceptions I’ve encountered in this industry.
Sign up here for more enjoyable, insightful and (dis)informative posts!
Header photo by Moresheth, used under CC BY 2.0 / Cropped from original
March 31, 2015 at 1:27 am
I really liked the read and have experienced the Rockstar vs Lousy in a startup. In that case it was accepting credit card payments – one guy did it in a week where the other spent months and it never shipped. In the first case, if static code analysis were in use, we would have seen his code was hopeless much faster. What are your thoughts on linting and code analysis to help send out some early warning signals to others?
(bias disclaimer: working on a startup in this space)
March 31, 2015 at 2:24 am
Yours is yet another reminder of some of the time-tested truths of software development. The best are not just slightly better than the worst. There is a wide gulf of productivity and quality depending on who is assigned to each project.
As your story illustrates, this can lead to disgruntled employees who feel unappreciated and undervalued. This leads me to two questions. From an employer’s perspective, how do you attract and retain these top talents. From the point of view of an employee, how do you promote your own talents and get rewarded for your work?
March 31, 2015 at 2:45 am
Great write. I’ve been using the same writer anology. I also think we piss away a lot of software dev productivity by making tasks collaborative that really are’nt. If you want to have a bestseller, is it a good idea to have 10 junior developers in india write it?
March 31, 2015 at 4:13 am
Its not only correct that its hard to measure developer productivity but no one takes into account developer peak and trough cycles either. I can go full on for about two iterations and then I slump for an iteration.
March 31, 2015 at 9:56 am
Sprints do not apply to rockstar developers, as they`re better at splitting tasks and prioritizing them. If they had to deal with unneeded management overhead, they would not be rockstar in the first place.
March 31, 2015 at 4:48 am
I think that there’s a problem with the whole “Rockstar” mentality. By separating performance and manifesting them in 2 different types of people, you might be ignoring a totally different type of collaboration and work.
Lets think about different environments depending on different circumstances.
Exhibit A (which I don’t have much experience with.) A small team of collaborative programmers / designers / project leads / QA which works collaboratively, intelligently, and calmly. They get the work done and go home for a beer after work. They use “agile” technologies and have the methodologies in place for working quickly.
Exhibit B. A true to life organization which has concerns dating way back when. They use legacy code that constantly needs to be re-factored, and they have strict organizational tendencies.
Exhibit B is more likely to fertilize a situation where one can BE a Rockstar. Due to the separation of roles in the organization – business needs are met much quicker but development needs are not so much. Development is entirely driven by the immediate needs of the business which are often driven by profit. These situations are sink or swim and Mr. Lousy’s and Mr. Rockstars will pop up according to the situation.
Although I don’t have much experience with an organization like Exhibit A – the egoless programming and happy community seems perfectly at home with being further away from life as ever.
March 31, 2015 at 3:22 pm
I would actually argue that it’s easier to spot the Rockstars in exibit A. Most of my work has been in small teams similar to what you described. Everyone is given a small set of tasks and there’s a lot of code reviews and overlap all throughput the process. This makes it much harder to hide bad developers as each team member must be able to pull their own weight. It makes it blatantly obvious who takes WAY to long on tasks, and who needs design help.
March 31, 2015 at 7:20 am
I agree. Right now I work on a team with 3 other developers; two of the developers are new and not really up to speed, so I won’t count them. The remaining dev is a front-end web dev, and I usually make the back end for him. I’ve noticed that it usually seems like he’s making all kinds of progress to higher upsbecause they can easily see what he’s done- go to this page, boom, all kinds of new things. When it comes to my work, even though I made the core that the front-end guy relies on, it looks like I’ve spent a lot of time dicking around and haven’t done much. But, I have in two weeks made new functionality that the previous programmer said wasn’t possible.
March 31, 2015 at 8:24 am
The answer here is to stop specialising on front end or back end and learn to code the full stack. Or stop complaining.
If you stop building the backend features it forces your boss to assess your value… or maybe those backend features aren’t really that complex.
As a former backed developer who now codes regularly on both sides I can honestly say that both worlds are hard – but the value gained by learning both parts is gold.
March 31, 2015 at 11:31 am
That’s not the point though. In Tyler’s case, because he has been casted into the “backend” development role, his work might not be as appreciated – even though its equally complex.
The article though tries to cover this by recommending that the higher ups be better versed with the development process – so that they can retain good talent.
March 31, 2015 at 3:36 pm
You can specialize on backend, you just need to sell you work better.
You see when the front dev, tells your boss that changing the button from blue to yellow will increase sales conversion by 8% he is doing a napkin calculation or pulling numbers out of his ass(unless he has real A/B test reports to back that up).
Now if you change all yous apis from xml to json you can run a crappy microbenchmark and report to you boss that the new json parser is 20% more efficient than the older xml one and that will save the company 8% in hardware costs yearly(or you can take time and run a real benchmark to see the impact).
PS: Your work has value and it’s your fault others can’t see it. Shove it to their faces.
March 31, 2015 at 9:45 am
This reminds me of another kind of programming – optimization. I worked for a large organization with 500 programmers, and a large base of code written in ‘c’. A module needed to be sped up and my office mate and I were well known to be effective at this sort of thing, but the boss wanted to showcase one of her engineers and help her to get promoted. When she was done, the code was slower than the original. So it was passed to me and my office mate. Like your story it was done right the first time and at about 1/2 of the staff hours.
March 31, 2015 at 9:55 am
You dont mention what I call “janitor syndrome”. Mr Rockstar has now spent a month mopping up Mr Lousy’s code. Playing the janitor. But because Mr Rockstar has not been present in all the requirement meetings etc, he has to catch up on some required knowledge. The time he takes to rewrite Mr Lousy’s code is actually more than the time he would have taken to write the code if he had been on the project from day one.
Meanwhile, Mr Lousy has had this problem taken off his plate. He is suddenly free to start with other work. It turns out that the boss has a backlog of things to be coded, and hands off the next item to Mr Lousy to implement. You know how well that’s going to turn out.
In the mean time, Mr Rockstar has completed the rewrite, everyone is happy. The boss asks Mr Rockstar if he can quickly look at Mr Shoddy’s project, which is experiencing similar problems to those Mr Lousy’s experienced. Turns out its a similar situation. Because customer’s are screaming, Mr Rockstar has to rewrite that too, as in yesterday. Again, he doesn’t have all the information required, but he manages to find everything, and delivers a working result in a slightly longer time than would have been the case if he were to have coded the project from the beginning.
Again, everyone is happy, but look! Mr Lousy has in the meantime been working on a new project. Its a mess, customers are screaming. The boss would really appreciate Mr Rockstar having a look at what is going on. Again, he is mopping up after someone else.
Eventually, Mr Rockstar is a full time janitor. He spends all his time mopping up after others. Ultimately, having the other two around is wasting money, and time as Mr Rockstar would actually have completed the projects faster if he were involved from day one. Also, there would be a lot fewer annoyed customers.
April 1, 2015 at 3:11 pm
Say, just wanted to say that I agree wholeheartedly with this post. I’ve seen that scenario a lot in my career, across multiple organizations.
The janitor problem, in my experience, usually ends up with a situation where Mrs Lousy and Mr Shoddy are seldom held accountable, as they are usually pulled off of the project gone bad to work on the next great thing. They then leave Mr Rockstar to deal with their mess, and sometimes it’s Mr Rockstar who gets associated with the problem, even though he was just the guy brought in to save the day.
I have found myself questioning whether this happens because management is ignorant of the situation, or whether it is intentional because they are trying to prop up and protect certain classifications of employees.
Maybe it’s a bit of both.
April 2, 2015 at 10:29 pm
@Soren I actually know what management would think. You’re the rockstar, you should do more job, because that’s the teamwork. Lousy etc would be the backup if you quit.
ehhh… more money? You’re not a manager right?
April 2, 2015 at 10:25 pm
@Jesse that’s really my daily tasks too, struggle for rewriting projects without ‘requirements’ but actually many hidden requirements.
March 31, 2015 at 11:42 am
The 28:1 ratio is often cited and originates from a paper published by Grant & Sackman’s in 1967. Some argue, eg. http://wwwipd.ira.uka.de/~prechelt/Biblio/varianceTR.ps.gz, that using Grant & Sackman’s data, that the real ratio is more like 14:1. Which is still an impressive number.
March 31, 2015 at 12:21 pm
You said Mr Rockstar and Mr Lousy performed the exact same task. They did not. Mr Rockstar benefited from significant hindsight: with the semi-working prototype from Mr Lousy he had the _final_ requirements, and a list of bugs to avoid.
He may be more productive than Mr Lousy, but this experiment isn’t enough to measure how much. We need more details about the task at hand to asses the situation.
March 31, 2015 at 2:42 pm
Great article, and 100% agree. I started out as a salesman, then project manager, then designer, then front-end, then backend, and finally product manager and can completely emphasise with everything mentioned here 🙂
March 31, 2015 at 4:52 pm
At story about Mr. Lousy and Mr. Rockstar you miss the point that crafting software from scratch and rewriting (or porting) a software is two different task. Rewriting the software usually can make 10 times faster that crafting from scratch because when rewriting, the material is already there.
I don’t really agree with the following statement:
“The huge difference between these two developers only surfaced here because they performed the exact same task.”
Maybe not the same task, but the same goal.
March 31, 2015 at 8:07 pm
Even though Mr. Lousy’s code was terrible, the bulk job of development got done, which is to detail out the requirements of the end product. So I agree with your sentiment, the comparison is not fair as the tasks would be substantially different.
In cases like this, when the stars align for a disastrous outcome, it is often a good idea to take a step back and do a post mortem analysis of the project. I am confident that Mr. Lousy was only partly to blame for the outcome, and the biggest problems are yet to be uncovered and dealt with.
That’s not to say that Mr. Rockstar and Mr. Lousy aren’t different in levels of proficiency, just that there is a lot you can do to even out the differences and make lousy programmers shine. The challenges in this occupation exists on multiple levels, and you can usually isolate a number of root causes.
March 31, 2015 at 6:04 pm
I agree with everything except the assumption that such discrepancies don’t exist in “commodity” jobs like bricklayers and janitors. As someone who currently works in IT and has previously worked in the trades I can assure you that varying abilities in trades can have very significant impact on projects. Especially on big jobs, where there are a lot of different trades (carpenters, plumbers, electricians) who need to work in a coordinated fashion and be aware of how their work affect those who come after them. It cost a lot less to fix a plumbing leak or make an adjustment BEFORE the sheet rockers cover all the pipes. The best tradespeople are aware of these issues will attempt to work accordingly. The key difference between this scenario and a software development team is that on a dev team, everyone is ostensibly on the same team, whereas in the trades, the carpenters and electricians and plumbers usually all work for different companies. So from a job performance assessment perspective there is significantly less incentive for them to work together. And yet, the best, the ones who take pride in their work, usually do make the effort, often resulting a huge savings. And just as with “rockstar” developers, often unappreciated by management.
Officially, coordination is the job of a general contractor, just as in software it is the job of the project manager. But we all know that in reality a project manager can only do so much in that regard – at some level it is the responsibility of every dev on the team to work as a team. Likewise in the trades.
March 31, 2015 at 10:00 pm
Speed of development is not a good benchmark. Nor is the volume of code
generated. I worked on a project where the lead developer generated code
at a furious pace, introducing a new feature at each monthly meeting. By
any “metric” this would appear amazing. The code leveraged patterns and
conformed to all the latest buzzwords.
Unfortunately, reality bit the project hard. The first ship was delivered to
the customer in a state that wouldn’t even compile. After the lead left we
found out that nobody else understood the primary data structure. There
were no explanations. There was “javadoc” of the API but it was useless.
The final code could not process much beyond toy input.
The lead “retired into management” at another company and is generally
hailed as a first-rate programmer. Hit and run rockstars.
April 1, 2015 at 1:23 am
I always knew one good programmer could match more than one bad programmer, I just never allowed myself to admit that it could equal a whole team, because that is a hard thing to convince a non-programmer. But I have definitely seen and demonstrated it in practice.
April 1, 2015 at 9:50 pm
I’m currently in a position where i have to assume a rockstar role while being lead for the web part. At one point it is very interesting since I have vigouriously taken ownership of the codebase and ramped it up to a much more maintainable level in three months, i do have a coworker that could be described as a mister lousy. Though a great guy, he doesn’t evolve and barely manages to follow my lead, and has a hard time understanding his anti-patterns. My output is 3 times as high and 3 times less buggy and I’ve revamped one third of all the modules he developed since I joined.
Management knows this but he is still usefull for the legacy clients so as long as he doesn’t work on the payment system and other critical processes. And i now know I have to ‘janitor’ from time to time, still hoping to get that one amazing devops intern i’m hoping to find
April 5, 2015 at 2:06 pm
It’s lovely to reason about Mr Rockstar, Mr Lousy and Mr Shoddy, but where does this leave slow, cautious coders like me? I don’t consider myself Mr Rockstar because I don’t think I’m fast enough. Certainly Business seems to wish I would hurry up.
I think of myself as a solid coder. I read a lot. I try to understand the tech I’m working on. I implement design patters, and spend a LOT of time thinking about design and architecture before I start coding. My code is neat and manageable, fairly bug resistant and usually easy to maintain or extend. However, I need to build a complete mental model before I can start coding, of how thing fit together. Once the model is done, the code flows like water from my fingers, but until that point I’m staring blankly at the wall while the project manager does the Impatience Fandango around my chair.
In your world of Ms Rockstar vs Mr Lousy/Shoddy, there seems to be no space for me. I’ve grown cynical of fast “rockstar” coders because they don’t seem to spend a moment on planning; features are all over the place and duplication abounds.
So am I wrong? Am I just a stodgy old-timer? Should I be grasping the intricacies of the model faster or just not think about it anymore?
I think there are more variations of coders than just the Rockstars and the Whatevers, but since these are the only two ever mentioned, if you’re not the one you must be the other, and I don’t agree with that.
If code mattered more than how quickly it took to write it, I might have a little rockstar in me 🙁
April 5, 2015 at 2:39 pm
“My code is neat and manageable, fairly bug resistant and usually easy to maintain or extend.”
Well, that seems like a Mr Rockstar to me.
“However, I need to build a complete mental model before I can start coding, of how thing fit together. Once the model is done, the code flows like water from my fingers, but until that point I’m staring blankly at the wall while the project manager does the Impatience Fandango around my chair.”
Yes, but you say your code is manageable and fairly bug resistant. So when you deliver, it’s pretty sure that you’re finished and won’t spend an unknown time squashing bugs and annoying colleagues and customers in the process.
The image I’ve got of a Mr Rockstar isn’t someone who starts hammering the keyboard 2 minutes after he/she got a new task.
And there are indeed more variations of coders, but this is just an example. I wanted to make the point that there can be a lot of difference between someone who knows what he’s doing and someone who really hasn’t got a clue.
When programmers think about 10x coders (how it seems to be called), they often see themselves as average and can’t believe that there are others who possibly work 10 times ‘better’.
But, they should rather think about the worst vs the best programmers they know. And then I guess most will agree there can be a 10x difference (and unfortunately that management is totally clueless about it).
June 1, 2015 at 5:27 am
I’m bricklayer who is learning programming and I thought I would google bricklayer programmer to see what would come up. It was nice read and I can see your point but bricklaying would be a bad example for the point your trying to make not because you need to know a lot, even though you do need to know a lot if you want to be respected within the trade but because the skill levels are really varied which is why a lot of firms do it on pricework for example I layed 1000 bricks in one day and earned £330 for the day but the worst I’ve seen is a 30 yr old man put a piece of lego in between his cross joint to get exactly 5mm and he layed about 50 in one day, it was an absolute joke.
July 20, 2015 at 10:13 am
Interesting writeup which I agree to except the writer analogy – pure BS. How would you explain Twilight and 50 Shades of Grey? Those have shoddy editing, errors everywhere, and still sell like hotcakes. So, not a good analogy.
July 21, 2015 at 10:05 am
At least they reached their goals: be interesting/entertaining and sell millions.
And 99.9% of their readers won’t notice the errors or shoddy editing.
I’m sure there are errorfree books out there with excellent editing that were recycled to toilet paper after X years. As well as bug ridden pieces of software with a crap interface that went on to become hugely successful.
But OK, there might be better analogies (which?).