Hiring Programmers and The High Cost of Low Quality 572
An anonymous reader writes "Why is it so hard to find good programmers? And why should companies favor hiring fewer more senior developers rather than many junior ones? Frank Wiles discusses his thoughts in his article A Guide to Hiring Programmers: The High Cost of Low Quality"
Internal Inconsistency in his Argument (Score:2, Interesting)
Anyone who has been a developer or managed developers can tell you that an expert can accomplish as much as 10 average developers. However, companies typically pay only a 10-20% premium for an expert over the average programmer. Whether or not their title is Lead, Architect, Development Manager, Guru or whatever nomenclature the company uses. I am not saying that if your average developer is paid $50k/year that you should pony up $500k/year for an expert. The employer/employee relationship never works like that, but what employers don't seem to realize is that in the end paying more saves them more.
This guy should be ready to put his money where his mouth is: If there really is such a thing as the über-programmer, who is literally 10 times more efficient than his average [median] colleague, THEN BY ALL MEANS he ought to be paid 10 times as much in salary - maybe even more.
The very fact that such disparities in salary don't exist means that either the über-programmer does not exist, or else there is something so screwy about the internal politics of corporations that the suits in management won't stand for some dweeb hax0r making ten times their salaries.
But I think that if the über-programmer really does exist, then eventually the free market will figure that out, and compensate him accordingly.
Re:My own experience... (Score:4, Interesting)
They exist, but they don't know it. (Score:5, Interesting)
Re:Sigh. (Score:5, Interesting)
Re:My own experience... (Score:1, Interesting)
Re:Internal Inconsistency in his Argument (Score:5, Interesting)
We had an über programmer. He left because rather than exceptional pay, he wanted good enough pay and a small company style work life.
We then got in a pickle where some kernel mode drivers for NT4 needed to be revised and SoftICD'd in. Even though he doc'd everything and gave training to our programming staff about gotchas and pitfalls as well as maintenance, it was something that only about 100 people in the world could really do. All we could get done is a widely variating series of BSODs. We hired him back at $12K/day + travel for 5 days of work. He did work his ass off, further document everything, and provide additional spot training to our two brightest. The job was done and he had a check for $60K. I suspect that the training and docs took the vast majority of his time. I asked him why so much (and why MegaCorp would pay that) and he said it was simple. They were a big company not interested in paying him either in lifestyle changes or money so he didn't stay, but for a short job he charged what it was worth.
The free market did work. (considering his solution was cheaper than a contract with MS for the same work by $40K).
-nB
Re:They exist, but they don't know it. (Score:1, Interesting)
Because you can't tell a great hacker except by working with him, hackers themselves can't tell how good they are. This is true to a degree in most fields. I've found that people who are great at something are not so much convinced of their own greatness as mystified at why everyone else seems so incompetent.
I've got to disagree; in my experience hackers tend to be pretty damn egotistical. Average hackers think they're good. Good hackers think they're great. Great hackers think they're on a higher plane of existence.
Re:hireing more people is better then over working (Score:2, Interesting)
Then again, I didn't RTFA, just other comments.
Ask the Yankees if this works. (Score:1, Interesting)
Baseball and programming might not be exactly alike. But look at it this way: The most "talented" individuals in baseball get the most money - yet all that talent pooled doesn't result in the super team that this guy is dreaming about. In baseball, it's fairly easy to measure past performance. Stats up the wazoo, in addition to recordings of their job performance that are easily available. But programmers aren't that way at all. Even if you try your best, filter like crazy, do interview after interview after interview, test after test, you may be getting a complete dud - shows up to work day #1 drunk and starts to watch graphic pr0n.
HR could work from now until the end of time trying to find the perfect fit. They could spend a billion dollars per employee trying to find the best. But that's still no guarantee that you'll get what you're looking for. Usually, you can't know the quality of the service until at least the start of when it's being rendered - and often times not until many years later.
Re:Internal Inconsistency in his Argument (Score:3, Interesting)
There are numerous studies to support this. Taking about 20 seconds to look for one: http://www.joelonsoftware.com/articles/HighNotes.
Also take a look at "Code Complete" by Steve McConnell and "Peopleware" by DeMarco and Lister. Actually, I've seen credible estimates of a factor of 25 times productivity between best and worst programmers. Given the negative productivity I've witnessed, even this may be an under-estimate.
This should be a well-known fact but it isn't. A major part of the problem is cluelessness by the people doing the hiring. You probably can't scale salary by productivity but how about something like the square root of productivity? Of course, the hiring of Bob Nardelli, the mediocre CEO who did nothing at Home Depot, by Chrysler shows how unrelated salary and effectiveness can be.
Easy answer. (Score:5, Interesting)
See The Market for Lemons [wikipedia.org]. The existence of tons of bad programmers, and the inability of employers to tell them apart from good ones, drives the salaries of all programmers towards that of the average programmer.
Read Joel's book (Score:5, Interesting)
I'm a little dismissive of the mystique around the required "super hackers" that never need to look for work but there is a ton of great advice on just hiring people.
I'm an engineer. Been there and done a lot of that. I'm not going to say I'm one of the greatest but not too shabby, I've built some stuff and made some good money, you, know left a few marks.. As a more senior guy I've been taking on more and more leadership and to be completely honest, I like to think there are things I know to look for and catch, but I suck at hiring and team building. At the end of the day it's about building products, selling them and making money and the balance between people you think are a good personality match vs. the people that are technically good enough vs. people that are actually motivated and want to work and be successful is hard. We've hired folks we though were good personality matches for the team and turned out to be terrible technically and completely unmotivated, as much as you might want to like them, you simply won't when they are trying to play big business "CYA" games and not actually contributing to the team.
I'm kind of dealing with a situation now, we're a small team, 4 or 5 developers and 2 testers. We hired the 5th developer based largely upon a recommendation from one of the testers. He's a marginal tester to be honest, good guy, just not super motivated, why we hired his recommendation is looking more and more stupid by the day, we value recommendations. After reading Joel's book I've found like 6 or 7 indicators that probably would have flagged this guy that we simply didn't think about. We were in a hurry, we thought the req would go away, etc.. Honestly, I'd rather have one fewer people and better morale that this guy, seriously in 6-8 months of having him, I cannot point to a single substantial contribution. Now we get to go through the process of firing him which sucks for every one involved also.
Basically, you always want smart people, you want motivated people, people that do a good job, people that have some passion, good communicators, strong team people that know what it is to be on a team, you want all of that stuff, all of the time and it's hard to find. We pretend that parts don't matter or don't matter as much. Having shitty people on your team just flat out sucks, doesn't matter how good everything else is.
Re:Internal Inconsistency in his Argument (Score:5, Interesting)
The real answer is that most uber programmers work for that small premium. They get to do what they want, get a few other perks like their choice of assignments, and are generally happy as is. Money isn't really the key motivator for them- if it was, they'd be in another field that pays more.
Unfortunate reality (Score:5, Interesting)
In the interim, unfortunately, we realistically need to take in some of the graduates that we have and finish the education they apparantly never received in full. If we don't -- if we let a bubble form between now and when the educational system corrects itself, then we will effectively lose much of the "tribal knowledge" that is passed down through the generations of the workforce.
You cannot sustain a class of experts in any endeavor simply by surrounding them with other experts. At some point they must mentor or pass down their knowledge to the next generation -- but the best way to ensure the next generation is to make sure that they're at least on-par as a developer.
I say all this as a relatively young developer who graduated in Computer Science in 2002.
This article has no value (Score:1, Interesting)
Testing.... (Score:4, Interesting)
If programming games is your dream, we're the place for you. Please send in examples of your work, no matter how trivial. Websites are acceptable as well. You can't always work in one language long enough to know the syntax by heart. But the concepts are reusable, that is what we look for. C/C++ knowledge is an advantage but not necessary.
The comment went along the lines of, how can a company make any good games if they hire just anyone off the street? Well, we do. But everyone has to pass a test. We basically hand them a copy of the engine and give them the instruction of. "Complete it" It's their job to read the code, figure out what it does, and add their own code to extend functionality. The test basically tests their ability to grok it. To get it to compile. Then to extend the code while following proper standards and naming conventions( As long as you follow the style of the rest of the code, we're happy ). Finally, their creativity. We don't tell them how to complete it. So some people do the bare minimum which shows competence, and some go all out. But usually you can tell what they like. Some are AI heavy, some do a lot with player mechanics, and some start extending the engine when they want to do more (Warning : Not Invented Here Syndrome Probably Present).
So we've got some older guys from the VIC-20 days, some young college grads and some non-traditionally trained programmers. I'm a tools and build process guy myself. Engine is another set of people that hate muddling with gameplay because you can only spec so much, the rest is up to...testing and feel, and they hate repetitive work like that. The gameplay guys that love to noodle and pull magic numbers out of the air and test until it feels "just right".
We also do products in staggerred teams. Several experienced developers, several inexperienced. Let the experienced funnel the knowledge down. Rotating R&D cycles, so everyones fingers is in the engine at least a little bit. Really experienced outside developers have their issues sometimes as well. They are very set in their ways, and it's hard to mold them to your system. Which is why Microsoft prefers hiring physics and math majors. They haven't learned any bad habits yet. Sure when it comes to crunch time, we do neglect the juniors, but that is when the smart one's start to shine.
Re:Languages (Score:3, Interesting)
I actually got a recruiter e-mail the other day for which I was basically a perfect match. I even had the soft skills they were looking for "bilingualism", training and support experience.
So I replied with the resume and comments about salary range (which wasn't listed), experience range (also not listed) and how the job listing looked very "boilerplate" and looked like a request for "bodies" and not for talent.
He replied with the list of 20 questions asking for further details. The first 8 questions were "how much experience have you had with technology XYZ"... So I replied by saying: you didn't answer my question about salary range and you asked really stupid questions, clearly this is not a job for me.
End of the day, recruiter just cost them an opportunity and never addressed any of my issues.
Re:Sigh. (Score:2, Interesting)
When folks ask, what do I write in? I say, Java (since 1.0.2, I'm now into 6), HTML (really, XHTML 1.0) CSS/JavaScript (my AJAX runes on even IE 5), etc. I have Software Development experience ranging from big teams at GE to small elite teams. Right now, I can make around 150k easily/year. I know Perl, PHP, etc. But I admit to these last.
The moment I'm not useful I know they will fire me that day. But right now, these specific skillz pay very well.
Re:How do you tell the difference??? (Score:3, Interesting)
The trouble might be that it's more difficult in coding to tell who really won the race, even after the fact.
Re:Sigh. (Score:3, Interesting)
Re:Sigh. (Score:4, Interesting)
I think we're talking about two different things.
By "specialist" I wasn't talking about idiots who specialize in one part of a particular programming language. I was talking about the people who specialize in writing software for one part of a particular industry and know that part of their industry very, very well.
For example, people who specialize in industrial robotic systems, telecom systems, automotive computer systems, avionics systems, etc.
To put it another way: Do you want the avionics in the plane your flying in to be written by 10 specialists with 200 years combined experience writing avionics systems, or by 50 general programmers with 5 years combined experience writing avionics systems?
Re:Oh god, they never get this right. (Score:4, Interesting)
As you can probably tell, this is what I do - design and difficult stuff. I really enjoy that. Others do GUI, build process, configuration, and what-have-you. Some of them like their work because they get to go home and not think about their work until next morning. They will stay "junior" forever, but are perfectly happy with that. They don't have a passion for their work, so they should never ever be allowed to do the design or solve the difficult problems, and most of the time they don't even want to.
Now management, that's another issue. They simply fail to understand that there can easily be a factor of 5 or 10 difference in the total time it takes for any two of us to complete a certain task with any reasonable measure of quality. This works both ways - I end up spending more time doing GUI work than those who like that work, simply because it is a kind of work that does not motivate me. Likewise, solving that OS and transport-independent highspeed failover service protocol was my work, because that is what I do 10 times faster and better.
Re:More to it than skillz (Score:1, Interesting)
Re:Sigh. (Score:1, Interesting)
Frightening isn't it? Certification 4tw! I stepped in and had his installer running in 7 minutes after he wasted 2 days on the phone with support. Keep in mind this was Oracle 10i and I'd never installed it on Sun before. I'd never been at a Sun prompt, but know BSD, Linux and Unix systems.
It's almost as bad as the MCSE I worked with who didn't know what ftp was. She literally couldn't get to Microsoft's ftp server to download something (this was back when their patches, resource kit, etc. were available on ftp)
If I'm ever in charge of hiring, there will be a system in my office when I interview people, where they get to show me what they know instead of telling me about what they know, or showing me a piece of paper. If it's an Oracle Admin, there will be a default install of Sun OS on the box, and the candidate will install it right there in the interview and get it up and running in front of me, or he'll look elsewhere for a job. Just take a sliver of their supposed skill set and spot check.
Only takes 10 minutes right? It's not hard to see who the idiots are, just put a terminal in front of them and ask them to do something.
-AC
Re:Sigh. (Score:2, Interesting)
I'm somewhat of a generalist (minus pretty web GUI's...), and my boss and I agree we can outdo (performance- and time-wise) the contractor through the entire cycle.
FTA: "Experts use better tools and care deeply about their craft. They aren't assembling bits on an assembly line, they are crafting a unique product to solve a unique problem. Experts are lazy, they work smarter rather than harder. Experts prefer the easiest solution that gets the job done. Experts aren't interested in creating complex solutions simply to have the complexity, that misguided egoism is the territory of more junior developers. They often get it right the first try and almost always on the second one."
This is the sad truth of my job: replace "experts" with my name and "more junior developers" with "our off-shore developers led by an American" and you have a pretty solid description of our development story. Locally, I *am* the dev team, and that doesn't really bother me as we aren't an IT company. My boss and I agree with this article: we should axe the clowns overseas and get one more *good* developer in here.
Then again, having these bozos arounds just makes me look even better, but it's not worth the headaches, and I'd frankly rather just write ALL the code and make it bulletproof and completely end-user configurable and operable. So in the words of the GGGGP: sigh.