- Critical thinking skills.
- An understanding of software design: Architecture and design patterns.
- A solid working knowledge of the programming language being used.
- Communication and collaboration skills.
- Continual learning and exploring.
- Domain knowledge of the problem being solved.
Communication is all about conveying your message clearly. And since software these days is increasingly more about teamwork, communication skills are increasing in importance. Have you ever seen energy wasted because of a miscommunication? Basic communication comes in a few forms:
Both e-mails and instant messaging are used quite frequently these days. Too often, people don’t pay enough attention to making their messages clear and concise. My experience is that writing clearly takes time and effort, and many times written messages can get muddled. The best tend to express themselves clearly and succinctly. And the most productive also choose wisely between the quicker, verbal conversation versus the longer, written form of communication.
Clear and succinct apply equally here as well. Ever had to listen to “rambling man” at a meeting? How about someone who speaks too softly, lacking in either confidence or conviction? How about those team meetings where that special someone always wants to take the conversation completely off-track? It takes time and practice like anything else, but being able to deliver well-considered, articulate input or questions is a huge productivity boost to everyone involved!
This may not come up as much for programmers, but in my company we have had occasion for senior-level programmers to participate in sales presentations as well as product demonstrations at our annual user conference. Interestingly enough, some of our best programmers happen to have good presentation skills, helping to produce sales in the process. I would never make presentation skills a requirement for any programmer, but it is included in my list of what great programmers have in their repertoire.
Collaboration skills directly speak directly about the participation and interaction with peers on project teams. This skill is growing increasingly important, and I've observed that high-caliber programmers are often high-caliber teammates. There are certainly exceptions to this rule, but the need for increased teamwork is reducing the tolerance for difficult personalities, regardless of the skill brought to the table.
Part of being on a team means that you must exercise some flexibility about what you are working on at times, demonstrating a willingness to help the team reach its common goal. I've observed that many high-caliber programmers are ready and willing to share responsibility with the team. As a manager, I've been challenged with another scenario that is only natural. High-caliber programmers want to work with other high-caliber teammates!
Continual Learning and Exploring
This comes in many forms, but the high-caliber programmers that I’ve seen keep up with the industry. They read books, trade journals, have their favorite web sites and read blogs (and blog themselves), and ask to go to specific conferences and training. They’re always looking to learn and do more.
Another trait of high-caliber programmers is the fact that they don’t limit their programming to just what they’re working on as part of their formal assignments. They work on mini-projects that expose them to new things.
Sometimes these are projects are of use to the company and done “on the company’s dime,” and other times these are simply self-exploratory projects aimed at learning and growing, done off-hours on their own time. And I’m not against allowing use of down-time between projects for this type of activity.
I’ve always encouraged any junior developer who wants to improve their game to pick a project and do this same thing. In fact, mini-projects are a great way for a junior developer to walk a project through soup-to-nuts, starting with requirements, creating a design and ultimately developing a finished product.
Domain Knowledge of the Problem Being Solved
I work for a company that writes insurance software, and I find that the more our programmers understand insurance, the faster we can develop software. Any discussions about requirements are made faster and easier because business analysts can spend less time talking about the business basics and move straight to the needs/requirements.
There was a concern expressed when I included domain knowledge in my list of what makes a programmer good in a LinkedIn question. The person responding felt that a developer with detailed domain knowledge adds risk because if there are ambiguous or incomplete requirements, that developer will make assumptions, whereas one who does not know the domain will ask the functional analyst.
I certainly agree that this is a risk. My counterpoint is that someone who deems themselves to be a professional should – when those incomplete requirements or ambiguities exist – get back to the business/functional analyst and determine what the real requirements are. Assuming is something that professionals should never do.
In general, it is my experience those with domain knowledge also have more efficient and effective dialogs with the functional/business analysts, creating greater overall productivity.
Just for the record, when I hire, my preference is to always hire good programmers first, and then look for industry-related experience. I value development skill first and foremost, and I always assume that any business-specific background can come through training and on-the-job experience. I don’t pass up a solid programmer because he or she lacks industry-related experience.
If you have all of the above, you fit my ideal of a great programmer! The final contributing factor in making someone a high-caliber, high-performing programmer is experience. While you can argue that technology is constantly changing and evolving and that yesterday’s skills aren’t important, I maintain my position here. And bear in mind that this is the lowest-ranking criteria that I have.
The way I see it, a seasoned programmer has been through a lot. They’ve lived through good projects and bad. They’ve worked with other skilled programmers and those who shouldn’t even be in the profession. There is nothing wrong with having someone around who has the “I’ve been there, done that before” wealth of experience that could mean the difference between success and failure of a project.
As I’ve mentioned, I’m a manager these days. Can I “manage” someone to greatness? Not really. I can understand it when I see it, and I can coach you about what you need to do to become great. I can help make opportunities available for you as a programmer to demonstrate your worth.
At the end of the day, the individual has a role here too. I’ll close with a quote from Steve McConnell, as he said in his book Code Complete 2.0, “If you want to be great, you’re responsible for making yourself great. It’s a matter of your personal character.”