Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Programming IT Technology

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"
This discussion has been archived. No new comments can be posted.

Hiring Programmers and The High Cost of Low Quality

Comments Filter:
  • by COMON$ ( 806135 ) * on Monday August 06, 2007 @05:45PM (#20135007) Journal
    While I am not a dev, Sysadmin here, this is probably the best article I have read on the subject in a long time. This idea of lets get someone in and train them up is assinine. Of course not every company can afford 120K a year but what about the lower end, midwest people get hit up with 45K a year jobs all the time, if the company would jump to 60-70K they would get 2X the dev and also get a much better product. I am currently with a company that made the mistake of hiring a below par employee to dev a site. Now they lucked out and got someone for the same price who doesnt care about salary but it a hell of a PHP developer, probably the best I have ever worked with. He spends 90% of his time fixing mistakes of the last dev and does things in minutes that took his predecessor days.

    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?

  • by COMON$ ( 806135 ) * on Monday August 06, 2007 @05:51PM (#20135075) Journal
    Sorry that is not the way the world works, at least not the commerce society. You get paid a general permium about what they mentioned, the real premium is beign so good at your job that you have no fear anymore. Getting fired is a perk meaning you get signing bonuses for your next job. Choosing your office to working is a perk as well, while at the lower end you spend your time just trying to be employed.

    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.

  • Re:Sigh. (Score:1, Informative)

    by Anonymous Coward on Monday August 06, 2007 @05:55PM (#20135123)
    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.
  • ...Java? (Score:3, Informative)

    by SanityInAnarchy ( 655584 ) <> on Monday August 06, 2007 @08:52PM (#20136885) Journal

    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.

    It makes great programmers produce merely adequate code, makes good programmers produce bad code, and makes bad programmers think they're great.

    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...

  • Re:Sigh. (Score:5, Informative)

    by Baddas ( 243852 ) on Monday August 06, 2007 @09:03PM (#20136967) Homepage

    I would say an expert can at times generate up to 3 times a much output, but 10 times is ludicrous.

    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'
  • by networkBoy ( 774728 ) on Monday August 06, 2007 @10:55PM (#20137881) Journal
    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.
  • Re:Yeah, right (Score:1, Informative)

    by Anonymous Coward on Tuesday August 07, 2007 @05:08AM (#20139555)
    ...which means that Perl doesn't lend itself to software projects of the scope that require teams. IE, most of them.
  • Re:Sigh. (Score:3, Informative)

    by Baddas ( 243852 ) on Tuesday August 07, 2007 @10:44AM (#20141879) Homepage
    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.

Loose bits sink chips.