Aside from the tone, maybe, this article is not 'one for the masses.'

Jony Ive didn't just sit down and whip up the iPod, to use Spolsky's example. We don't see the blood/sweat/tears that goes into it. From Ive:

One of the hallmarks of our team is this sense of looking to be wrong ... It’s about being excited to be wrong because then you’ve discovered something new.

Obviously Ive has the creative ingredient. And some are going to be predisposed with talent. Michael Jordan may have had his famous "4am club" where he hit the court every morning to just drill, but so did Scotty Pippen, and he never hit the Jordan high note clutch performances that make my jaw drop watching 20-year-old replays. So I see your point, that talent matters. But the other way to look at it is that Jordan was just better at learning from his mistakes in those 4am practices.

So no, this is not some pedestrian piece of feel-good soup. Great work, in programming, design, anything, is about repeatedly pushing a boundary, recognizing where you messed up, fixing it, and repeating that all over again. The people who do this best are the people who believe that by iterating they can get better. This works even as you get all the way up into the stratosphere of a field.

[1] http://www.dailymail.co.uk/home/moslive/article-1367481/Appl...

So maybe there is something to being part of a "4am" club.

http://www.maxpreps.com/news/WpxTIZzCckWkptFeAcuDrw/how-mich...

Don't know if it was actually at 4AM or not.

It could partially be natural talent, however much of it is nurture. Carol Dweck has proven that the growth-mindset can be taught. Parents, friends, communities, media and school systems alike can promote "fixed" mindset thinking through various means, thus limiting learning from mistakes. It's incredible how much harm someone can do by steering someone off the growth-mindset path.

Who succeeds is a function of what projects they were working on. And that, is almost purely random and a result of circumstances. We like to think that Sergey and Larey were more brilliant than anyone else, for example, but the truth is they just stumbled into the right thing at the right time.

Don't discredit yourself as a programmer for not yet having a huge stroke of luck.

You're also using a limited angle of success (Larry and Sergey's business success via google). Many of the other "best programmers" on your 1000 person list may have non-commercial success (their creative project leads to a highly cited paper for example).

If you just took the top 1000 programmers (again assuming you could) in 2003, it's unlikely that Mark Zuckerberg would have been one of them. Not that he wasn't a great hacker, but what metric could have demonstrated his creative/business abilities as an undergraduate?

Of course luck is involved in anything. Einstein was "lucky" that he happened to be obsessed with the relative speed of light to different parties at a time when we knew a bit about how light/gravity etc worked. Perhaps if he'd been born in Newton's time, his style of intellect would not have had the same impact. Nonetheless we can, in hindsight, only measure someone's achievement, not his/her luck.

No doubt hyper-achievement (like Einsteins' or Zuckerbergs') is evidence that the achiever possesses a high degree of work ethic AND talent with at least a bit luck thrown in. No doubt that you would agree Hyper-achievers are a subset of "Potential Hyper-achievers" (those with talent & work ethic) and someone's level of achievement will roughly correspond to his/her personal characteristics.

In a particular poker game, it's mostly luck whether you come out ahead, but over time (as in life) those who practice harder and play smarter will (usually) come out on top.

I would argue luck does play a big role, and that they weren't lucky enough to be born into a country with the standard of living, educational resources, and number of tech jobs that Americans have is the major differentiating factor.

Also it is a bit of a logical fallacy to say just because luck is not the main factor in success that being unsuccessful means you are lazy or dumb rather than unlucky.

You can take the luck argument too far though. You were lucky to be born as the you that you know because there were millions of other sperm competing to fertilize your mother's egg.

But honestly, I came pretty close to "winning" by the time I was 10 years old. I was born in one of the richest countries of the world, to well-off parents who were science/technology-minded, attending a good school district, etc. I also happen to have computer science as one of my strengths from a young age, partly due to foresighted parents who sent me to an after-school Logo program, and partly due to what feels like natural affinity. That pays well, while I could just as easily imagine being gifted in something less-lucrative, like music or history (I'm personally completely in awe of people who have perfect pitch and what seems like an innate sense of rhythm). I had to do relatively little on top of all that to succeed, at least compared to what other people would've had to do to succeed similarly. Basically had to not completely fuck it up. (And I assure you I am lazy as shit compared to a lot of people doing less well.)

When I see "fail fast", what I really think is: "increase your sample size".

But you can't directly control luck. You can directly influence the other factors, and while luck does play an important role, so do other factors. To borrow a quote, "The harder I work, the luckier I get."

In this view, the lucky may not have recognized opportunity better, just created better opportunities for themselves (through hard work). Even if this notion isn't completely correct, I like how it incentivises working rather than waiting.

Edit: corrected my phone's overzealous auto-correct.

ps. huge fan of Empire! thank you sir for working on that game. i think Sid Meier cited it as a design influence for Civilization as well.

"In the fields of observation chance favors only the prepared mind."

A factor in that is developing a strong associative memory. This means seeking out many many kinds of knowledge and experiences and constantly trying to connect them together. It's not banging "random" ideas together, because your associative memory filtera it down.

tpatke: > it just doesn't apply (and I am a huge fan on Dweck's work). This article is one for the masses - not people who are trying to create the next Google

aristus: > defining characteristic of highly creative people is their ability to change their mind at will. ... A factor in that is developing a strong associative memory ... seeking out many many kinds of knowledge and experiences and constantly trying to connect them together

Being wrong, persisting, and trying to learn from the mistake takes effort. It's difficult, and I suspect as difficult as (if not directly linked to) exerting self-control. Connecting thought is here: http://psr.sagepub.com/content/11/4/303.short

A good question for Moser/Dweck would be: is the physiological response of a child to a mistake a function of their blood glucose levels? I suspect that it is: anecdotally, people are a lot more optimistic and willing to explore an issue instead of yielding to to surface obstacles if they're on a sugar high.

I hadn't thought about it in terms of Dweck's work on open-mindedness but it seems like accepting failures and persisting probably fall into the category of tasks that cause ego depletion. Very interesting.

I wondered this as well. Even if it's not necessarily glucose-focused, there are a ton of angles. Depression? The two ends of manic/depressives? Sleep -> mood -> mistake response? Talking to an attractive member of the opposite sex and having it go well/not well?

I suspect that Moser/Dweck would find that programmers in a state of flow encountering a compile/runtime exception would exhibit significantly lower amplitude signal associated with immediate negative response.

Since ERN amplitude is associated with better learning, it might be the other way around, that people in flow are producing stronger ERN's and correcting their mistakes faster.

Now this being said, in the environments where I work, I have met a lot of top-notch programmers and a much larger number of mediocre programmers who crank out huge quantities of unmaintainable code. And of course unmaintainable code is contagious: if you work with it, the quality of your own code suffers.

And so I have come to a contrarian perspective on a lot of this.

The difference I think is that the top notch programmers tend to be interested in improving. There is nothing worse than reading through the SQL-Ledger codebase and realizing that despite some modest improvements in security over the years (though not enough IMO) the coding style has never improved (\%$form? Really? Still? And no 'use strict?' what will it take?). Instead they make up for a lack of self-improvement with extra brute force effort in things like testing and debugging.

So this leads me to conclude there are two fundamental types of programmers out there: brute force programmers (the majority), and those programmers who substitute quality of effort for quantity of effort.

The majority of programmers are mediocre and never hit high notes because they believe that what matters is how much time and effort they put into programming. The other programmers spend less time and effort coding, and more time and effort thinking about coding. They recognize that this is where the key investment lies, and that time spent here saves a lot of effort elsewhere.

One problem with programming is that you rarely get immediate feedback on the mistakes that matter---areas like style, clarity, maintainability, and elegance of design. It's only if you go back and question your ability in these areas can you improve. But time spent thinking about these things, going over past efforts and critiquing them, is time that is not spent programming.

I sometimes think programming should be learned first through an apprenticeship, then through journeyman programs where an individual learns from many accomplished programmers, and finally certified to take on students.

But sure, it's suggestive of what you say.

For example, in this day and age of fast processors, abundant memory, large hard-drives, you can't expect a novice to put much emphasis on efficiency. He'll code and will run his program just to see the output appear almost instantly. A veteran will look at it and shake her head, but that's because she knows that back in her days, code this inefficient guaranteed that you'd spend the day in the lab just waiting to see the first letter of the output. Don't expect the newbie to learn that lesson any time soon, with his blazingly fast laptop, on which he's working comfortably from his bedroom. Now, hand him one of those snail computers at his next internship and watch the transformation operate.

But the manifestation more relevant to the real world is not having the experience base to realize it's biting you in the ass. Specifically, even though X is working, it could be working better, for less effort. Or another common case is X is not working and you misidentify why ("lazy developers not willing to do the work" instead of "used the wrong paradigm for the job", for instance).

The difference is that an expert will be able to make a good decision about that trade-off. A novice is restricted to the tools and practices they are familiar with - they might come to the same conclusion, but not for the same reasons.

When I'm working with code that doesn't have it, runtime errors significantly lengthen the time between insights, as I hunt for the root cause of some bug.

The general point is that you do better work in small increments and revisions than you do, like Coleridge, getting high and watching masterpieces spill out of you, like Kubla Khan. You will be less sensitive to small things destroying your work, like Coleridge's visitor. Truish story.

High notes, low notes who cares? The test of the acceptable programmer is in the works he/she creates. And to judge that requires answering the following:

1. Does the software do what it's supposed to do? 2. Does it do what it does efficiently?

That's it.

Forget wanting to belong to the legions of hallowed programmers who use the latest/best programming languages or frameworks.

No programmer hits a low note ... unless they want to. Those are not programmers but itenerant workers just filling in for the time-being. (Which could last 30 years. :) )

Ciao

There could be kids in the class with 2 years internship experience with the exact language on similar projects and those that have never programmed before.

Comparing professionals would be much more useful.