How to recognise a good programmer.
mok
It’s not as easy as it sounds. CV experience is only of limited use here,
because great programmers don’t always have the “official” experience to
demonstrate that they’re great. In fact, a lot of that CV experience can
be misleading. 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
spent 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 this article, in the hope that it may help other
“business guys” to recognise good programmers. And, who knows, perhaps
some programmers who have the potential to be good but haven’t really
exploited this can also read this and realise what they need to do to
become good (although, as I’ll argue, that’s definitely not accessible to
all programmers!).
In his article The 18 mistakes that kill startups, Paul Graham makes the
following point:
“… what killed most of the startups in the e-commerce business back in
the 90s, 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 which are the good programmers. They don’t even
get a shot at the best ones, because 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 are good programmers (it says here on his resume that he’s a
Microsoft Certified Developer) but who aren’t. Then they’re mystified to
find that their startup lumbers along like a World War II bomber while
their competitors scream past like jet fighters. This kind of startup is
in the same position as a big company, but without the advantages.
So how do you pick good programmers if you’re not a programmer? I don’t
think 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 would you even do that?”
I disagree with Mr Graham on this one. I think there are a number of very
strong indicators of a “good programmer” (and, conversely, strong
indicators of a “not-so-good programmer”) that even a business guy can
recognise. I’ll summarise 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
before: 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. Basically, they lack passion.
I believe that good developers are always passionate about programming.
Good developers would do some programming even if they weren’t being paid
for it. Good 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, that what they’re talking about is really worth
talking about). Some people might see that as maladapted social skills
(which it is), but if you want to recognise a good developer, this
passion for what they’re doing at the expense of social smoothness is a
very strong indicator. Can you get this guy to excitedly chat up a
technology that he’s using, for a whole half hour, without losing 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 development universe. This is not to say that all good
programmers pick up these 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 will be the one talking your ear off about a new
technology that you haven’t even heard of, explaining to you why you must
use it in your business, even if none of your staff knows how to use it.
Even if it’s a technology he doesn’t know 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 them will actually have pretty good social
skills too. The cliché of the programmer who’s incapable of having a
conversation is just that - a cliché. I’ve 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 group and
realise they’re talking about the best way to design a RESTful
application 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 enough, 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 programmers 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
not. If you can’t have a great conversation with them in a relaxed social
context, 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
indicator 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 onto the PC, did some Pascal. When I was 14 I wrote a raycasting
engine in C and Assembler, spent a large amount of time playing with cool
graphic effects that 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 complicated. 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 two 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 actually represents an awesome accomplishment. A good question
to ask a potential “good programmer” in an interview would be “can you
tell me about a personal project - even or especially one that’s
completely irrelevant - that you did in your spare time, and that’s not
on your CV?” If they can’t (unless their CV is 20 pages long), they’re
probably not a good programmer. Even a programmer with an exhaustive CV
will have some significant projects that are missing 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 technology 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 programmers 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, Hibernate, Spring, Struts, EJB, Shell scripting”, etc..
But those are all part of the same technology stack, all directly related
to each other. This is possibly hard to recognise for non-programmers,
but it is possible to tell whether their technology stack is varied by
talking to them about it, and asking them how the different technologies
they know relate to each other. Over-specialisation in a single
technology stack is an indicator of a not-so-good programmer.
Finally, if some of those technologies are at the bleeding edge, that’s a
good positive indicator. For instance, today (November 2007), knowledge
of Merb, Flex, RSpec, HAML, UJS, and many others… Please note that these
are fairly closely related technologies, so in a couple of years, someone
who knows all these will be equivalent to someone familiar with the Java
stack listed in the previous 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 the technologies are bleeding edge. And bleeding edge
technologies are a positive 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 outline 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 Computer Science. Many won’t. Certifications, like MCSE
or SCJP or the like, don’t mean anything either. These are designed to be
accessible and desirable to all. The only thing they indicate is a
certain level of knowledge of a technology. They’re safeguards that allow
technology recruitment people in large corporations to know “ok, this guy
knows java, he’s got a certification to prove it” without having to
interview them.
If you’re hiring for a small business, or you need really smart
developers for a crack team that will implement agile development in your
enterprise, you should disregard most formal qualifications as noise.
They really don’t tell you very much about whether the programmer is
good. Similarly, disregard age. Some programmers are awesome at 18.
Others are awesome at 40. You can’t base your 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 note that age
discrimination is illegal in most countries!).
As a final note to this, in my experience most average or poor
programmers start programming at university, for their Computer Science
course. Most good programmers started programming long before, and the
degree was just a natural continuation of their hobby. If your potential
programmer didn’t do any programming before university, and all his
experience starts when she got her first job, 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 find 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 help 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
technologies 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 with 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!
Thanks for reading.
Charlie Noah
Some excellent points here. It's a pity mok doesn't identify himself
or herself. It sort of takes a little away from the credibility. The
grammar and spelling suggests the poster might be in the UK. I just
hope it's not "that guy", although the post is a bit too lucid for
that.
Regards,
Charlie Noah
DrewConboy
tobewan
Daniel Tenner -
http://inter-sections.net/2007/11/13/how-to-recognise-a-good-programmer/
x
I have a fleet of eighteen wheelers and I need to hire a bunch of
mechanics to service Volvo, Kenworth and Mack trucks.
The article gives me two possible hiring scenarios which I've adapted
to my business.
Positive indicators:
* Passionate about technology
- Heard about the latest F1 regenerative energy systems.
* Programs as a hobby
- Tinkers with his own dirt bike.
* Will talk your ear off on a technical subject if encouraged
- NASCAR galore.
* Significant (and often numerous) personal side-projects over the
years
- Remember his Radio-Flyer cart !
* Learns new technologies on his/her own
- Reads "Popular Mechanics" magazine.
* Opinionated about which technologies are better for various usages
- He's keen on Brembo brakes.
* Very uncomfortable about the idea of working with a technology he
doesn't believe to be “right”
- Hates the old carburetor thing.
* Clearly smart, can have great conversations on a variety of topics
- iTune, iPhone, Roberta Black, Iraq etc.
* Started programming long before university/work
- As a teenager repaired the toaster and changed the kitchen faucet.
* Has some hidden “icebergs”, large personal projects under the CV
radar
- Wants to tinker with a jet ski watercraft.
* Knowledge of a large variety of unrelated technologies (may not be
on CV)
- Knows the difference between a CD, a regular DVD and a blue-ray DVD.
Negative indicators:
* Programming is a day job
- Does truck service & repairs for a living.
* Don’t really want to “talk shop”, even when encouraged to
- Prefers to check the service manuals and do the job at hand.
* Learns new technologies in company-sponsored courses
- If I am going to send him to a GM training course he will gladly
obliged.
* Happy to work with whatever technology you’ve picked, “all
technologies are good”
- If we decide to buy GM trucks he will gladly work on them
* Doesn’t seem too smart
- He does not seem interested in iTune, iPhone, Roberta Black, Iraq
etc.
* Started programming at university
- Learned how trucks are built, how to service them and had hands on
practical experience under the supervision of master mechanics in an
accredited school with his major in Volvo engine and control module
diagnostic and repair and minor in Kenworth engine and transmission
repair and has a "specialist" certification.
* All programming experience is on the CV
- Left out his alma-mater racing club where he is the chief mechanic.
* Focused mainly on one or two technology stacks (e.g. everything to
do with developing a java application), with no experience outside of
it
- He is focused on Volvo and Kenworth and has really no experience
with Tatra, Zim, Hino, FIAT and other trucks.
I don't know why, but I would hire the guy/gal with the negative
indicators.
Lucian