Some Lesser Known Truths About Programming

&#62; 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.<p>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.<p>See <a href="http://leanpub.com/leprechauns" rel="nofollow">http://leanpub.com/leprechauns</a> (disclosure: I'm the author) for the long form, with a detailed bibliographical investigation of the "10x studies".<p>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.

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

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

&#62; "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."<p>This hasn't been the case on any non-trivial project I've been involved in.<p>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.