Charles Miller blogs about good Java developers vs. excellent Perl hackers--and which one should you prefer to hire on your team. Actually, Charles quickly swaps in Python for Perl, talking about a "merely good" Java developer versus an excellent Python developer.

What's funny about the blog is how Charles jokes about the Java developer having to deal with the Python developer constantly complaining how "whatever feature you’re working on could be implemented better in five lines of Python." I'm actually involved with a project that uses Python as well as Java, and I think it's actually me who complains about Python (I'm a Java guy by background) and not the other way around. Yes, you read that correctly.

Whereas Python being a dynamic scripting language and all is nice, I can't help but feel that it's a compromise between the power and freedom of Ruby and the rigor of Java and the like. Yes, the list comprehensions are ok but what the heck is going on with tacking that "self" everywhere? :)

I digress. Back to business.

So, in his blog, Charles also says something I can't help but quote verbatim:

A great programmer may not crank out features ten times as fast as a good one, but they still may have that much performance benefit overall. For me, what gives great the edge over good is some combination of: attention to detail, which means their features will be more completely implemented with fewer incidental bugs, attention to design, which means they’ll leave the code in a better state than they found it, and inspiration, where they will find solutions to a problem that simply wouldn’t occur to other programmers. All of these have really, really powerful flow-on productivity effects for the whole team.

Let me repeat the part that especially struck a chord with me:

Attention to design, which means they'll leave the code in a better state than they found it, ...

Amen, brother! There are plenty of "good programmers" out there who manage to crank out bug-free software and come up with smart solutions, but I'm always most excited about seeing someone do the dirty work--cleaning up after whomever happened to code that particular function--without giving it a second thought. That's the kind of "good programmer" I'd hire for my team. Whereas it might be a nice-to-have in some contexts, living and breathing refactoring is a requirement for an agile project to deliver working software week in, week out, sustainably.