Live data from Hacker News

Being a "Great Coder" and 10000 Hours

groups.google.com

21–30 of 70 posts

Re: Being a "Great Coder" and 10000 Hours

#21
post #5

There really is a meme here I think, and it relates to ego. Having said that, I definitely do think there is truth in massive variations between programmers, though I personally think that is a combination of a small pre-requisite talent (the ability to code at all, which I think a surprisingly small amount of people have - simply a genetically determine brain configuration), and mostly attitude + hard work. For exam…

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.

Re: Being a "Great Coder" and 10000 Hours

#22
Revisiting your old code is like reuniting with an old friend, and also your friend is now disfigured. Despite this evidence that I've improved so much in 10+ years of writing code, my self-assessment has stayed constant: very good, close to great. (This must be how Zeno's arrow feels.) Tim Daly's post provides some welcome clarity. I'm happy to still have a ways to go. "The lyf so short, the craft so long to lerne."

Re: Being a "Great Coder" and 10000 Hours

#23
post #17

Earlier quoted context omitted.

Why do you say it is the inverse and not the regular Dunning-Kruger effect?

Surely silvestrov miswrote and meant "converse", not "inverse". And it's because the classic statement of the Dunning-Kruger effect is that the unskilled have an unrealistically high estimation of their own abilities. It doesn't talk about what the skilled think.

Inverse is correct.

D-K effect is "If a person is unskilled, then they have high estimation of their abilities."

Converse is: "If a person has a high estimation of their abilities, then they are unskilled."

Inverse is: "If a person is skilled, then they would have a low estimation of their abilities." <-- this matches silv's assertion

Re: Being a "Great Coder" and 10000 Hours

#24
post #20

The problem: As it is mentioned in the email. People tend to believe, being great is about knowing a lot of facts and stuff from memory. Having information about stuff others don't know. While the fact is intelligence and knowledge only acts as catalyst in the path to success. They are not success or don't lead to success in themselves. Unless you don't understand this you will keep wondering why you are not getting…

"If you believe reading algorithm and data structures text books and searching for puzzles online will make you a good programmer, then I'm not sure. It may prepare you for interviews, it may also get you a job a bit web giant. It may make you look super intelligent in front of a panel or your team. But in terms of producing software for solving business problems, those facts from memory and even their practice at maximum serves as a catalyst not a crucial ingredient to success."

I call this the difference between being functionally and theoretically great. After finishing my undergraduate, it dawned on me that my education gave me a theoretical ability. Outside the classroom application is what yields functional ability.

"So, just be more productive and iterate your work endlessly. Find flaws and fix them. Do it in iterations. You will be taken care of."

Absolutely agree here too, refinement I think is a big factor to success.

Re: Being a "Great Coder" and 10000 Hours

#25
post #22

Revisiting your old code is like reuniting with an old friend, and also your friend is now disfigured. Despite this evidence that I've improved so much in 10+ years of writing code, my self-assessment has stayed constant: very good, close to great. (This must be how Zeno's arrow feels.) Tim Daly's post provides some welcome clarity. I'm happy to still have a ways to go. "The lyf so short, the craft so long to lerne."

Well look on the bright side, in Chaucer's time the "lyf" was shorter. Chaucer himself died at 57.

Re: Being a "Great Coder" and 10000 Hours

#26
I, of course agree with point author makes in this post, however 10,000 hours is also meme that Malcolm Gladwell uses to sell his books. I read articles that disprove his assertion and show that often he will fudge data to make a point.

Still 10,000 hours is really good metaphor and it should be understood as such. It is a lot like that left and right brain, sounds really good and people pick this up because it sounds good.

Re: Being a "Great Coder" and 10000 Hours

#27

I, of course agree with point author makes in this post, however 10,000 hours is also meme that Malcolm Gladwell uses to sell his books. I read articles that disprove his assertion and show that often he will fudge data to make a point. Still 10,000 hours is really good metaphor and it should be understood as such. It is a lot like that left and right brain, sounds really good and people pick this up because it sound…

The 10,000 hours predates Gladwell. He just wrote a book based on existing research. I haven't seen anything that actually disproves the assertion (again, it's not Gladwell's). Do you have references?

Re: Being a "Great Coder" and 10000 Hours

#28
post #5

There really is a meme here I think, and it relates to ego. Having said that, I definitely do think there is truth in massive variations between programmers, though I personally think that is a combination of a small pre-requisite talent (the ability to code at all, which I think a surprisingly small amount of people have - simply a genetically determine brain configuration), and mostly attitude + hard work. For exam…

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

Re: Being a "Great Coder" and 10000 Hours

#29
post #28
post #5

There really is a meme here I think, and it relates to ego. Having said that, I definitely do think there is truth in massive variations between programmers, though I personally think that is a combination of a small pre-requisite talent (the ability to code at all, which I think a surprisingly small amount of people have - simply a genetically determine brain configuration), and mostly attitude + hard work. For exam…

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…

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.

Re: Being a "Great Coder" and 10000 Hours

#30
post #22

Revisiting your old code is like reuniting with an old friend, and also your friend is now disfigured. Despite this evidence that I've improved so much in 10+ years of writing code, my self-assessment has stayed constant: very good, close to great. (This must be how Zeno's arrow feels.) Tim Daly's post provides some welcome clarity. I'm happy to still have a ways to go. "The lyf so short, the craft so long to lerne."

Whenever I read some of my old code, I am always surprised at how although my code was more simplistic than what I write now, there is a certain amount of elegance and efficiency that I have lost over time. Almost like, in an effort to become a better programmer, I now waste too much time trying to be "fancy".
Post reply on HN