8 ms·

Some Lesser Known Truths About Programming

63 points by moonsoonmenu 14y ago

tharris0101 14y ago
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.
- loeschg 14y ago
  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.
- michaelfeathers 14y ago
  There's actually a book about that effect: http://www.amazon.com/Breakout-Principle-Creativity-Performance-Productivity/dp/B000H2M8O2 http://www.amazon.com/Breakout-Principle-Creativity-Performa...
Morendil 14y ago
> 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 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.
- fusiongyro 14y ago
  Came here to say this. It frustrates me to see this BS repeated on an almost daily basis, I can only imagine how much it must infuriate you.
- jdlshore 14y ago
  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. Horse pucky.
- gaius 14y ago
  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.
- GlennS 14y ago
  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.
- ExpiredLink 14y ago
  Just wanted to post a link to your article. See also: http://news.ycombinator.com/item?id=4118034 http://news.ycombinator.com/item?id=4118034 http://www.reddit.com/r/programming/comments/n8fqi/there_is_not_a_shred_of_evidence_that_the_best/ http://www.reddit.com/r/programming/comments/n8fqi/there_is_...
notJim 14y ago
Why are these described as lesser-known truths when we read an article about them every week, or even multiple times a week? If there's a group of people who don't “know” these things, they are not to be found on HN. Beyond that, I feel like this is just a aimed to stroke our egos by confirming the biasses we already have. I'd much rather read an article about lesser-known truths.
stephengillie 14y ago
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.
- sbornia 14y ago
  couldn't agree more.
gav 14y ago
> "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.
- svdad 14y ago
  > 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.
danso 14y ago
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.
npsimons 14y ago
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.

63 points by moonsoonmenu 14y ago

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.

loeschg 14y ago
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.
michaelfeathers 14y ago
There's actually a book about that effect: http://www.amazon.com/Breakout-Principle-Creativity-Performance-Productivity/dp/B000H2M8O2 http://www.amazon.com/Breakout-Principle-Creativity-Performa...

Morendil 14y ago

> 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 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.

fusiongyro 14y ago
Came here to say this. It frustrates me to see this BS repeated on an almost daily basis, I can only imagine how much it must infuriate you.
jdlshore 14y ago
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. Horse pucky.
gaius 14y ago
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.
GlennS 14y ago
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.
ExpiredLink 14y ago
Just wanted to post a link to your article. See also: http://news.ycombinator.com/item?id=4118034 http://news.ycombinator.com/item?id=4118034 http://www.reddit.com/r/programming/comments/n8fqi/there_is_not_a_shred_of_evidence_that_the_best/ http://www.reddit.com/r/programming/comments/n8fqi/there_is_...

notJim 14y ago

Why are these described as lesser-known truths when we read an article about them every week, or even multiple times a week? If there's a group of people who don't “know” these things, they are not to be found on HN. Beyond that, I feel like this is just a aimed to stroke our egos by confirming the biasses we already have. I'd much rather read an article about lesser-known truths.

stephengillie 14y ago

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.

sbornia 14y ago
couldn't agree more.

gav 14y ago

> "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.

svdad 14y ago
> 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.

danso 14y ago

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.

npsimons 14y ago

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.