Being a "Great Coder" and 10000 Hours

There really is a meme here I think, and it relates to ego.<p>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.<p>For example, I took part in the recent Stanford AI class, though not about programming specifically, I was utterly down-heartened when I heard they sent out those 'send me your CVs you clever people!' emails to the top 1k students, it just made me feel like a lot of people were taking part in order to participate in a 'look how much cleverer I am than you' pissing match.<p>That kind of things ruins the collaborative 'learning for the joy of learning' side of things and has a tendency to make the whole thing into a sort of nasty elitist thing. I really wish they hadn't done that (N.B. I did fine on the course - 98.7% - so this isn't sour grapes).<p>The biggest problem with anything like this is the idea that 'here is some test of inherent intelligence - I am far better than you so you are inherently unable to do this thing' which is just the biggest barrier to actually trying to do something - if you think you inherently suck or at least are simply mediocre, your motivation to do that thing is severely reduced.<p>or perhaps I'm just ranting/projecting here :)

A little off topic but somewhat relevant: When someone asked Larry Wall why there aren't any Perl certifications to classify the experts, he replied "I'm not going to tell people whether they're certified or not. My approach to language design has always been that people should learn just enough of the languages to get their jobs done. They shouldn't have to learn the whole language to begin with. But with certification, you have to be learning the whole language."<p>In my own experience, this is especially true if you're self-employed / startup guy. Am I a great PHP coder? Not by a long shot. Does it in any way affect our user-experience or how much money we make? Again, not by a long shot.

It's important to also continue striving for self-improvement. If you hit a level where you've stopped wanting to learn more and started wanting to simply compare yourself to others, of course you'll look good by comparison - but you're not getting any better.<p>I started programming using Python. When I started, I wanted to understand the "feel" of Python programming, and that was all my mind could comprehend. Now that I have a decent smattering of Python knowledge, I now realize I don't have a total grasp of transfer protocols and I should probably learn a lower-level C language as well. I started off not knowing one thing, now I have added two more.<p>I'm still a better programmer, but now I realize I'm clueless about even more stuff than I was before.

<i>People would rate you "great" but you'll be able to say "How would you know?". At which point, the better you get, the worse you'll know you are. Anybody who rates themselves as "great" is probably on the uphill side of the learning curve.</i><p>This attitude annoys me greatly. I understand Dunning-Krueger and all, but I still don't buy the idea that skill is inversely proportional to confidence. I think it's simplistic to think that confidence directly implies lack of skill and vice-versa.<p>I mean clearly no one likes an ego-maniac who acts like a know it all. But at the same time, sometimes people are right when they say good things about themselves. Even if they act completely narcissistic.<p>In fact, I would say that maturing has done nothing but increase my confidence in my skill level. I think that I can say that I'm a good programmer and that I hope to be a great programmer some day without being cocky or egotistical. It doesn't mean that I'm always right or that I don't make mistakes. But at the end of the day, I have confidence in my abilities.

The problem:<p>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 successful while some guy you consider mediocre is winning.<p>What matters in real world is productivity. Ability to discover things quickly. Learn quickly. Learn to understand and properly state problems. Search for solutions quickly. And then use the best tools at disposal to build things in as little time with acceptable quality in the problem domain. Intelligence and knowledge of facts in this system at maximum fastens your rate of success nothing more nothing less. But yes practice helps. But practice in the right areas.<p>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.<p>Apart from practicing writing programs. Learning API's, best practices, tools, techniques and your other usual day to day programming tasks. You also need to practice to be a better team player, you need to learn design, you need to learn customer interaction skills, you need to learn how to gather requirements.<p>You need to learn how to manage resources - time, money and people effectively. You need to learn effective ways of running software teams. The list goes endless.<p>Its no longer "Can write awesome code" == "Success". There are a gazillion parameters that will decide you success. And programming is just one of many of them.<p>Here is the shocker. You don't really a 1000 years of life to give 10 years to each. And even if you had a 1000 years of life you would be bored of giving 10 years to each and you would keep forgetting what you did decades back.<p>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.

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

Wouldn't it be awesome if one of those "looking for a technical co-founder" types would say they were looking for a programmer "who knows how bad they are"?

Curiously I think you missed the more important point of the post. The literate programming insight is clearly more valuable as a "take-away" idea.<p>Literate programming has the potential to allow a program to "live". Certainly it allows a program to outlive the authors. Most programs no longer have the original authors available. Look at the thousands of dead programs on sites like Sourceforge. Or consider the number of commercial programs that are no longer maintained by the authors.<p>Your program should be written to pass the "Hawaii test". That is, you give a new hire your literate source code, send them on a fully paid trip to Hawaii for two weeks. When they come back they should be able to maintain and modify the program as well as the original authors.<p>Literate programming is not documentation. It is a form of communication. You need to motivate code you introduce. You need a good story line. You need to get it past an editor-in-chief.<p>See "Lisp in Small Pieces" for a great literate program example.<p>Tim Daly daly@axiom-developer.org

<i>The better he got, the worse he knew he was.</i><p>The inverse Dunning–Kruger effect: <a href="http://en.wikipedia.org/wiki/Dunning–Kruger_effect" rel="nofollow">http://en.wikipedia.org/wiki/Dunning–Kruger_effect</a>

'Great' doesn't mean anything if not a relative value. So saying you are great just means saying you are one of the best. That's all that counts.. who cares if you're not as good as the mythical uber-coder?<p>Sure, once you reach the other side of the bell curve, you realize you don't know anything, <i>compared to everything there is to know</i>, but that doesn't make you anything less than great.

I liked the comment about literate programming. When I need to write a new set of related functions (or classes if I am using an OOL), a great way to start is by writing function stubs, and then write the internal comments. Even better to not immediately write the code. Anyway, this works better for me than TDD.

one of the things everyone seems to forget about the whole 10000 hours thing is that the research says it's 10000 hours of mindful practice. that's a lot harder than 10000 hours of practice...

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

if i understand correctly, the dunning-krueger effect means i should just accept i am god-like????