[Shengster]

It seems the general consensus is that a great programmer can write better quality code in less time than others.

This requires a high level of aptitude and experience (which comes with practice).

However, I feel the ability to write quality code quickly is just one facet of a great programmer's skillset.

Often overlooked is the ability to communicate and collaborate with others effectively--which is just as important.

With complex projects, I oftentimes find that the solution to my problems has already been solved. Sometimes the best code is no code at all.

[zenocon]

Agree -- also one of the most under-rated skills is someone who keeps up to date on all the latest frameworks / libraries, etc. More often than not, you're building something that solves a unique problem and you do that by stitching together pieces of other people's engineering.

I would argue that this presents several sub-skills:

Being able to do this quickly b/c you don't have to spend the time learning

Being able to do this effectively -- by not painting yourself into a corner b/c you well versed in best practices and anti-patterns with using said 3rd party technology

Being able to do this smartly -- because you are well-versed in a lot of the different options, you can effectively way their pros/cons, and make smart decisions on which 3rd party stuff to use, and when to build vs. buy

I think these skills are more effective (towards your end goal) than simply being able to quickly code some brilliant labyrinth of an algorithm in less SLOC than a 1 or 2-xer. I feel like the emphasis is always put on the latter, and these skills are overlooked.

Combine these with effective communication, and then you are talking about someone who can get things done.

[enjo]

I think you came close to the biggest differentiator: adaptability. Great programmers can dive into a new technology and use their past experience to quickly gain competency in it. If I hand node.js to a great programmer, I expect that he/she will be able to start being productive with it in just a day or two. Lesser programmers struggle to apply their past experience to that new paradigm. It takes months for them to truly get comfortable.

That type of agility is hugely helpful in an organization.

[cema]

Almost as important. I agree wholeheartedly: without communication, there is no team, just a bunch of folks sitting next to each other.

(Still, working is more important than talking about it.)

[beersigns]

Communication/Collaboration & ability to write elegant code are pretty symbiotic but I'd generally say it's harder to find someone who can elegantly design/code a system than it is to find people to talk about it(Reqs, specs etc).

[mmcconnell1618]

Smaller teams means more of the communication takes place in the 10x programmer's head rather than in multiple meetings between 1x programmers. A team of 3 10X programmers should be more efficient than 30 1x programmers simply because communication will be more efficient.

[beersigns]

Hah, my own anecdotal evidence has been in favor of smaller teams for the communications reason you cite. Probably a bit of a bad analogy but it made me think of 3 Unix processes vs 30. Way harder to manage IPC between 30 processes as opposed to 3.

[dalke]

Here's what McConnell writes on the topic, in chapter 30 of "Making Software." (The rest of this comment comes from McConnell.)

Some people have objected to the "10x" label, making an argument like "We had a super programmer on our team once. He was so obnoxious he alienated the whole team, and overall productivity was actually better without him.

In general, any practical definition of a real 10x programmer has to include the effect the programmer has on the rest of the team. I have known super programmers who were obnoxious. More often, a supposed super programmer with an obnoxious personality was really an average programmer, or worse than average, using an obnoxious personality to hide a lack of performance. The true super programmers I've worked with have generally also been cooperative team players, although of course there are always exceptions."