[ericb]

I know one programmer who I would call great. Here's what I've observed from him so far:

1-A serious amount of fucks are given both via attention to detail, polish, and no corners are cut. I have been lazy comparatively and often accepted "good enough." I'm working on changing this so that my priority is what is awesome for the user, not easiest for me to implement.

2-At the micro level, before setting out with any new technology, he tests its properties thoroughly. For example, benchmarking each part of the setup on its most intensive tasks before building with it. No "assuming it will work" based on breathless blog posts. Using his intuitive sense of what is expensive, he also optimizes expensive operations in loops by hand (like mysql complex queries).

3-A well thought out, and well practiced tool-chain for development. Ex: Using vim and knows it well, pays for tools to make life easier, has easy backups with time machine to easily go back, etc.

4-Diverse range of skill, and eagerness to dive into something new at any point.

5-An ability to rapidly debug problems. I haven't pieced together how this skill is built, except it involves the usual logic combined with a better memory than mine (so remembering what to rule out) and a pattern recognition that comes from remembering similar problems.

[nostrademons]

Point 2 is something I've heard Jeff Dean strongly suggest. Write microbenchmarks for all the basic operations of the "black boxes" you'll be using to build the system. That way, you can do quick back-of-the-envelope calculations to estimate the performance of the system before actually building it. You can explore the problem space much more quickly when you can simulate the important characteristics in your head instead of having to actually type them out into an editor.

Point 5 is something my former manager once told me. He'd done RoboGames or something like that as a grad student, and he found that invariably, the teams that won were the ones who had built the best debugging infrastructure into their robot, so that when it didn't behave as expected, they knew exactly what was wrong.

This is as much a property of the program as of the programmer. The best programs usually have debug information built into the structure of the program itself, along with an easy UI for viewing that debug info so you don't have to stare at log lines all day. Once a couple programmers start doing this and everyone else realizes how much time it saves, it becomes part of the culture of the organization, and everybody starts designing programs with an eye toward "Will I be able to figure out what's wrong if this doesn't work?"

[delian66]

Please, would you give an example of an open source program with such infrastructure built in ? I'm eager to study such programs to pick up insights.

[nostrademons]

The closest open-source example I can think of is --verbose mode on many UNIX utilities, though that wasn't really what I had in mind. Developer Tools in Chrome is another example of the principle - think of how much easier it is to debug Chrome than IE6 - but again, not quite all the way. Imagine using Developer Tools to debug all of Chrome, eg. Webkit rendering (overlaid on the rendered page itself), resource parsing & scheduling, JS JIT compilation, etc, and not just the pages that execute within it. (Maybe this is possible, I'm not familiar enough with the Chrome project to know all the debug flags available.)

[swah]

That's a great insight/tip - I wish there was a book with hundreds of those...

[raphaelb]

I certainly don't claim I'm a great programmer, but I can attribute a lot of my career success to focus on and learn to improve #5. I got the itch to improve it because the greatest programmer I know is a true master of rapidly debugging problems, and great at un-sticking projects when no one else can/will.

I was able to improve my own skill in the matter with the "Learn to Debug" section in the "How to be a Programmer Book": http://samizdat.mines.edu/howto/HowToBeAProgrammer.html

[ifewalter]

Impressive.

On point 5, thing is as a programmer (any career actually) with years of code experience, you just know the possible cause for any bug, and what function/class is at fault.

[saraid216]

To elaborate, debugging is basically "applied memory recall". When you see a symptom, what happens is that you start guessing how it could have manifested. Sheer experience basically gives you better guesses.

I've been able to debug more effectively than my coding skill level would imply by dint of my better recall ability.

[grlthgn]

True but you can't just apply 1 and 2 to every problem and expect to meet deadlines. Part of the skill is to know instinctively how much polishing is enough.