One more characteristic: fearlessness. You have to be able to not only start, but commit to completing, a project even tho' you've no idea how to do it. You have to have that faith that you <i>are</i> smart enough to learn on the hoof, and you have to have the courage when you realize that you've written a ton of code already, when you realize you're heading down a dead end, to just delete it all.
It seems as though the programming field is in a bit of a bind because, odd though it might seem, it has been difficult to be <i>empirical</i> in our approach to our field. The programming domain is very complex, so there are considerable difficulties in implementing empirical approaches. Proprietary development often entails a degree of secrecy, so a lot of data is not available to be shared. There is even debate along the lines of what is valuable to measure, or what can even be measured. One is reminded of many social sciences and psychology, or even medicine prior to the scientific revolution.<p>What is holding programming back from the degree of empiricism found in a field like mechanical engineering? Is it that it's hard to fund or even structure meaningful experiments? Should someone be developing non-ferromagnetic monitor/keyboard sets so that we can study programmers of different levels of demonstrated ability with their heads stuck inside MRI machines? (Such research has been done with piano virtuosos playing on electronic keyboards and rappers.)<p><a href="http://www.ted.com/talks/charles_limb_your_brain_on_improv.html" rel="nofollow">http://www.ted.com/talks/charles_limb_your_brain_on_improv.h...</a><p>Another thing I'd note, is that a lot of debate about programming is word salad full of reasons why you can't say X or Y. There seems to be a lot of the <i>Epistemic Viciousness</i> that exists in martial arts schools.<p><a href="http://lesswrong.com/lw/2i/epistemic_viciousness/" rel="nofollow">http://lesswrong.com/lw/2i/epistemic_viciousness/</a>
Assuming a "great programmer" is one that writes good quality code, then I don't think tools are necessarily about making you a great programmer, I think they're more about making you a faster and happier programmer. I would probably write the exact same code in nodepad as I would in vim, but I could probably write it in significantly less time in vim, and I would be much happier and less frustrated along the way.
<i>The best programmers that I’ve known put people first. They’ve realized that the software that they’re writing is for people, even if it’s just the back end of a complicated system or a protocol that no one but other developers will ever use. They write documentation because it’s important. They help people use their code. They’re willing to work extra and deal with a bit more complexity to give the people using their software the right solution.</i><p>I always get a bit irritated when people make the "people first" argument. It's not that I disagree with putting people first. It's just that "putting people first" always seems to mean "being a good cog in the machine".<p>There's more to putting people first than writing documentation and explaining your code to other people. Those are important, but they mean putting the task first, not the people. To put people first, you have to do things like: listen to others, empathize with them, use tact, compromise, and occasionally do something impractical for no other reason than to help work suck a bit less.
While I agree with the main points of the post, I'd like to defend learning proper tools.<p>Even if a good text editor like vi won't make you a great programmer, it most definately will make you a better programmer!<p>First, you'll be more effective and thus achieve more. You can squeeze more refactoring and trying out different things when you are more efficient. This could lead you becoming great at some point.<p>Second, it's about your mindset. Programming is about automatizing and a great programmer should aim for the highest achievable level of automation. Why should your tooling be left out of the equation? With proper tools you can automate more.<p>If a developer has more then 1 year active developing to do, learning e.g. a good editor will pay off.
There's a great Quora page about this topic: <a href="http://www.quora.com/What-distinguishes-a-good-software-engineer-from-a-great-one" rel="nofollow">http://www.quora.com/What-distinguishes-a-good-software-engi...</a><p>The top answers on Quora offer a lot of food for though.
<i>My brother took a Python class his Senior year of high school</i><p>The best I got out of high school back in the early 90's was an "Intro to Computer Programming" using Turing[1], of all things on a Macintosh Classic. Of course we didn't have the internet either back then, but I digress.<p>You guys are so lucky to be growing up post internet. :)<p>[1]: <a href="http://en.wikipedia.org/wiki/Turing_(programming_language)" rel="nofollow">http://en.wikipedia.org/wiki/Turing_(programming_language)</a>
While tools may not make a great programmer, tools do make a great programmer more effective. In fact, I'd say passion (I'd prefer a different word, but need something stronger than strong preference) for tools is a trait of great programmers. And sure, the desire to optimize one's toolset comes from deeper motivations, but I think a better programmer is, among many other things, one who never passes up on chances to improve productivity through better tools.<p>I kind of like Rand's take on the subject:<p><i>As an engineer, there is a short list of tools that you must be rabid about. Rabid. Foaming at the mouth crazy.</i>
[<a href="http://www.randsinrepose.com/archives/2009/11/02/the_foamy_rules_for_rabid_tools.html" rel="nofollow">http://www.randsinrepose.com/archives/2009/11/02/the_foamy_r...</a>]<p>And sure, there isn't going to be a single set of tools for every programmer and every workflow, but good tools and a thorough understanding of them are something I would expect from a great programmer. I agree with most of the author's points, and don't want to at all suggest that becoming a vim wizard will on its own make you a great developer, I guess I'd hate to discourage anyone from seeking "text editor zen".
I'll throw in my favorite under-rated characteristic of good programmers: the ability to throw away code you've worked hard on. Sometimes code that is well written, tested, and documented just isn't needed anymore or doesn't fit with new changes to an architecture. The pros throw it out without a second thought. Many programmers find it hard to let go and it causes serious bloat to a code base.
Communication - if you can't talk* about solutions and translate them into code that others can work with, learn from, maintain, etc. then whatever else you have doesn't matter. Your impact will be limited to that you can directly touch. You will never be great.<p>* "talk" most of the time means "listen and understand".
I would like to add something that everyone seems to have forgotten. A great programmer has a significant life outside the field.<p>Additionally, and I don't know if it's just a coincidence, but the best programmers I know are fluent at least in one musical instrument.
" It's not really enough to solve the problem. We have to have the pleasure " - DHH, 2011 Railsconf, Keynote<p>Should this trait has anything to do with it?
Somebody who delivers sh*t that works, on time and under budget. The code is robust and can be maintained, with extra points and gratitude if it's well-documented. Oh, and said code both scratches an itch and solves an important customer problem.<p>As Joel said: Smart, and Gets Things Done.