The Myth of the Genius Programmer

This is a really good point. It allows the social structure of the project to grow and change in a very natural way which makes it not only easier to adapt as committers come and go, but effortless.

This is part of the problem with DVCSes - you do your work off in a cave, and then when it's "perfect" you submit it for inclusion.

Note that SVN doesn't lack this problem - it can even make it worse. It's just far more common in my experience for people to do work in a cave somewhere with a DVCS and then throw it all over the wall in a huge hunk than with SVN, because it's so easy to maintain that fork off in neverland.

After all, just look at the comments (on this article no less!) about how "once I clean X up, I'll put it on {github,bitbucket,google code}." That's the kind of attitude that means it'll almost never (statistically) be seen by anyone other than the original author (which is likely true anyway, only one of my projects has ever really attracted anything resembling attention).

Note that Ben isn't convinced that this risk of DVCSes outweighs their (admittedly large) benefits. It merely aggravates a very serious problem to a point where it becomes a complete nightmare.

Yup. They wrote Subversion and continue to encourage people to use it.

Perhaps they should tone down their egos and realize that Subversion was not really that great of an idea, and there are now several competing tools that do everything Subversion does, but better.

I don't like the "there are no geniuses" phrase, especially since they then have to back down and say, "Well, it isn't that there are no geniuses -- just that they're extremely rare," which just obscures the point further. The point I think they're trying to make, though, is that the myth of the hero programmer who writes a perfect program and releases it to a world full of unhelpful clods is counterproductive.

If you want to dispute their point, then answer their question: What successful, widely-used project was created entirely by one lone genius?

It's easy. Until your code is good, no one gives a damn about it. Even if it's good, you'll still have to shove it down people's throats before they care. So don't worry that "someone might see your bad code". They won't. Nobody cares.

I think one of the key lessons for me, which is very easy to grasp intellectually but much harder to internalize, is that any nastiness you receive in the short term doesn't really matter (and often comes from people who don't really matter). If you succeed in the long-term, that's what you will be known for, and all of the scorn directed at your early works will seem irrelevant. You should therefore do whatever maximizes your chances at long-term success, which includes taking the risk of exposing yourself to humiliation so that you can get better faster.

It's one of the things I really admire about, say, Jeff Atwood. He's consistently bashed here and elsewhere for being incompetent, and it's not undeserved: even though I consider myself a pretty poor programmer at the moment, I can often tell when he says things that are fallacious or ignorant. And yet, with Stack Overflow he has been involved in a project more successful than most people's projects here. I would never mistake him for the mythical genius programmer, and I may be puzzled at the attention he receives or his persistence about writing topics he doesn't know much about, but when I see how he keeps writing and keeps building useful things even when everyone is publicly explaining to him all the ways he sucks, I wish I had his cojones.

With this attitude* , only criticism about how the code is serving its purpose is relevant. If someone criticizes it (or I imagine they will) because it's Lisp (or because isn't), or because it uses design patterns (or because it doesn't) and the criticism doesn't seem to make a difference to its purpose - it's just kind of bemusing.

* Hard to do.

EDIT ah... having now read the slides, this is one of the things they're saying.

Minus four used to be for trolls but now it seems it for disagreement? Even if you think I'm wrong here, does this post merit this treatment? (I moderate base on opinion for posts in the positive range but negative has, uh, negative connotations).

I would say that I've have been in a number of situations where one team member was indeed more far more productive than another. But as far as I can tell, this was a product, itself, of the breakdown of team-process. Either the productive programmer wouldn't tell the unproductive programmer how they did their magic or alternatively, the unproductive programmer wasn't interested in finding out.

One way to see team organization is as a way to prevent one person from always being "on the critical path". The most effective way is give skills to those who don't have them.

There might indeed be no simple metrics that will support my view but I suspect this is because it is complex than such metrics can describe.

There have been some studies lately showing that, in general, few people gain their abilities through "raw talent" rather than hard work see http://www.scientificamerican.com/article.cfm?id=the-expert-... . I guess these are what I'd fall back on for any proof. Whether person is willing to learn a given skills is whole other problem but I think these studies show that if a person is willing to learn, they are able.