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"
Same concept goes with my job field, I spend a considerable amount of time consulting, fixing poorly configured networks and servers. You cant just grab a joe off the street and expect him to be a professional or put out professional work without having learned his/her lessons, they will make mistakes learning, do you want it to be on your buck and your network?
CS: It is all sink or swim...oh and did I mention there are sharks in that water?
Uber programers do exist, and yes they are paid very well, but it would be an HR nightmare to prove that Johnny X does the work of 10 people so he should be paid what 10 people are, thus the reason it is not done.
CS: It is all sink or swim...oh and did I mention there are sharks in that water?
However, specializing to such great extent means that you will become virtually unemployable outside of your present position. Generalists here have an advantage of having a lot more opportunities that fit their resume. Which means that once e.g. corporate culture at the present employer changes to the worse, they can easily get another job.
Besides, you'd want to specialize in your employer's business or a blend of business and technology rather than the technology itself for obvious reasons. That just might not be your cup of tea.
You blast Perl, and then go on to suggest Java, of all things?
The reason there is bad code in Perl is, it doesn't actually "force" you to do anything. There are so many ways to do it that it's very easy to write crap -- but it's also very easy to write good stuff.
That works even better if you apply it to Java.
Java has things like static type checking -- to the point where you must explicitly declare what exceptions you might run into. Before templates, I was actually forced to typecast to and from Object...
This is flatly retarded, by the way -- if Java can give me a compile-time error that my method didn't declare a particular exception, why can't I simply omit all such declarations and let the compiler add them back in?
But then, managers like to see Java as a good thing precisely because it's so limiting. It forces everything to some level of mediocrity and sameness, meaning horrible programmers are just slightly bad because Java keeps them from shooting themselves in the foot. It also means you can hire a team of horrible programmers, and replace any one of them with another at any time, and the project will continue moving forward. And it's great for programmers, because they can look busy all day writing interfaces, typing ridiculously long method declarations, and dealing with the complexities and limitations of things like single inheritance, without having to get much actual work done (or do much thinking).
But what people are finding out is, flexibility like Perl's is really useful. Look at Ruby. The syntax looks OK on the surface, but get into even marginally complex programs and it can look as ugly as Perl. But it's also amazingly flexible, quick to code in, and makes a bright programmer into a brilliant programmer -- whereas Java will take your bright programmers and beat them down into codemonkeys.
You can point to all the Java in the world, but when Ruby runs probably 10 or 100 times as slow as Java, and people STILL use it to run websites, and simply buy more hardware? I'd say that proves we have some damned good languages. Obviously better than Java -- pick any site that's written in Perl or Ruby (even Python), and not Java, and ask yourself why.
Now, PHP is an horrifically bad language...
Don't thank God, thank a doctor!
Heh, quantity is not quality. Do you have any metrics? DeMarco and Lister do, and their data seems to show 10x. As in, not 'more code' but 'better code, fewer bugs, faster execution'
If you consider his knowledge of the NT4 kernel that no one on our team had as mediocre then sure.
If you consider that his documentation was approaching 4:1 against lines of code then sure.
If you consider that even with the 1:1 coaching that he gave our resident programmers they could barely keep up then sure.
And finally...
If you consider that we bid this to MS and they conceded that it was a touchy application that required a team of at least three programmers, then sure he was a mediocre programmer.
More likely he was light years ahead of anyone else we employed. I read his code and I fully understood the principle of the operation (with the help of the comments), but my capability of the execution would have been grossly lacking.
Seeing as you're an AC I likely wasted my time on a troll, but whatever.
-nB
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
...which means that Perl doesn't lend itself to software projects of the scope that require teams. IE, most of them.
According to them, both. It's useless to hire good people if you don't give them good space, and vice versa, though even poor performers do relatively better in good space.