How to recognise a good programmer(inter-sections.net)
inter-sections.net
How to recognise a good programmer
http://inter-sections.net/2007/11/13/how-to-recognise-a-good-programmer
14 comments
"We met with some programmers who were passionate, but were obviously charlatans."
And how did you tell the difference? (when it wasn't obvious... or was it always obvious?)
And how did you tell the difference? (when it wasn't obvious... or was it always obvious?)
Well, we did hire one charlatan programmer, but we dropped him pretty quick when we realized that he couldn't produce the quality and quantity of work that he claimed possible. Like I said, this was when we didn't know diddly about programming / hiring programmers.
Regarding the ones that were obvious (as it seemed to me), they were lingo dropping high-horsers, and when we looked at their previous work and saw that they were producing crusty web applications while claiming that they were abreast of all the latest technologies, we knew something was up.
We chose at one point to work with a web development firm that promised great things and they had a strong team... but what I wish we would have payed more attention to was the fact that they were working on MANY other projects and were spread way too thin. In the end they were late on every deadline so we stopped working with them.
I feel fortunate to be working with two other great developers now. But I've worked with several doozies, and it has been through that process that I've learned more about who to hire, and I'm much more cautious now.
Regarding the ones that were obvious (as it seemed to me), they were lingo dropping high-horsers, and when we looked at their previous work and saw that they were producing crusty web applications while claiming that they were abreast of all the latest technologies, we knew something was up.
We chose at one point to work with a web development firm that promised great things and they had a strong team... but what I wish we would have payed more attention to was the fact that they were working on MANY other projects and were spread way too thin. In the end they were late on every deadline so we stopped working with them.
I feel fortunate to be working with two other great developers now. But I've worked with several doozies, and it has been through that process that I've learned more about who to hire, and I'm much more cautious now.
Thanks a lot for taking the time for writing such useful reply.
The list of qualities here would indicate a good person in any profession, not just programming. I think these challenges only exist because we (as a society) have learned to accept schooling as the indicator of qualification.
Anyone with these traits probably is good, but a programmer that doesn't have them is almost certainly not good. I imagine there are plenty of plumbers and accountants who don't work on personal projects, have hidden experience, or play with bleeding-edge technologies and are still good. In those fields, schooling is still probably the best indicator of qualification.
The more artistic the profession, the less telling someone's formal education seems to be. Since programs can do anything that our minds can think, programming tasks range from the hardest of hard sciences (say, compiler optimization) to pure art (videogames, for example). I suspect the best compiler optimizers went to (and perhaps now work for) the best schools, while I doubt there's much correlation between schooling and great game developers.
The more artistic the profession, the less telling someone's formal education seems to be. Since programs can do anything that our minds can think, programming tasks range from the hardest of hard sciences (say, compiler optimization) to pure art (videogames, for example). I suspect the best compiler optimizers went to (and perhaps now work for) the best schools, while I doubt there's much correlation between schooling and great game developers.
a programmer that doesn't have them is almost certainly not good
Maybe that is true if your bag is Web 2.0 AJAX Rails etc etc. But I'll bet the people writing "serious" software (for example, safety-critical embedded systems) are treating it exactly the same as say Civil Engineers treat their jobs. I'd be very reluctant to call them "not good", how reliable is their work compared to the average website?
Maybe that is true if your bag is Web 2.0 AJAX Rails etc etc. But I'll bet the people writing "serious" software (for example, safety-critical embedded systems) are treating it exactly the same as say Civil Engineers treat their jobs. I'd be very reluctant to call them "not good", how reliable is their work compared to the average website?
Schooling might not work so well as qualification, but take care not to trivialize the problem. You can't really figure out how good someone is until you've worked with them, unless they have a long string of accomplishments. Schooling might be a little above noise, but at least it functions as a fairly reliable minimum bar.
Based on the deluge of resumes I've seen coming into tech shops lately, the bar set by college degrees is so low that you need to dig to find it.
That is why there is the notion of league tables for colleges. My friends with MBAs say quite plainly that unless an MBA is from a "top 25" school, it simply isn't worth doing or having.
That leads me to believe it is a bullshit field of study altogether, if the only metric of worth is the school name.
CS graduate from MIT or Podunk U?
Well, can they code or not?
[deleted]
I disagree. I work with a brilliant coder who dropped out of high school.
I dropped out of highschool too; my point is that a degree in a technical discipline, from a tough school, will filter out many people who are incapable. It's the low bar to jump over. But by no means will all of the brilliant people have degrees, nor even decent looking credentials, on paper.
(A ⇒ B) ⇏ (¬A ⇒ ¬B)
I've got to say - In my experience, industry-based qualifications are more often than not a counter-indicator.
This was particularly true of the Java certifications during the dotcom boom - it was invariably the sign of someone who really just wanted to cash in... Out of the ten hires I was directly involved with, 6 were Java certified and 5 of those were absolutely terrible.
It might demonstrate a knowledge of Java, but at a very superficial level - even if you take someone with the best vocabulary in the world, it doesn't mean they'll be a good author.
A degree is a bit different. It at least demonstrates - a probable understanding of the fundamentals, the ability to stick at something and a certain level of exposure to broad ideas... Plenty of good programmers won't have degrees, but it's not a bad indicator none-the-less.
This was particularly true of the Java certifications during the dotcom boom - it was invariably the sign of someone who really just wanted to cash in... Out of the ten hires I was directly involved with, 6 were Java certified and 5 of those were absolutely terrible.
It might demonstrate a knowledge of Java, but at a very superficial level - even if you take someone with the best vocabulary in the world, it doesn't mean they'll be a good author.
A degree is a bit different. It at least demonstrates - a probable understanding of the fundamentals, the ability to stick at something and a certain level of exposure to broad ideas... Plenty of good programmers won't have degrees, but it's not a bad indicator none-the-less.
Just coincidentally, these happen to be the exact attributes the author believes he has! How fortunate!
Unfortunately, there are programmers that you could recognize using these criteria who produce highly idiosyncratic code that's nearly impossible for someone else to maintain for the months it takes for them to come up to speed. There are also programmers who would be recognized by this criteria who are just as insightful and productive who produce beautiful intention revealing code.
How would we recognize the latter group?
How would we recognize the latter group?
Try asking them.
"Hey, do you find most of your colleagues are familiar with your code or do you find most of them have trouble getting up to speed with it?" You can ask this question in a very neutral tone, one that implies that the colleagues may have been at fault.
And then, be very careful to determine whether the colleagues really weren't at fault. If you're trying to hire a very smart person, you may find someone who has chafed writing J2EE code in BigCo, and yes his code was inscrutable to his colleagues, that's why he wants to write Python code for you.
"Hey, do you find most of your colleagues are familiar with your code or do you find most of them have trouble getting up to speed with it?" You can ask this question in a very neutral tone, one that implies that the colleagues may have been at fault.
And then, be very careful to determine whether the colleagues really weren't at fault. If you're trying to hire a very smart person, you may find someone who has chafed writing J2EE code in BigCo, and yes his code was inscrutable to his colleagues, that's why he wants to write Python code for you.
I've witnessed solo programmers writing brilliant but inscrutable code in Smalltalk. Bittorrent's code also fit this description for awhile. Someone who writes inscrutable code in J2EE in BigCo might do so because he's hobbled by their coding standards. But he might be one of those folks who is a brilliant coder but has no sense of what is intention revealing to those reading his code.
I agree. All I can say is... the OP mentions indicators. It is absolutely correct that they are merely hints. You still have to interview them and/or test them and/or check references from former employers and/or check references from former colleagues, and/or...
In this particular case I speak as someone who has received both praise for my ability to write code that my colleages find crystal clear and vilification for writing code that my colleagues find inscrutible.
Did I mention code samples? I have code I can share. I like it when I'm interviewing and someone has code they can share.
In this particular case I speak as someone who has received both praise for my ability to write code that my colleages find crystal clear and vilification for writing code that my colleagues find inscrutible.
Did I mention code samples? I have code I can share. I like it when I'm interviewing and someone has code they can share.
Make them read code.
Take a chunk of good code, a chunk of bad code (real code, not toy stuff), and ask them to explain it, find any bugs, and recommend improvements.
Take a chunk of good code, a chunk of bad code (real code, not toy stuff), and ask them to explain it, find any bugs, and recommend improvements.
Everytime I read these kind of articles I see the one glaring headline, how programmers love to work outside of their regular work day
Then I become sad because 80% of my week I come home and have to handle something and by the end of it all, I don't have any time to play around (aka, program) because I have to go to bed. Sigh, vicious cycle :(
(I know I can work on managing my time better and I am, like cooking more meals for the week, and time-boxing other tasks .. but it takes time!)
Then I become sad because 80% of my week I come home and have to handle something and by the end of it all, I don't have any time to play around (aka, program) because I have to go to bed. Sigh, vicious cycle :(
(I know I can work on managing my time better and I am, like cooking more meals for the week, and time-boxing other tasks .. but it takes time!)
Freud was once asked what he though a normal person should be able to do well. The questioner probably expected a complicated, a "deep" answer. But Freud simply said, "Lieben und arbeiten" ("to love and to work"). It pays to ponder on this simple formula; it gets deeper as you think about it. For when Freud said "love", he meant the expansiveness of generosity as well as sexual love; when he said "love and work," he meant a general work productiveness which would not preoccupy the individual to the extent that his right or capacity to be a sexual or loving being would be lost.
(From "Identity and the Life Cycle", by Erik H. Erikson)
Yes, this is a repost of a comment but it is relevant. Work can cut into life and life can cut into work...
(From "Identity and the Life Cycle", by Erik H. Erikson)
Yes, this is a repost of a comment but it is relevant. Work can cut into life and life can cut into work...
Thanks for posting that, it's actually stuck in my head since you did yesterday .. just never got around to posting a reply :)
as a programmer, one of the things i look for in a company is a willingness to let a guy like me play around with technology on the side and not have scary legal documentation concerning their ownership of it. while i work for a startup at the moment, my previous employer (a well-known language learning software company) actively discouraged its employees from pursuing any side projects.
if you're looking to hire someone who's driven, this is a terrible idea; a good programmer will always be thinking of something, mulling some problem over in his head. probably several, a few of which aren't related to his job. if he has to worry about whether or not he can legally work on these things outside of his regular employment, he's less likely to explore, and less likely to learn on his own time.
so hiring managers and legal departments: look for someone who checks over the contracts for ownership rights and complains if they're too strict.
if you're looking to hire someone who's driven, this is a terrible idea; a good programmer will always be thinking of something, mulling some problem over in his head. probably several, a few of which aren't related to his job. if he has to worry about whether or not he can legally work on these things outside of his regular employment, he's less likely to explore, and less likely to learn on his own time.
so hiring managers and legal departments: look for someone who checks over the contracts for ownership rights and complains if they're too strict.
I have found this to be creeping up on me as well. I think that particular work environments make it more likely to become a habit.
To combat it, I try to find time to squeeze in little unorthodox projects with my work, as long as they can be justified as valuable. Of course, I think my sanity and skills are probably valuable to the company too.
To combat it, I try to find time to squeeze in little unorthodox projects with my work, as long as they can be justified as valuable. Of course, I think my sanity and skills are probably valuable to the company too.
Problem is that many of the positive indicators are also present in bad programmers.
My experience is that it is extremely hard to recognize good programmers from bad programmers on the basis of personality traits.
The only think that seems to work is to actually investigate how well they read and write code.
My experience is that it is extremely hard to recognize good programmers from bad programmers on the basis of personality traits.
The only think that seems to work is to actually investigate how well they read and write code.
I'm tired with people putting elite programmers on pedestals. I used to almost worship this one code guru at my company but I eventually moved on to just working on myself, taking up avocations outside of programming. I'm fortunate to be able to code/problem solve for a profession.
This is an article for recognizing good programmers, so you can hire them, not for other programmers to admire them.
Exactly.
Maybe you are contemptuous of them, but you have a business plan that involves having them work back-breaking hours for some founder's equity you will dilute down to the strength of Budweiser beer.
That sounds like sarcasm, but consider the case of salespeople. Many people have trouble liking salespeople, and many people do not admire them. But many businesses would close without good salespeople. So you try to find and hire the best salespeople you can find.
Wanting to put someone to work in a manner advantageous to your business is entirely orthogonal to putting them on a pedestal.
Maybe you are contemptuous of them, but you have a business plan that involves having them work back-breaking hours for some founder's equity you will dilute down to the strength of Budweiser beer.
That sounds like sarcasm, but consider the case of salespeople. Many people have trouble liking salespeople, and many people do not admire them. But many businesses would close without good salespeople. So you try to find and hire the best salespeople you can find.
Wanting to put someone to work in a manner advantageous to your business is entirely orthogonal to putting them on a pedestal.
[deleted]
I would look for the ability to think i.e., quickly and logically breaking a problem into its components and get to the essentials. Ask good questions along the way, and come up with a solution to the problem. Do this in an area outside their expertise.
Anyone who passes that test with flying colors and is interested and engaged while doing it has a first-rate mind. The rest is detail -- do they know this language? if not, do they want to learn it? can they work with other people? do other people want to work with them?
Valuing "passion" (in the 20-something hacker crowd) or a university degree (large software companies too numerous to name) over the ability to think clearly in the abstract are both unfortunately too common. It seems to me that either is more a tool for recognizing "people like us" than to actually identify a good programmer.
Anyone who passes that test with flying colors and is interested and engaged while doing it has a first-rate mind. The rest is detail -- do they know this language? if not, do they want to learn it? can they work with other people? do other people want to work with them?
Valuing "passion" (in the 20-something hacker crowd) or a university degree (large software companies too numerous to name) over the ability to think clearly in the abstract are both unfortunately too common. It seems to me that either is more a tool for recognizing "people like us" than to actually identify a good programmer.
If this article is correct: I should make a career change
Aren't these instructions on "How to recognise an hypermind programmer"?
Edit: I agree that this way you can recognize good programmers, but are all good programmers supposed to be that way, or only hyperbrain/INTP/whatever?
Edit: I agree that this way you can recognize good programmers, but are all good programmers supposed to be that way, or only hyperbrain/INTP/whatever?
Hia,
I wrote this article a long time ago, long before the whole hyperbrain thing. It was actually published here, although with "www" in the URL, which explains why it can be reposted :-/
This was actually the article via which I found HackerNews, since HN showed up as a large referrer in my logs so I came here to investigate and, finding it to my taste, stayed.
And to answer your question, no, I don't think these characteristics are in any way related to hyperbrains.
(initial post of this article: http://news.ycombinator.com/item?id=97121 )
I wrote this article a long time ago, long before the whole hyperbrain thing. It was actually published here, although with "www" in the URL, which explains why it can be reposted :-/
This was actually the article via which I found HackerNews, since HN showed up as a large referrer in my logs so I came here to investigate and, finding it to my taste, stayed.
And to answer your question, no, I don't think these characteristics are in any way related to hyperbrains.
(initial post of this article: http://news.ycombinator.com/item?id=97121 )
Hi, thanks for answering. I relate this to hyperbrains because it talks about programmers that: a) are intelligent, b) work in a lot of different projects, possibly unrelated, that are usually hidden, c) are passionate, and self-taught. Maybe not(hyperbrains<->your good programmers), but I'm sure a stable hyperbrain programmer would have all characteristics on your list.
Anyway, I don't like the hyperbrain word (sounds too powerful, as if being better than the other brains and I don't like it), though I really like your articles on the subject btw.
Anyway, I don't like the hyperbrain word (sounds too powerful, as if being better than the other brains and I don't like it), though I really like your articles on the subject btw.
I'm sure a stable hyperbrain programmer would have all characteristics on your list.
That's quite possible, actually. Someone with a hyperbrain who also happens to be a programmer will probably fit most of these criteria - but then, I would say that this is more an indication of hyperbrains being well adapted to programming than of good programmers being hyperbrains.
Anyway, I don't like the hyperbrain word (sounds too powerful, as if being better than the other brains and I don't like it), though I really like your articles on the subject btw.
Thanks. I came up with "hyperbrain" because I felt I had to call it something for it to stick out. Hyperbrain seems like a reasonable term because: a) it's not in use, b) it transmits the idea that this kind of person is "hyper", in the sense of being more extreme in their behaviour. Certainly it's not perfect, but oh well. If it sticks around, it'll stick around, if not, it won't ;-)
That's quite possible, actually. Someone with a hyperbrain who also happens to be a programmer will probably fit most of these criteria - but then, I would say that this is more an indication of hyperbrains being well adapted to programming than of good programmers being hyperbrains.
Anyway, I don't like the hyperbrain word (sounds too powerful, as if being better than the other brains and I don't like it), though I really like your articles on the subject btw.
Thanks. I came up with "hyperbrain" because I felt I had to call it something for it to stick out. Hyperbrain seems like a reasonable term because: a) it's not in use, b) it transmits the idea that this kind of person is "hyper", in the sense of being more extreme in their behaviour. Certainly it's not perfect, but oh well. If it sticks around, it'll stick around, if not, it won't ;-)
Someone with a hyperbrain who also happens to be a programmer will probably fit most of these criteria - but then, I would say that this is more an indication of hyperbrains being well adapted to programming than of good programmers being hyperbrains.
Touché. If your criteria for good programmers is ok, then you are right.
Touché. If your criteria for good programmers is ok, then you are right.
I only use one criteria: demonstrated performance.
You mentioned that in the previous posting of this article, but I wasn't around to reply back then :-)
I agree that demonstrated performance is the ideal, but there are two problems with it:
1) it's slow and expensive. Who do you ask to demonstrate performance? You need some initial filter to cut out most of the crud, otherwise you'll spend all your seed money getting people to demonstrate performance. These indicators allow you to perform some sort of preselection, at least. Also, if you're interviewing, you'll find that most good people get snapped up before you have a chance of seeing their performance, so you'll miss out on 90+% of good hires.
2) What if you don't know how to tell good performance from bad? You can't reply that "a non-technical guy has no business hiring a technical guy". This article is aimed at business guys, and they have the very real problem of needing to basically boot-strap their business's technical expertise starting from nothing. This article can help recognise a good cofounder too. At that point "demonstrated performance" is fairly irrelevant, since as a business guy you wouldn't be able to tell good performance from bad - however, you can still tell passion from lack of it, or hidden experience from purely on-the-job experience.
I agree that demonstrated performance is the ideal, but there are two problems with it:
1) it's slow and expensive. Who do you ask to demonstrate performance? You need some initial filter to cut out most of the crud, otherwise you'll spend all your seed money getting people to demonstrate performance. These indicators allow you to perform some sort of preselection, at least. Also, if you're interviewing, you'll find that most good people get snapped up before you have a chance of seeing their performance, so you'll miss out on 90+% of good hires.
2) What if you don't know how to tell good performance from bad? You can't reply that "a non-technical guy has no business hiring a technical guy". This article is aimed at business guys, and they have the very real problem of needing to basically boot-strap their business's technical expertise starting from nothing. This article can help recognise a good cofounder too. At that point "demonstrated performance" is fairly irrelevant, since as a business guy you wouldn't be able to tell good performance from bad - however, you can still tell passion from lack of it, or hidden experience from purely on-the-job experience.
If I was hiring I'd say "point me at a public repo of some of your code."
Introverts are generally good programmers.
That is a preposterous claim! Perhaps you meant that good programmers are often introverts?
I think programmers in general are often relatively introverted, however my anecdotal experience is that good programmers are not on average more introverted than bad programmers. So introversion is a really bad indicator.
I think programmers in general are often relatively introverted, however my anecdotal experience is that good programmers are not on average more introverted than bad programmers. So introversion is a really bad indicator.
For the last two start-ups in which I was involved (as a graphic designer), a co-worker and I were placed in the position of choosing developers to build our application. We were the most technologically savvy people on our start-up team of businessmen, attorney's, accountants, etc. (in many ways those startups followed the inverted timeline of most startups).
At first the only questions we could ask the applicants were... what languages do you know? what projects have you worked on? how would you solve this problem?... as if their answers would inspire some confidence regarding their abilities as a programmer - their answers inspired nothing because WE knew nothing. What I'm saying is that if you are going to hire people, you have to educate yourself to a conversational level+ in their area of expertise.
Nowadays my said co-worker and I both know RoR and are building our own startup apart from that original group. And when we decided to hire another developer we were in a MUCH better position not only to recognize a strong programmer but to leverage our own abilities.
Be wary of his point regarding PASSION. We met with some programmers who were passionate, but were obviously charlatans.