> A good programmer is ten times more productive than an average programmer. A great programmer is 20-100 times more productive than the average. This is not an exaggeration – studies since the 1960′s have consistently shown this.
That's folklore, not fact. The short form of the argument is: the studies are old, not very credible, and based on a notion of "productivity" which is most generously described as vague.
See http://leanpub.com/leprechauns (disclosure: I'm the author) for the long form, with a detailed bibliographical investigation of the "10x studies".
The rest of the "truths" in the OP are of a similar caliber: they are more properly called "opinions". A better title would have been "Some opinions about programming that you don't necessarily share". I happen to agree with some of them; but that doesn't make them true.
And the link to the 2004 "study" is actually a news report about the Standish Group's CHAOS report, which itself is actually a very loose survey from a company that has an interest in exaggerating the state of the "software crisis." Look at the frikkin report title: it's the 90's version of linkbait.
Furthermore, the CHAOS report defines "success" as "shipped on time and on budget" without regard to profitability or anything else people here on HN know is involved in real success.
As a result, when the CHAOS report says 51% of [surveyed participants self-report that] projects "fail[ed] in a critical aspect," what they really mean is that 51% of projects didn't ship exactly on time and on budget. If a project shipped a month late and made $10 million, it's still considered unsuccessful.
I only have my own antidotal experience as a consultant with probably less than 100 companies. But I would say that it's impossible to quantify programmer productivity so specifically as 10x or 1000x. It's a lot more complicated than that. One person may be a monster at fixing bugs. Another is incredibly gifted at designing object models. One person is great at the visual design. It's further complicated by the fact that 10 great lines of code may be more "productive" that 100 lines of garbage.
That being said, I do believe the spirit of these kind of statements to be accurate. Some programmers seem to be constantly inspired, always surprising you with a solid, clean and simple solution. Others seem to get bogged down in complexity and create fragile solutions with bugs that continue to pop up for years. The latter needs to be nudged in the right direction regularly. If left to design anything that is too big on their own without guidance they can and will cause disasters.
If you have ever had to manage programmers, you know that there are one or two guys who you give the really complicated problems - and then you don't have to stress because you know it will be perfect - even better than perfect. The other group you have to be more selective with their tasks and plan to check in more frequently. I spend a fair amount of my time trying to figure out why one struggles so much and the other does not - and how to help the one who struggles to become better. I don't consider myself a master, but I am one of those people for whom it seems to come easily. I'm not sure if it's experience or just a certain type of mind? I just know that I've observed it many times at many different companies.
The truth is that the difference is even more extreme. Good programmers are much more than 100 times more productive than average programmers.
Good programmers create features, designs, and implementations which are more elegant, cleaner, more understandable, more robust, less buggy, and much more valuable to the end user.
Consider J. Average Coder. He implements a feature in a typically half-assed way. The feature isn't well thought out, it barely works from a user perspective and has horrible usability. Anyone who doesn't think this is how average coders work has never experienced software developed by average coders. More than that, it's buggy and hacky and it serves as a development time sink, a tar trap for the entire development team. Bugs get reported and because of how messy and convoluted and fragile the code is it takes a lot longer to fix each bug. And in the end the effective productivity of that coder ends up being astoundingly low. Because the end result is a single feature that has taken a tremendous amount of coding and especially bug fixing on his part and on the part of his co-workers. The ratio of total end-user value to total invested dev-hours is incredibly low.
Now compare this with Dudley Code-right. He comes up with not only an excellent feature with high-user impact but he also comes up with a very elegant way to implement it. Boom, it's done, and nearly bug free. What bugs are found are quick to fix because the code is so clean and well put together. The ratio of total end-user value to total invested dev-hours is through the roof in comparison. Not just a factor of 100 different, but factors of thousands different.
There are tons of easy examples out there in the real world. Look at open source projects with tiny dev. teams, like nginx or varnish, and the value of those code bases relative to the effort behind them, then compare that to some random line of business software abomination from the enterprise trenches that has had hundreds of thousands of dev-hours dumped into it.
This is called "an argument", one in which you appeal to some stereotypical descriptions of programmers which may or may not be accurate.
It's not the same thing as what we call "evidence", which consists of actually going out in the world and collecting information from more than a tiny and highly biased sample (which, like it or not, is a fair description of the set of programmers most of us will run into over the course of a career).
For instance, for one "Dudley Code-right" who is just as you describe, how many "Dudley Code-fast" exist, who are just as you describe except that no one else can understand their elegant constructions and it turns out that the "nearly bug-free" part, well... disappoints? Dudley Code-fasts look highly "productive" for a little while, then cause big problems down the road.
What we're dealing with here is the representativeness heuristic, which often makes us misjudge statistical truths. It's akin to the way people are much more afraid of flying than of driving, even though the former is orders of magnitude safer.
And some things you don't have to prove, because you've seen them with your own eyes. Have you ever seen a programmer that is crazily more productive than another? If yes, then you know what we're talking about.
It might not be 10x or 20x --which is hard to measure anyway--, but we've all seen programmers that are far far better than others.
What's crazy to me is why would anyone try to argue otherwise. Isn't the same true for EVERY other field of activity?
There are painters (e.g Picasso) that are crazily more prolific than other painters. There are inventors that are crazily more prolific than other inventors (cough Tesla cough). There are athletes that are crazily better than other athletes. Writers. Composers. And so on. On some of those fields (like sports) we even have objective ways to measure how better they are. But in all fields, we know there are geniuses, crazy good guys and average ho-hum dabblers.
So, why exactly, would it be any different in programming?
>Thomas Kinkade was, I believe, far more prolific than Picasso. But I do not want Kinkade-grade developers.
I meant "prolific" in the sense of producing lots of GOOD work, not merely churning stuff.
Which for Picasso, it was. If anything, the critics agree (which is as far a metric as you get in the fine arts).
>There needs to be some other metric for software development. Figuring out what that should be, and how to accurately measure it, is non-trivial.
Sure, but the "good programmers are X times more productive than bad" (as I see it) is not about producing more code, but about producing more of what a project needs. I.t they are qualitatively more productive, not quantitatively.
Come to think of it, it sounds more of an obvious statement, almost a tautology or truism: "good programmers produce MORE good code than average programmers".
Consider Dudley Code-right. He implements a feature which isn't well thought out, barely works from a user perspective , and has horrible usability. He comes up with a very elegant way to implement it. Boom, it's done, and nearly bug free. What bugs are found are quick to fix because the code is so clean and well put together.
Now compare this with J. Average Coder. He implements an excellent feature with high user impact in a typically half-assed way. The ratio of total end-user value to total invested dev-hours is through the roof in comparison. Not just a factor of 100 different, but factors of thousands different.
Peopleware uses similar studies with similar numbers, but it also adds the caveat that people at the same companies tend to be relatively closer together.
So even if you were to accept that some programmers are orders of magnitude better than others, at it's likely that some of that is about things like noise, interruptions, network effects of putting a lot of good people together, and general corporate culture stuff.
Monkeywrench: brilliant people are 100 times more productive than average people?
My thought is that programming sees similar dynamics as the rest of the world. There are amazing people out there who build companies or change governments or move the world forward in a way that is beyond most individuals' mental capacity. Why would engineering be any different?
It is strange that the idea that "A good programmer is ten times more productive than an average programmer" is almost always taken out of the context of the human race as a whole.
Continuing my thought pattern... I'd take 1 Tim Cook or Henry Ford over all the operations consultants and hackers and people in the world. That doesn't make average ops people worthless, nor does it mean that tactics that Cook or Ford have taken in the past can't be employed by almost anyone.
I think it really comes down to the ability to find a problem and invent a solution, a rare gift indeed.
The link you provide is not a citation to a peer reviewed journal article as your claims about scientific evidence would suggest, but is a link to a self published ebook hat you are charging money for. Please take your shilling elsewhere.
I believe there must be a kernel of truth in it and it's this: there are lots of people who are 10x more productive than their peers at one very specific thing. But that one thing, by itself, is rarely enough to complete a project. Over the long term, everyone tends towards the average by definition.
>See http://leanpub.com/leprechauns (disclosure: I'm the author) for the long form, with a detailed bibliographical investigation of the "10x studies".
Forget about the studies. We all have seen empirical evidence of this.
I'm disappointed that an essay about the writing of less code failed to mention this: you will spend far more time reading your own code than you will writing it: so don't take syntactic shortcuts that obscure meaning.
I only relatively recently grokked this, and it's helped me to stick to best practices and naming conventions when in the past, I'd just throw in the first thing off the top of my head.
The last point is the best. I frequently step away from a project and take a shower or go for a walk to think about what I'm doing. Usually the problem is that I'm over complicating things and the answer will come as an "Ah-ha!" moment.
Conversely, I have to do something like read or watch a movie before bed to get my mind off of whatever project I'm working on or else I will lay awake thinking about it.
I'm actually starting to find that many times I'm more productive, feel better, and I believe do better work when I do my "thinking" on paper/white board. When I sit down at a computer to do the actual coding, my brain isn't processing a ton of information. It's just using what I've already written down.
This blog post seems to be about pigeonholing other people - "John is a bad programmer because he does $x / Mary is good because she does $x". Labeling people doesn't help them. Pointing out problematic behavior doesn't directly lead to solutions. It doesn't tell people how to change their behaviors to remediate the problem.
These generalizations seem too high level to be of any use, anyway. Good programmers want to program, and their interest will carry them up through skill levels. They'll want to learn and improve, and if they can't learn from your workplace you're wasting their time and yours. Bad programmers don't want to program, and should do something else.
First and foremost, these are not "lesser known". Most of these have been discussed ad naseum since at least MMM and Peopleware. Second, as others have mentioned, at least the one about some programmers being 20-100 times more productive is far from "truth"; it's highly debatable with data for and against, and if anything is "true", it's that the data is inconclusive.
> "Although most software is made by teams, it is not a democratic activity. Usually, just one person is responsible for the design, and the rest of the team fills in the details."
This hasn't been the case on any non-trivial project I've been involved in.
However, a defining quality of successful projects I've been involved in is that there is one person driving the overall design and that person runs things closer to a dictatorship than a democracy.
> However, a defining quality of successful projects I've been involved in is that there is one person driving the overall design and that person runs things closer to a dictatorship than a democracy.
Yeah, that's been my experience too, but I keep running into people who think everything runs better if the whole team decides and everyone gets a say. OK, there's definitely merit in getting input from what one hopes is a bunch of smart people, and it also helps morale for everyone to feel like they're being heard, but at the end of the day I think there really needs to be one or at most a few people who make the final decisions.
That's folklore, not fact. The short form of the argument is: the studies are old, not very credible, and based on a notion of "productivity" which is most generously described as vague.
See http://leanpub.com/leprechauns (disclosure: I'm the author) for the long form, with a detailed bibliographical investigation of the "10x studies".
The rest of the "truths" in the OP are of a similar caliber: they are more properly called "opinions". A better title would have been "Some opinions about programming that you don't necessarily share". I happen to agree with some of them; but that doesn't make them true.