Google I/O Talk: The Myth of the Genius Programmer

[cdleonard]

I found a very interesting talk that I believe is worth sharing: http://code.google.com/intl/es-AR/event ... ammer.html. If you don't feel like wasting time watching people talk you can also read these posts by one of the presenters.

The basic argument is that a lot of programmers are way too insecure and don't share their code until it's "perfect". Instead they want to wait until they build something "perfect" that and reveals their geniues. Any thoughts on this?

Arguably something like this would affect the Ogre community more because people here play a lot more games and enjoy "pwning the n00bs".

[xavier]

Haven't looked at the sources posted, but are they talking about open-source or commercial/closed-source development? Because with the latter, you don't get a say in when the code is released.

[stealth977]

Well, they are talking about both, the argument is that mostly programmers choose to commit changes only when they think it is perfect, which in turn causes the other team members not able to see how the code is evolved or even worse if there is a design flaw, it is mostly too late for it to be changed during the commit time (countless hours been already spent on it, making it such a waste).

The authors claim that committing changes on a regular basis, no matter its flawed or not, helps other team members understand the code better (feeding the code in small chunks) , also they claim that by this way, the other team members can pinpoint the design flaws very early in the code and make suggestions to correct it from the start so that countless hours is not wasted on born-with-design-flaws code...

ismail,

[jacmoe]

Arguably something like this would affect the Ogre community more because people here play a lot more games and enjoy "pwning the n00bs".

Care to elaborate? I don't see the relation?

"The Myth of the Genius Programmer" is a talk by Brian Fitzpatrick and Ben Collins-Sussman, creators of SVN.
The talk is a response to Linus Torvalds' Google Tech Talk on GIT.

Linus's talk focuses mainly on the technical decisions behind GIT, and lambastes some of technical decisions behind SVN, which Brian and Ben started. Brian and Ben spend some time defending some of the decision making that went into SVN, although they adopt an agnostic "wait and see" attitude on the technical differences.

A major part of Linus's sales pitch is that GIT tends to hide "bad branches" and encourages experimentation, so that you don't have to know what everybody else is doing. Ben and Brian point out the importance of community and the value of documenting failure.

Both of these talks have valid points. About source control and community.

[Klaim]

The difference of point of view is indeed very interesting.

Thanks for the videos

[Jabberwocky]

The authors claim that committing changes on a regular basis, no matter its flawed or not, helps other team members understand the code better.

I don't entirely agree with this.
First off, committing "flawed" code is much more likely to be buggy code. For many projects, committing buggy code is a serious problem - for example breaking the build might seriously impact other team member's ability to work.
Secondly, "flawed" code is more likely to contain poor commenting, poor organization, and temporary hacks, all of which make the code more difficult to understand.

or even worse if there is a design flaw, it is mostly too late for it to be changed during the commit time (countless hours been already spent on it, making it such a waste).

This is a more convincing point. Basically they're saying, don't code in a vacuum. Involve the team with what you're working on. For a game, this should not only include other programmers, but designers, artists, and producers (depending on the task).

Depending on what you're working on, it is often a good idea to get feedback from other team members before you're finished. But you don't need to check in your code to receive feedback from it. It's easy enough to hash out the design up-front with other team members, discuss your progress in a team meeting, or bring another programmer over to look at your code when you've got a tricky issue to work out.

[danharibo]

The authors claim that committing changes on a regular basis, no matter its flawed or not, helps other team members understand the code better.

I don't entirely agree with this.
First off, committing "flawed" code is much more likely to be buggy code. For many projects, committing buggy code is a serious problem - for example breaking the build might seriously impact other team member's ability to work.
Secondly, "flawed" code is more likely to contain poor commenting, poor organization, and temporary hacks, all of which make the code more difficult to understand.

committing broken code is a bad idea, but you shouldn't try to "perfect" the code before committing. Obviously not commenting the code in first place isn't a good idea, I find that going over comments I've written helps me to understand what on earth I was thinking when I wrote the code

[stealth977]

Just to correct a misunderstanding, perhaps my english is not that good and i used the wrong term

By saying flawed code, i didnt mean broken code or not working code. What i meant is, the code you are working on may have issues which is not appearant at first sight, or it may have design flaws. If you continue working on it for lets say a month and than commit it, it becomes a "code bomb". Hard to review for other team members and quite a big loss if it is discovered that the code has design flaws after its "perfected" by the coder.

Here "perfect" code is subjective. Something that you think is "perfect" may not mean the same for others, and in most of the situations your "perfect" may not be the ideal solution. So, committing regularly:
1 - Makes it easy for others to review your code
2 - You always have the chance for an "Early Recovery", recovering from the design flaws or shortcomings of your code or even recovering from not yet visible problems of your code, early in the coding phase, so that later you dont have to scrap a so called "perfected" code

Lets think this way:
You are building a Pizza Tower, hiding the construction area, working on it for a year, perfect it and then open the tower for public use, just to realize that it is bending every year and soon it will collapse.
What if you havent hidden the construction area, let other architects view your progress and warn you about that small design flaw you made during constructing the base?

ismail,

[Jabberwocky]

If you continue working on it for lets say a month and than commit it, it becomes a "code bomb".

Agreed, a month between checkins would be way too long under most circumstances.

By saying flawed code, i didnt mean broken code or not working code.

Yeah, maybe the word "incomplete" is better than "flawed". I think the key is to decompose a big task into smaller chunks so you can check in more often. Still, whatever you do check in should be properly designed and coded, and generally indicative of the final code quality - perhaps with some clearly identified hacks to "clamp off" sections that aren't finished yet.