What Makes a Great Software Developer?

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.

The Importance of Formatting

I've said it before and I'll say it again. The book that most changed my view on software is Robert Martin's Clean Code: A Handbook of Agile Software Craftsmanship. There's an entire chapter of the book devoted to formatting. In it, Martin says the following:

When people look under the hood, we want them to be impressed with the neatness, consistency, and attention to detail they perceive. We want them to be struck by the orderliness. We want their eyebrows to rise as they scroll through the modules. We want them to perceive that professionals have been at work. If instead they see a scrambled mass of code that looks like it was written by a bevy of drunken sailors, then they are likely to conclude that the same inattention to detail pervades every other aspect of the project. You should take care that your code is nicely formatted. You should choose a set of simple rules that govern the format of your code, and then you should consistently apply those rules. If you are working on a team, then the team should agree to a single set of formatting rules and all members should comply. It helps to have an automated tool that can apply those formatting rules for you.

In The Purpose of Formatting section Martin writes:

First of all, let's be clear. Code formatting is important. It is too important to ignore and it is too important to treat religiously. Code formatting is about communication, and communication is the professional developer’s first order of business. Perhaps you thought that “getting it working” was the first order of business for a professional developer. I hope by now, however, that this book has disabused you of that idea. The functionality that you create today has a good chance of changing in the next release, but the readability of your code will have a profound effect on all the changes that will ever be made. The coding style and readability set precedents that continue to affect maintainability and extensibility long after the original code has been changed beyond recognition. Your style and discipline survives, even though your code does not.

Benefits of post-commit code reviews

Many teams debate whether code reviews should occur before a submission or after a submission. I've worked on teams that have used both approaches and am convinced that post-commit code reviews are more beneficial. Post-commit code reviews:

• allow reviewers to easily try out the real code they are reviewing.
• are easier to create.
• promote a culture of many small submissions.
• work better for submissions that require more than one review.
• prove to developers that they are trusted and therefore leads to a happier development community.

Each benefit is explained below.

Reviewers can experiment with code under review

With post-commit code reviews, a reviewer can experiment with the code under review just by checking out the relevant code base from source control. If a reviewer works on the code base frequently, he probably already has a checkout of the code base and just needs to update it. To experiment with code in a pre-commit code review, a reviewer must typically download a patch that is attached to the code review and apply it to his checkout, making sure to apply it to the correct root folder.

Ease of code review creation

Post-commit code reviews are easier to create than pre-commit code reviews. Code review tools, such as Atlassian Crucible, allow you to create a code review simply by selecting a submission. Pre-commit code reviews are harder to create because they typically require the author to create a patch, upload the patch to the code review tool, and ensure that the patch is anchored to the correct folder in source control.

Culture of small submissions

Post-commit code reviews promote a culture of many small submissions - get a little piece of functionality working and then submit it. Repeat this frequently and trust developers to decide when a particular submission requires a review.

Submissions that require more than one review

When you do a pre-commit code review based on a patch, it's not clear how to review the changes made based on review comments (because you'd have to make a patch of a patch to review only the changes). When you do post-commit code reviews, you just make a second submission and, if necessary, call a review for that submission.

Trust in developers

Just like any other group of people, developers like to be trusted and are happier and work more effectively in an environment where they are trusted. Post-commit code reviews promote such trust in developers. Pre-commit code reviews promote the opposite - that developers must be scrutinized. Sure, junior developers may need to be scrutinized but that should not be the default team behavior.

Potential drawback and workarounds

One potential drawback of post-commit code reviews is that an unreviewed submission can break everything. However, modern development tools provide easy workarounds:

• A continuous integration system, such as Bamboo, will quickly tell you that everything is broken.
• A modern revision control system, such as Subversion, allows you to easily revert a single submission. Therefore, in a worst-case scenario when the continuous integration system indicates that the build is broken, you can revert the offending submission and trigger another build.

Scrum team member code of conduct

This post defines a code of conduct that I try to adhere to on a Scrum team.

Team participation

• Fixing my team's broken builds is my highest priority.
• Participating in my team's code reviews is my second highest priority.
• Improving my team's velocity is more important than improving my individual velocity.
• I will not be late for team meetings.
• I will ask for help when I need it.
• I will provide help when asked.
• I will be honest at all times.
• If I don't believe something is possible I will say so without hesitation.

Peer reviews

• I will be professional and tactful when providing review comments.
• I will be open to receiving feedback when others review my work.

Writing code

• I will express myself through code.
• I will add comments to code only if I have failed to express myself through code.
• I will write code that adheres to my team's formatting and style conventions.
• I will not submit production code without thorough in-memory unit tests.
• I will not submit code that causes any tool to emit a warning.

Comments are a failure

The book that most changed my view on comments in code is Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin.  There's an entire chapter of the book devoted to comments.  In it, Martin says the following:

Nothing can be quite so helpful as a well-placed comment.  Nothing can clutter up a module more than frivolous dogmatic comments.  Nothing can be quite so damaging as an old crufty comment that propagates lies and misinformation.

Comments are not like Schindler's List.  They are not "pure good."  Indeed, comments are, at best, a necessary evil.  If our programming languages were expressive enough, or if we had the talent to subtly wield those languages to express our intent, we would not need comments very much -- perhaps not at all.

The proper use of comments is to compensate for our failure to express ourself in code.  Note that I used the word failure.  I meant it.  Comments are always failures.  We must have them because we cannot always figure out how to express ourselves without them, but their use is not a cause for celebration.

So when you find yourself in a position where you need to write a comment, think it through and see whether there isn't some way to turn the tables and express yourself in code.  Every time you express yourself in code, you should pat yourself on the back.  Every time you write a comment, you should grimace and feel the failure of your ability of expression.