
Some Lesser Known Truths About Programming - moonsoonmenu
http://dotmac.rationalmind.net/2010/08/17/some-lesser-known-truths-about-programming/
======
Morendil
> 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.

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

~~~
olavk
You can create a fictional story to prove anything.

~~~
batista
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?

~~~
jamesbritt
_So, why exactly, would it be any different in programming?_

Sadly, it's not.

Thomas Kinkade was, I believe, _far_ more prolific than Picasso. But I do not
want Kinkade-grade developers.

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.

~~~
batista
> _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".

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

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

------
stephengillie
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
couldn't agree more.

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

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

