Slashdot Log In
Hiring Programmers and The High Cost of Low Quality
Posted by
CmdrTaco
on Mon Aug 06, 2007 05:29 PM
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"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Sigh. (Score:5, Insightful)
Some of the best developers I know were originally trained as journalists, mathmaticians, linguists, and other professions not normally associated with software development...
As a generalist programmer, originally trained in cognitive science, who has formerly worked in several disparate industries, was a systems administrator, programs in half a dozen languages (including perl), etc, etc...Apparently I'm supposed to be making twice my salary. Goddamnit!
*stomps off in search of his boss*
These days, being a programmer generalist (even worse, one with admin experience) just increases the types of shit that get dumped on you...Where they might have had to hire a person to do the front end GUI code, a person to do the database work, a person to set up the server, and a person to code all the services that need to constantly run in the back end, instead, since they've got you, you can do it all, while the specialists sit around drinking coffee and making catty comments about how much better they are at what they do than you are.
My advice is specialize in something to the point where when you do any work on it, it's immediately out of the comprehension of a generalist or a less accomplished programmer...Sure, everyone will hate you, but they'll have to deal with you, and you'll be in a position to dictate terms. What's a generalist got? They're great employees. Big deal. Being a great employee is like being a great dog; at the end of the day, they'll still euthanize your ass when you're no longer of use.
//Not bitter or anything.
Re:Sigh. (Score:5, Interesting)
Parent
Re:Sigh. (Score:5, Insightful)
Three possible methods... may be used in combination:
1) Small companies/organizations
2) Being completely oblivious to politics and not getting involved
3) Consulting/contract work
Note, I'm not the original person you were asking. I just thought I'd chime in.
Parent
Re:Sigh. (Score:5, Insightful)
Another good strategy is simply to be good at what you do and don't give anyone any reason to doubt your sincerity or integrity. Always be upfront, frank, and honest. Never be afraid to say "I don't know" if you don't know something. If/when someone approaches your boss to complain about you (presumably for no good reason), your boss will take your side by default and you can therefore remain oblivious to the politics.
Of course, if you're in management, too bad. Politics is pretty much your jobs then.
Parent
Re:Sigh. (Score:5, Insightful)
Parent
Re:Sigh. (Score:5, Funny)
Perl and Batch files it is!
Parent
Re:Sigh. (Score:5, Insightful)
Basically, some people are just better coders, and adding sub-standard assistance just ensures late, sub-standard software. Adding people to late projects makes them later.
Parent
Re:Sigh. (Score:5, Funny)
Parent
How do you tell the difference??? (Score:5, Insightful)
By some estimates, Good Programmers can be a factor of ten or more productive than Bad Programmers, yet they are seldom paid more than a few tens of % higher. It would be far better for most companies to pay double the going salary to attract only the best, but unfortunately business thinking does not seem to be structured that way.
Most organisations base their planning on some convenient notions like programmer-months etc, using some standardised measure for programmer capability. These measures are great because they make the spreadsheets look neat and tidy. They also make all the outsourcing logic work: "I can get programmers in country xxx for $10 per hour". Untimately they are flawed because you get what you measure. If you don't pay a premium for good programmers you won't get them. You end up spending mucch more on crappy programmers.
Parent
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.
Parent
We all have to start somewhere... (Score:5, Insightful)
My college never stressed learning any one language well. Rather, it taught us the tools and techniques we would need to survive in the ever-changing world of software development. Yet none of this seems to count for anything. No past experience with a company? Goodbye. The fact of the matter is, I need to start somewhere. Right now I'm sitting at a job that I feel doesn't tap my abilities, yet I put up with it for the "experience." The number of opportunities for fresh graduates are few and far between, and you have to take what you can get.
Re:We all have to start somewhere... (Score:5, Insightful)
* use source control?
* analyze someone else's code (multiple people's code), figure out what it's doing, and map that to what it's supposed to be doing?
* can you understand the bug at all (what is is supposed to be doing)?
* can you figure out how to verify that your fix actually worked?
* do you understand how to configure and use the product you're working on?
* explain what you're about to do, and justify why it should be done like that?
* be focused enough to fix one (1) bug, and not go off and rewrite a whole lot of stuff that looks like cr*p?
* not break the build?
In real life, doing architecture and writing stuff from scratch rarely happens...but that's all they teach you in school. In real life, you're working on some big pile of code that you're stuck with, can't change, and don't understand. You can fix #3, but usually #1 and #2 are immutable...until the magical day when they need a new feature (hey, we need to redo a whole chunk of that thing to get the new feature to work).
Do you need experience? Write something. Nothing sells your coding skills like code. The downside is that people will be able to see how your code is. If the programmers in your target company are good, they'll be able tell the difference between someone who's new and someone who just sucks. If they aren't so great, then your code is still a plus, because they won't know how bad it is.
Parent
Re:We all have to start somewhere... (Score:5, Insightful)
As someone with experience I'd just like to suggest that maybe they aren't stuck in a logical loop. Maybe you aren't the person they want, they want someone with experience.
Here's an idea: As a computer programmer, you are in a unique position to make your own experience. I got started in "the business" by developing a totally crappy (seriously, I'm ashamed) graphing calculator for the HPC. I have an HPC, I needed a graphing calculator, and I'm cheap, so I really wrote it for myself. Then I put it up on the web and people liked it, so that became the first point on what is now a long programming resume.
My point is, you don't have to get hired by anyone to get experience. If you don't have an idea or an itch to scratch of your own, pitch in on some open-source projects.
When I am hiring junior programmers, the guy who is fresh out of school I'm going to overlook. The guy who's fresh out of school AND has some projects of his own he's worked on is EXACTLY the guy I want, though -- not only do I know he's knowledgable and capable, I also know he's a self-starter who's not going to wait around and whine and bitch that no one is giving him an opportunity. The opportunities are out there, you can't wait for someone to give them to you... you have to go take them.
Seriously, go *do* something. It'll take your mind off being out of a job and if you do it right it will be the thing that gets you a job. It's win-win.
Parent
Yeah, right (Score:5, Insightful)
HR ... (Score:5, Funny)
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.
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.
They exist, but they don't know it. (Score:5, Interesting)
Parent
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
Parent
Re:Internal Inconsistency in his Argument (Score:5, Insightful)
It has, and then some. These "über-programmers" are what you and I know as "wildly successful startup founders." Part of the reason it's so hard to hire them is because they are mostly already independently wealthy and / or personally invested in a project of love that no offer of cash and benefits will draw them away from. Most likely, if the former is not true, the latter will eventually cause it to be true. The best and most common way of hiring an über-programmer is to buy the company they currently work for.
Parent
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.
Parent
Re:Internal Inconsistency in his Argument (Score:5, Insightful)
The best approximation is that each problem has a certain complexity and a certain size. The size determines how long it will take, and it doesn't matter how good the developers are. The complexity determines how good a developer is needed to make progress at all. If you've got only easy problems, an uber-programmer doesn't help you much (unless the programmer can find a smaller, harder problem that replaces the big easy one). If you've got a hard problem, ten average programmers will work on it forever without getting any results.
And there's one last thing specific to computers: the computer can solve easy problems for you, but making it do so is a hard problem. But solving that one hard problem (plus some processor time) resolves a lot of easy problems. Another type of hard problem is writing a magic library function that makes a range of moderately hard problems easy enough for average programmers to solve.
If you've got ten people essentially doing data entry, an uber-programmer may be able to eliminate the need for them to do that at all. If you've got ten developers working on some problem, an uber-programmer may be able to double their productivity. In either of these cases, the uber-programmer directly produces something that isn't part of the actual project, but the benefit to the project is on the order of ten average programmers' work. And, if the uber-programmer reduces the complexity of the problem to put it in reach of the rest of the team, no amount of ordinary programmers' work would benefit the project as much as the uber-programmer's contribution. Of course, if you require an uber-programmer to literally do the work of average programmers, there's no benefit at all.
Parent
Re:Languages (Score:5, Insightful)
Parent
Re:Best damn article in a while (Score:5, Insightful)
Dumb question, but if nobody trains new developers, then where the heck are those more experienced developers supposed to come from? And of course the related question, where did the few that we now have come from?
T
Parent
Re:close your browser now boss (Score:5, Insightful)
1. it isn't garbage and spaghetti because you have difficulty following the technique, there are a thousand ways to do anything. It's garbage and spaghetti when it doesn't work well, and when it's under documented.
2. Could you really write it in six months without referencing the code you are talking about? It's one thing to write code when the problems have been solved, quite another to solve the problems.
3. the scope of a job changes over time. For a new programmer, start looking for scope creep, it's a friend and an enemy.
4. code changes over time because languages change over time. Look for those situations in the spaghetti code where those guys that you are better than wrote functions that were not available in the language. You may get a surprise that they did something really elegant to overcome something missing in the language originally that exists now.
5. lets say that there were five programmers on the code before you, one after another. The first four might have been gods gift to programming, it only takes one pretentious newbie in the chain to really screw up pretty code.
certainly none of these apply to your project, but it's something to think about as you are exposed to projects in your career.
Parent