Hacker News Reader

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

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.

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)

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.

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.

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

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

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.

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.

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.

The best coders I know (including agavin, who comments below) are all insanely hard workers. There are a few other correlates, but these seem secondary to me:

- willing and able to rapidly learn new tools (especially languages, debuggers, build/test infrastructures, and profilers)

- understand software at many levels (so-called "full stack" programmers)

- more interested in producing a working system than in technical details

- self-confident enough to seek experts and extract information from them on areas of ignorance

- have a strong aesthetic sense of code

Definitely "being really smart" or "having a Ph.D" hasn't been a correlate in my experience; if anything, I've seen these to be negatively correlated with code production and quality.

And distribution of coding ability definitely seems to follow a normal curve; a handful of coders I know are 6 sigma out. There are many more two-sigma outliers, and tons in the middle, as you'd expect.

Definitely "being really smart" or "having a Ph.D" hasn't been a correlate in my experience; if anything, I've seen these to be negatively correlated with code production and quality.

Unfortunately this is largely the case. It's in many ways similar to why many on HN don't want to do Java enterprise LOB apps. It seems like painful drudge work. For a lot of really smart people who did their PhD -- the work it takes to build a production web app is painful drudge work. They'll happily build the prototype that proves the concept and their done. Everything else is a painful drudge work -- a solved problem ("I can reduce what's left to what Facebook did. QED.")

Um.. most PhDs in the experimental sciences involve lots of drudge work, and 14 hour days, and the people who make it are generally very hard workers. This may not be true in theory or engineering.

I have a PhD in CS. There's a lot of "drudge work" in the design and execution of experiments. I just spent four days designing, executing and analyzing experiments to see if our model was accurate and my implementation was correct. (Both are, which is nice.) But those experiments will never be published - experiments like them will, but not those. Those experiments are what I call "guiding experiments" - they're not rigorous enough to convince others that what we did works, but it's enough to convince me we're doing the right thing, and give me the confidence that things will work out as expected when we do the full, rigorous experiments.

So, yes, research has its own grunt work. And some of my code will make it into production.

> The best coders I know (including agavin, who comments below) are all insanely hard workers

I'd +1 this if I could. This is the instinct I've had for a while, and probably also the key as to why it is so rare.

I suspect a key part of it is learning how to work effectively, and avoiding burnout in the process, neither of which are trivial to achieve.

Thanks for the comment, extremely interesting!

To me, insanely hard work always connotes working 80 hours/wk and not having (or spending time with) a SO, kids, or other hobbies besides the job.

I don't know if that's what you mean, but that kind of life is not one I would go for, even assuming I am capable of being more than one or two sigmas good.

I definitely don't mean to imply working 80+hr weeks. Perhaps the parent does, but I personally don't think it's healthy nor do I do I think it's conducive to avoiding burnout let alone happiness. You can work hard in a 40hr week.

I don't think that's true. I consider myself an ok coder, but I'm lazy. I work in bursts, but even a good day is likely to be less than six hours of actual work. Bad days are near 0. If I had the work ethic of the parent commenter, I could get a hell of a lot done in a reasonable amount of time.

Some of that laziness is because I'm not crazy about what I'm working on. Being truly honest with myself, though, it may be an internal defect that will prevent me from becoming a great coder until I get over it.

Anyway, that lack-of-laziness is what I think the parent was attempting to describe, not 80-hour weeks.

It partly depends on "stage of life" as well. Most of the outlier coders I know are 40+ now and don't work 80 hours weeks; nor do they ignore their families, etc. However, all did at one time in their lives, and all still have a strong work ethic. Work ethic often goes along with long hours, but beyond a certain level of experience, I see excellent producers working smarter and not just harder, to use the cliche. It could be that it takes the proverbial 10k hours to get to that level of experience; I don't know.

"- understand software at many levels (so-called "full stack" programmers)"

People should start using "multi-stack" to describe those jobs when PHB's decide they know best which technologies to use, and not surprisingly, they're all incompatible and different than last month's technologies.

simply a genetically determine brain configuration

I sincerely doubt this. I think some people like it more in the beginning, so they get the positive reinforcement very early. But I think that what tends to happen is people convince themselves a head of time "This is hard, I'll never be able to do it" which becomes a self-reinforcing thing.

you know that was my first reaction to the email too (actually my first reaction was petty jealously that I didn't get that email)

when I thought about it some more, that might have be a really nice break for someone who deserved it, and the type of person who took that class and was in the top 1,000, is probably the type of person who would make the most of a nice break

take away, the more I thought about it the less I had a problem with it

Oh I'd be being dishonest if I said there wasn't a petty ego blow there on my part too, esp. since there were a few answers that I just didn't check properly. Part of it is that I was simply frustrated that it had become that sort of thing. Had a perhaps romantic view of this kind of thing. Certainly don't mean to take away from those who scored so well :)

Human nature. We all are the victim of "ego" once in a while in our life.

Ego is what bring us down from the top of cockyness mountain as well. The fall would make us humble (and hopefully learn something from it).

At the end of the day, I believe human should learn to live with each other than to shove one another.

I think there's a meme in the term “greatness”. Perhaps a better formulation of the rule is the more traditional one, that it takes 10 000 hours to reach your peak at whatever it is you're practicing.

It's not automatic (you still have to do the right things), and you can be great way before that (especially relatively speaking).