Recently I contributed to a discussion on a PHP mailing list about how to identify great programming skill. A lot of the discussion centered around previous experience, organizational ability and accomplishments. You can tell a lot from these, but I chimed in with a different take. In my experience, the programmers who I think are great have invariably had the traits I described in my post. I’m including a slightly modified version below.
In my experience the key distinctions between a mediocre and a great programmer are very difficult to define, although there have been some great comments previously that get at the distinction. But, I would add that there are definitely some aspects of a great programmer that do not necessarily come with time. That is, there are some aspects of an excellent programmer he or she has from the beginning, or which have been consciously cultivated.
When hiring in the past, these are the three criteria that I have looked for in a programmer,
Curious
I have met programmers with 10+ years who are not as curious, and consequently have not branched out as much, as some classmates I had in college. I knew a guy who wanted to program an OpenGL demo using Lisp, just because there were bindings in the language for it. That kind of curiosity is invaluable and isn’t readily apparent on a resume. In my opinion, a curious programmer will be one who writes programs for purposes that are not related to their job, and are outside of their core discipline. E.g., a web developer who takes a stab at improving MySQL, or graphics programming, or just something other than web development.
The kind of cross-fertilization that occurs when a programmer does that is something that improves them by informing them of how different people in different domains solve both similar and different problems. Sadly, most job-seekers are trained to omit from their resumés any information about side projects, hobby programming or anything else that is not professional experience. I admit that, as the person who is looking over candidate profiles, I tend to scoff at amateur experience on a resumé. I do think a winning strategy, however, is to display your hobby or side accomplishments on a website and include the address on your resumé.
Curiosity in a programmer is important to me because it means that this person views programming as an important skill in their life and one that needs to be honed and refined. If programming is only a skill for finding a job and earning money then, in my opinion, his or her skills tend only to be as good as necessary, but not better.
Precise
A good programmer is also interested in being precise, by which I mean that a great programmer knows that for every challenge there are solutions that are different levels of correct. Although I can’t think of an example off the top of my head, anyone who has had to refactor a code base knows that there is a sense that programmers have for how to identify groups of code and organize them in a way that optimizes the code’s readability, accessibility and maintainability. Don’t take that skill for granted, not everyone has it.
Precision in a programmer also manifests itself in his or her other habits. A precise programmer speaks about technology and programming in precise terms, and they know what those terms are. Mediocre programmers speak loosely about technical concepts and of programming because they haven’t bothered to learn the terminology. When comparing different programming languages, for example, a great programmer would know and use the proper terms for different features. They would know the terms because they are curious and they would use them because using imprecise language is ambiguous and potentially confusing, which is a less-than-correct application of words.
For example, a programmer who knows what closures are is, in my experience, likely to know how to use them correctly and to have had made all the head-scratching mistakes that creates valuable experience. A guy who comes in and doesn’t know what a closure is, referring to that language feature instead as some imprecise description like “assigning functions to variables” (a definition which omits the ability to enclose an environment) is not as likely to be as knowledgeable about them, although they might be. I have to wonder how a great programmer would have become so great without having had their curiosity piqued and reading up enough to learn the correct terminology.
For a good example of this, listen to some technical talks given by programmers you think are respectable. In my experience they don’t use terms loosely or use the wrong words to describe different concepts. That’s attention to detail and it shows that this person cares about doing things correctly.
This is important to me because there are many decisions in programming where the difference between the Right and the Wrong solution exists, but is difficult to articulate. Someone who has cultivated an appreciation for the concept of Rightness in programming is someone who has taken on enough problems in their career to discover that some ways work better than others, and they have cultivated a sense for distinguishing better ways from worse ways.
Dispassionate
In my experience, the best programmers are like scientists, meaning that their interest is to follow the evidence. In programming that means NOT becoming attached to any particular code or pattern, but instead always being ready to rewrite because a better way became apparent. It may not always be feasible to do that, and a great programmer will know when other constraints prevent total improvement, but they will always trend towards choices that move the code closer to an improved version.
One good example comes from the .NET framework design guidelines. The author describes an earlier version of the framework where different graphics functions adhered to different naming conventions. If I recall correctly, in one place a method was called GetAsRGBA() and in another it was called StoreAsRGBAlpha().
The author lamented the fact that the methods did not adhere to a consistent naming convention. He also knew that, because existing applications depended on these methods, changing their names and breaking backwards compatibility was out of the question. Still, he developed a convention and future additions to that API do conform to it. In my experience, mediocre programmers do not recognize or care for this level of analysis or consistency, possibly because they do not have the experience or interest in developing good, usable programming interfaces.
This is important to me because I want to know that my colleagues and I can reach agreement on the idea that the code’s most correct form exists and is achievable. We can discuss what it should look like and what it would take to get there, and we can then make decisions about which measures we can implement to get there and which would be too costly or impractical.
One last word I would say about great programming skills: none of these require someone to be able to perform particular feats of great magnitude. A programmer who has these attributes will, in my opinion, be able to successfully complete many difficult programming challenges. A programmer without these attributes might also be able to complete such challenges, but that doesn’t mean that they are a great programmer, just good at producing certain solutions. A great programmer has the aforementioned attributes which, to me, indicate their capacity to grow as a programmer.
However, if you are looking for a great programmer I suggest you get a few such programmers together and ask them to assemble a set of challenging questions for interviewees. These questions should be a mix of closed-form challenges (i.e. those with one or a few discrete solutions) and open-form challenges that expose their understanding of concepts underlying the challenge. It should include questions that ask for criticisms of different proposed schemata for a particular situation, that ask for the interviewee to generate their own schema for a given purpose, that ask about the suitability of different data structures for a situation, and also some questions which ask the interviewee to assess the strengths and weaknesses of a proposal with an eye toward security.
If you have technical staff, a technical interview is absolutely necessary. Interviewees need to be interviewed by their potential teammates, and they need to be interviewed thoroughly. At a previous position, my department was bound by some politically-motivated decisions of upper management to have a panel interview where representatives of every department were present. This allowed room for about two technical questions, and because the entire panel had to be able to understand the question, the most difficult such question was something along the lines of “What is a right join?”
The result: an incredible waste of time, as the technical abilities of these different candidates had to be evaluated on a very small glimpse. The lesson here is simple: be kind to your technical employees, let them develop a thorough process for screening their potential workmates. The most enjoyable interviews I’ve had were a series of three or four one-on-one sitdowns with different members of the technical staff. It creates a valuable opportunity to know more about a person than whether or not they know a little SQL.
Creator.