What Makes a Great Software Developer?
Friday, July 27, 2012 at 9:29PM Let’s face it. Some software developers are better than others. According to Robert Glass in his great book Facts and Fallacies of Software Engineering, the best developers are up to 28 times more effective than the worst developers. My experience has been that the effectiveness range is even wider than that. Some developers are a net negative for their employer. Their work is so shoddy and to get anything done they have to spend so much time with their colleagues that they are an overall drain.
On the other hand are the great developers. They are a joy to work with and they make everyone around them better. I’ve been thinking lately about the traits shared by the developers I most like to work with. I always consider Joel Spolsky’s advice from Smart and Gets Things Done: Joel Spolsky’s Concise Guide to Finding the Best Technical Talent when interviewing candidates. In particular, I consider the two most important questions:
- Is the candidate smart?
- Does the candidate get things done?
In this article I want to go beyond those two high-level questions. What behaviours are shared by the best developers? In no particular order, here’s what I’ve come up with so far:
Prefers Collaboration to Individualism
Poor developers love working alone. They prefer to be off in a corner by themselves for weeks or months at a time while they slave away and create incomprehensible code… that’s how they prove how smart they are! By working alone, they become indispensable. Only they can decipher the hieroglyphics they’ve created. The best developers are the exact opposite; they love working on a team. They get a thrill when their idea is added to by a colleague to come up with a better idea. They revel in creating a code base that anyone can read, where nobody is indispensable.
Attention to Detail
The best developers have tremendous attention to detail. They care about naming and formatting. They’re like a perfect camper in a national park; things are always cleaner after they leave than when they came. They don’t leave messes like commented-out code, unused private methods, or unnecessary classes. When they see a small error, such as a typo in a code comment, it bothers them enough that they fix it. Poor developers don’t care about such mundane things; their attitude is much more blasé.
Plans Ahead; Doesn’t Rush
The best developers have the right mix of slowness and speed. They don’t rush ahead and hammer away at the keyboard with the first idea that pops into their head, nor do they spend weeks carefully mulling over every possible alternative. They fit nicely down the middle of the rushing spectrum. Good developers seem to have stretches of thinking time followed by rapid bursts of code. Lesser developers seem to spend most of their time coding, a lot of which eventually gets rewritten by the better developers.
When coding, the best developers spend a few moments considering every detail. What should this class be called? What package should it go in? Has this method been written before in a reusable library? What should the parameters be?
Embraces Change
The best developers are not only open to change, they embrace it! Our industry changes so rapidly that there is always a better way and a person who knows better. A best practice from two years ago might be a hindrance today. Poor developers resist change; they cling to their old ways and refuse to accept that a better alternative exists. Good developers are keen when shown a better way. They spread the gospel of this new technique to their colleagues. They shout it from the rooftops… “I’ve been doing it wrong!”
Willing to Ask for Help
The best developers aren’t afraid to ask for help and know when it’s appropriate to do so. Rather than struggle for days to cobble something together, great developers are willing to admit that they need help. It’s all part of being a humble programmer, as Edward Dijkstra called it. We must be willing to put our egos aside and get the job done!
Clear Communicator
The best developers communicate clearly, both in their spoken words and their software. When debugging a problem, they can provide a clear explanation of what they’ve tried so far and what they’ll try next. They can provide a crisp status on their project and their daily work.
Able to Admit Mistakes
Everyone occasionally makes mistakes. It’s how you react to those mistakes that separates great developers from the rest. Great developers readily admit their errors; they’re human and they can even laugh about it. Poor developers think they’re infallible. They refuse to admit they were wrong, even when all evidence points in that direction.
Reader Comments (1)
Hello Kyle!
I just found your page and I just wanted to say that your blog is really well written and it looks like a great resource. I've bookmarked it :)