Slashdot Mirror
Hiring Programmers and The High Cost of Low Quality
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"
FTA: ...Experience is key, but not necessarily in ways you might imagine. Time in the saddle, with a particular language is not as important as diversity of experience. Someone who has worked in several disparate industries, a generalist, is often a much better developer than one who has spent years in the same industry. There are exceptions to this, but in general I have found this to be the case. Bonus points if your developer was a systems administrator in a former life.
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
The hardest part of finding a new job is getting past the recruiters, who are generally not capable of anything more than keyword matching against your experience. Use your contacts if you can to get in front of the technical managers who will understand that your domain knowledge and overall experience is more valuable than which languages you have been using for the past few years.
As a recently graduated CS student, I find this type of thinking to be incredibly infuriating at times. Companies only want to hire people with experience. Yet to gain this experience, I need a job. The circular logic goes round and round until you have a brain aneurism.
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.
"Now I'm seriously serious!" - Serious Sam
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.
Engineering is the art of compromise.
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.
A positive attitude may not solve all your problems, but it will annoy enough people to make it worth the effort.
There's no one programmer who does the work of ten other programmers. One uber-programmer does just as much work as one ordinary programmer. It's just that the results solve ten times as many problems. Programming is fundamentally a design problem. A great bridge designer doesn't do the work of ten lousy bridge designers; the great one designs one great bridge in the time it takes the ten lousy ones to design ten lousy bridges.
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.