[agavin]

There is such a difference in coding output. Having had perhaps 50 work for me over the years (and being one myself), the top guys do perhaps 10x the output of the merely "very good" guys. And near infinite with the mediocre ones who on tough projects actually suck more time than they contribute.

The good guys also come in and contribute right off the bat. Like Christophe Balestra, who now is co-president of Naughty Dog. When he arrived on Jak 2 he was pounding out real working stuff the first or second day. By the end of the game (one year later) it was clear he was so kick ass that we promoted him across like 15 others guys to be co-lead with me on Jak 3. And he continues to kick ass to this day. I just site him, but I had the pleasure to work with around half a dozen other totally awesome guys too. Still, the "good" guys will take a system and do a great job with it over weeks. The great guys will knock it out in like 24-48 hours.

Lots of articles on this kind of stuff at my site too:

http://all-things-andy-gavin.com/video-games

[rdouble]

I've found that a difference between the "top" guys and the "very good" guys is that the very good guys are smart enough to do great work, but just aren't as into it. I know many guys who were mathematicians, physicists, or near-professional violinists and fell into programming because they couldn't make money from their other interest. These guys are often really good, but you can tell they wish they were doing something else. That said, the worst dudes are the ones who are really into it, but are really bad.

[kenjackson]

For the poor performers they may be nothing you can do. But for the merely "very good" are there practices that Balestra can teach them?

For example, one thing I've seen that can increase productivity by a factor of ten is good debugging skills -- which are generally teachable. The other thing is to get people on things they're excited about. Mentally checking out is another area I've seen strong people lose time.

[agavin]

Good debugging is key, and as anyone who ever worked with me will note, I'm a fantastic debugger (in no small part because I'm cold, rational, and rarely get upset). I keep meaning to write up a post for my blog with "Andy's rulez of debugging." There are really very simple, but very effective.

Like: "don't assume" and "divide and conquer" (they do require a bit of explanation)

[jcheng]

Please do write that post, I for one would love to read it.

[EmployedRussian]

I wonder if you have much to add to http://www.amazon.com/Debugging-Indispensable-Software-Hardw... (which I really like).

Rule 5: "Quit thinking and look" is (I think) equivalent to your "don't assume".

Rule 6: "Divide and Conquer".

[agavin]

I'll have to check that out. Although my advice will be free :-) But I'm sure that many many other good debuggers have developed the same basic techniques independently. Still, the vast majority of programmers could use some improvement in this area. "Quit thinking and look" is exactly what I mean by "don't assume." People tend to get wrapped up their own view of things and forget that empiricism really wins the day. There is often even fundamental denial, as in "what bug? I haven't seen it." Clearly if someone saw it, unless they were hitting the crack pipe, it's real.

[joe_the_user]

I often find that looking at the code hard and adding the appropriate tests and asserts can be better than immediately pulling out the debugger. Assert are continually testing your assumptions where you can only see them once in a debugging session.

[ntoshev]

Debugging is almost always about uncovering wrong assumptions, but I don't see how you can do without assumptions. Every line of code assumes certain state of the program that it operates on.

[agavin]

You can't have no assumptions. But half the time I help someone debug something they begin with, "it can't be in this part of the code" which is often unfounded. Now if you PROVE that it isn't, that's a different matter.