If writing code were a science, all developers would pretty much be the same.

Just as in art, no two developers have the same thinking or perception or the subjective truth while writing code for the same outcome.

While some struggle to produce the desired outcome, to a few, it comes almost naturally, as if an epiphany hits them at the moment they sit to create programs or solve a problem.

In a blog post, Steve McConnell (cited as an expert in software engineering) writes that the original study that found huge variations in individual programming productivity was conducted in the late 1960s by Sackman, Erikson, and Grant. They found that the ratio of initial coding time between the best and worst programmers was about 20 to 1. They found no relationship between a programmer's amount of experience and code quality or productivity.

While there were flaws in this study, even after accounting for them, the data still shows more than a 10-fold difference between the best programmers and the worst.

At Arkenea, we have more than five years of experience hiring developers, and it's as challenging as it was in the earlier days to tell a great programmer from a good one.

It's not a unique challenge. We've seen many large enterprises and companies across industries struggle with the same issue. Many have created a filtering process by means of various tests, but can you really test an artist?

The straight answer is no.

Writing good code simply isn't the only factor when judging whether the programmer is a great resource.

But there's a way. There are some other indicators (apart from the quality of code writing) that separate great programmers from good ones.

Christopher Burke, in a response on Quora, highlighted that anyone who can write working programs to solve problems is a programmer. A good programmer, on the other hand, is one who collaborates with others to create maintainable, elegant programs suitable for use by the customer, on time and with low defect rates, with little or no interpersonal drama.

But what makes for a great programmer is one who understands algorithms and architectures intuitively, can build self-consistent large systems with little supervision, can invent new algorithms, can refactor live systems without breaking them, can communicate effectively and cogently with nontechnical staff on technical and nontechnical issues, understands how to keep his or her ego in check, and can teach his or her skills to others.

In my experience, though, I would equate his definition of a programmer with that of a good programmer and his definition of a good programmer with that of a great one.

Someone Christopher calls a great programmer, I would say, wouldn't necessarily write code upon reaching this stage of his or her career. The person would be working more strategically with companies and their development teams to give product directions--essentially someone like a CTO.

The willingness to stay with a problem until it's resolved (not to be confused with sitting on a problem), coupled with the ability to creatively solve it, is a highly desired skill or aptitude found only in great programmers.

So the quintessential question, how do you identify a great programmer? This person will be able to quickly get to the root of your problem. He or she may not instantly provide a solution but can chart out a path toward getting to the solution quickly and effectively.