zz from http://developers.slashdot.org/article.pl?sid=08/01/11/1746250
It’s not as easy as it sounds. CV experience is only of limited use here, bec
ause great programmers don’t always have the “official” experience to demon
strate that they’re great. In fact, a lot of that CV experience can be mislea
ding. Yet there are a number of subtle cues that you can get, even from the CV
, to figure out whether someone’s a great programmer.
I consider myself to be a pretty good programmer. At the same time, I’ve spen
t a fair amount of time on the business side of the fence, filtering technical
CVs for projects, interviewing people, etc. Thanks to this, I think I have a
bit of experience in recognising good programmers, and I want to share it in t
his article, in the hope that it may help other “business guys” to recognise
good programmers. And, who knows, perhaps some programmers who have the poten
tial to be good but haven’t really exploited this can also read this and real
ise what they need to do to become good (although, as I’ll argue, that’s def
initely not accessible to all programmers!).
In his article The 18 mistakes that kill startups, Paul Graham makes the follo
wing point:
“… what killed most of the startups in the e-commerce business back in the 9
0s, it was bad programmers. A lot of those companies were started by business
guys who thought the way startups worked was that you had some clever idea and
then hired programmers to implement it. That’s actually much harder than it
sounds—almost impossibly hard in fact—because business guys can’t tell whic
h are the good programmers. They don’t even get a shot at the best ones, beca
use no one really good wants a job implementing the vision of a business guy.
In practice what happens is that the business guys choose people they think ar
e good programmers (it says here on his resume that he’s a Microsoft Certifie
d Developer) but who aren’t. Then they’re mystified to find that their start
up lumbers along like a World War II bomber while their competitors scream pas
t like jet fighters. This kind of startup is in the same position as a big com
pany, but without the advantages.
So how do you pick good programmers if you’re not a programmer? I don’t thin
k there’s an answer. I was about to say you’d have to find a good programmer
to help you hire people. But if you can’t recognize good programmers, how wo
uld you even do that?”
I disagree with Mr Graham on this one. I think there are a number of very stro
ng indicators of a “good programmer” (and, conversely, strong indicators of
a “not-so-good programmer”) that even a business guy can recognise. I’ll su
mmarise some key indicators and counter-indicators in a list at the end of the
article.
#1 : Passion
In my corporate experience, I met a kind of technical guy I’d never met befor
e: the career programmer. This is a person who’s doing IT because they think
it’s a good career. They don’t do any programming in their spare time. They’
re shocked when they find out I have a LAN and 3 computers at home. They just
do it at work. They don’t learn new stuff unless sent on a training program (
or motivated by the need to get a job that requires that technology). They do
“programming” as a day job. They don’t really want to talk about it outside
of work. When they do, they talk with a distinctive lack of enthusiasm. Basic
ally, they lack passion.
I believe that good developers are always passionate about programming. Good d
evelopers would do some programming even if they weren’t being paid for it. G
ood programmers will have a tendency to talk your ear off about some technical
detail of what they’re working on (but while clearly believing, sincerely, t
hat what they’re talking about is really worth talking about). Some people mi
ght see that as maladapted social skills (which it is), but if you want to rec
ognise a good developer, this passion for what they’re doing at the expense o
f social smoothness is a very strong indicator. Can you get this guy to excite
dly chat up a technology that he’s using, for a whole half hour, without losi
ng steam? Then you might be onto a winner.
#2 : Self-teaching and love of learning
Programming is the ultimate moving target. Not a year goes by without some new
technology robbing an old, established standard blind and changing half the d
evelopment universe. This is not to say that all good programmers pick up thes
e changes and ride the bleeding edge. However, there’s a class of programmers
that will never, ever pick up a new technology unless forced to, because they
don’t like learning new stuff. These programmers will typically have learnt
programming at university, and expect to get by on whatever skills they picked
up there, plus whatever courses their company is willing to send them on.
If you’re thinking of hiring someone as a programmer, and he ever utters the
words “I can work with that, just send me on a training course for a week and
I’ll be good at it”, don’t hire that guy. A good programmer doesn’t need
a training course to learn a new technology. In fact, the great programmer wil
l be the one talking your ear off about a new technology that you haven’t eve
n heard of, explaining to you why you must use it in your business, even if no
ne of your staff knows how to use it. Even if it’s a technology he doesn’t k
now how to use yet.
#3 : Intelligence
Some business people assume that lack of social tact and lack of intelligence
are the same. Actually, intelligence has several facets, and emotional/social
intelligence is only one of them. Good programmers aren’t dumb. Ever. In fact
, good programmers are usually amongst the smartest people you know. Many of t
hem will actually have pretty good social skills too. The cliché of the progr
ammer who’s incapable of having a conversation is just that - a cliché. I’v
e been to a few meetings of the London Ruby User Group and I can say that with
only a very few exceptions, most people there are smart, talkative, sociable,
have varied interests, etc. You wouldn’t look at them chattering away in the
pub and think “what a bunch of geeks!” - at least until you approach a grou
p and realise they’re talking about the best way to design a RESTful applicat
ion with a heavy UI frontend.
This doesn’t mean that they’ll all feel comfortable in every social context.
But it does mean that if the context is comfortable and non-threatening enoug
h, you’ll be able to have as great a conversation with them as you would with
the most “socially enabled” people (perhaps better, since most good program
mers I know like their conversation to revolve around actually useful topics,
rather than just inane banter).
Don’t ever hire a dumb person thinking they’re a good developer. They’re no
t. If you can’t have a great conversation with them in a relaxed social conte
xt, they’re very likely not a good programmer. On the other hand, anyone who’
s clearly very smart at the very least has a strong potential to be a good or
great programmer.
#4 : Hidden experience
This is correlated with the “Passion” point, but it is such a strong indicat
or that I’d like to emphasise it with its own point.
I started programming when I was about 9, on a Commodore 64. I then migrated o
nto the PC, did some Pascal. When I was 14 I wrote a raycasting engine in C an
d Assembler, spent a large amount of time playing with cool graphic effects th
at you could get your computer to do by messing directly with the video card.
This was what I call my “coccoon stage”. When I entered that stage, I was a
mediocre programmer, and lacked the confidence to do anything really complicat
ed. When I finished it, I had gained that confidence. I knew that I could code
pretty much anything so long as I put my mind to it.
Has that ever appeared on my CV? Nope.
I strongly believe that most good programmers will have a hidden iceberg or tw
o like this that doesn’t appear on their CV or profile. Something they think
isn’t really relevant, because it’s not “proper experience”, but which act
ually represents an awesome accomplishment. A good question to ask a potential
“good programmer” in an interview would be “can you tell me about a person
al project - even or especially one that’s completely irrelevant - that you d
id in your spare time, and that’s not on your CV?” If they can’t (unless th
eir CV is 20 pages long), they’re probably not a good programmer. Even a prog
rammer with an exhaustive CV will have some significant projects that are miss
ing from there.
#5 : Variety of technologies
This one’s pretty simple. Because of the love of learning and toying with new
technologies that comes with the package of being a “good programmer”, it’
s inevitable that any “good programmer” over the age of 22 will be fluent in
a dozen different technologies. They can’t help it. Learning a new technolog
y is one of the most fun things a programmer with any passion can do. So they’
ll do it all the time, and accumulate a portfolio of things they’ve “played
around with”. They may not be experts at all of them, but all decent programm
ers will be fluent in a large inventory of unrelated technologies.
That “unrelated” bit is the subtle twist. Every half-decent java programmer
will be able to list a set of technologies like “Java, J2EE, Ant, XML, SQL, H
ibernate, Spring, Struts, EJB, Shell scripting”, etc.. But those are all part
of the same technology stack, all directly related to each other. This is pos
sibly hard to recognise for non-programmers, but it is possible to tell whethe
r their technology stack is varied by talking to them about it, and asking the
m how the different technologies they know relate to each other. Over-speciali
sation in a single technology stack is an indicator of a not-so-good programme
r.
Finally, if some of those technologies are at the bleeding edge, that’s a goo
d positive indicator. For instance, today (November 2007), knowledge of Merb,
Flex, RSpec, HAML, UJS, and many others… Please note that these are fairly cl
osely related technologies, so in a couple of years, someone who knows all the
se will be equivalent to someone familiar with the Java stack listed in the pr
evious paragraph.
Update: As a clarification to this point, there’s in fact two indicators here
: variety and bleeding edge. Those are separate indicators. A good variety of
technologies across a period of time is a positive indicator, whether or not t
he technologies are bleeding edge. And bleeding edge technologies are a positi
ve indicator, whether or not there’s a variety of them.
#6 : Formal qualifications
This is more a of non-indicator than a counter-indicator. The key point to out
line here is that formal qualifications don’t mean squat when you’re trying
to recognise a good programmer. Many good programmers will have a degree in Co
mputer Science. Many won’t. Certifications, like MCSE or SCJP or the like, do
n’t mean anything either. These are designed to be accessible and desirable t
o all. The only thing they indicate is a certain level of knowledge of a techn
ology. They’re safeguards that allow technology recruitment people in large c
orporations to know “ok, this guy knows java, he’s got a certification to pr
ove it” without having to interview them.
If you’re hiring for a small business, or you need really smart developers fo
r a crack team that will implement agile development in your enterprise, you s
hould disregard most formal qualifications as noise. They really don’t tell y
ou very much about whether the programmer is good. Similarly, disregard age. S
ome programmers are awesome at 18. Others are awesome at 40. You can’t base y
our decisions about programmer quality on age (though you might decide to hire
people around a certain age to have a better fit in the company; please do no
te that age discrimination is illegal in most countries!).
As a final note to this, in my experience most average or poor programmers sta
rt programming at university, for their Computer Science course. Most good pro
grammers started programming long before, and the degree was just a natural co
ntinuation of their hobby. If your potential programmer didn’t do any program
ming before university, and all his experience starts when she got her first j
ob, she’s probably not a good programmer.
Disclaimer
None of the indicators above or below are sure-fire indicators. You will find
great programmers who break some of those moulds. However, my view is, you’ll
rarely find a great programmer that breaks all of them. Similarly, you may fi
nd poor programmers that meet (or appear to meet) some of these criteria. But
I do strongly believe that the more of these criteria a programmer meets, the
more likely they are to be one of those elusive “good programmers” that, as
a business guy, you need to partner with.
The criteria in bullets
So, in summary, here are some indicators and counter-indicators that should he
lp you recognise a good programmer.
Positive indicators:
* Passionate about technology
* Programs as a hobby
* Will talk your ear off on a technical subject if encouraged
* Significant (and often numerous) personal side-projects over the years
* Learns new technologies on his/her own
* Opinionated about which technologies are better for various usages
* Very uncomfortable about the idea of working with a technology he doesn’
t believe to be “right”
* Clearly smart, can have great conversations on a variety of topics
* Started programming long before university/work
* Has some hidden “icebergs”, large personal projects under the CV radar
* Knowledge of a large variety of unrelated technologies (may not be on CV
)
Negative indicators:
* Programming is a day job
* Don’t really want to “talk shop”, even when encouraged to
* Learns new technologies in company-sponsored courses
* Happy to work with whatever technology you’ve picked, “all technologie
s are good”
* Doesn’t seem too smart
* Started programming at university
* All programming experience is on the CV
* Focused mainly on one or two technology stacks (e.g. everything to do wi
th developing a java application), with no experience outside of it
I hope these help. Let me know below if you have any comments, or anything to
add to them!