No, what I’m saying is more along the lines of Kevin Barnes’ latest article.
Ah. Well, I'm not sure how I was supposed to intuit that from the single question, "Et tu, sauoq?" I guess I'll have to try harder next time... ;-)
Thanks for the link. It was a semi-interesting blog post in a blah-blah-blah plus a dash of common sense sort of way. I enjoyed it.
I don’t believe you should hire a “Perl programmer” or a “PHP programmer,” specifically.
Would you feel more comfortable with my phrasing if I changed it to "programmer with Perl experience" and "programmer with PHP experience"? Or are you really suggesting that you shouldn't hire someone with a particular skillset or experience in the technology you are using? Specifically? Because that just doesn't sound right to me, truth be told. And I don't think that's anything close to what Mr. Barnes was saying. The reality is that, if I'm going to hire someone to work on a project, I'm going to prefer someone who is already familiar with the technology and the problem domain. Other things being equal, of course. I simply want to minimize how much I'm paying for their learning curve(s).
-sauoq
"My two cents aren't worth a dime.";
| [reply] |
But if the system you’ve built is of any complexity, you’ll inevitably pay for the learning curve that actually matters: absorbing the system’s architecture. Compared to it, the time it takes an experienced programmer to get up to speed with a new language isn’t very significant. (Admittedly, this thread is about a pretty simple system; though who knows where scope creep might take it (see my signature).)
Hiring a “PHP programmer” is mostly a way for a non-programming manager to find someone vaguely fitting, because he can’t effectively evaluate a programmer’s skills on much more than prior experience with particular technologies. But such a manager is in for a rough ride at the best of times, anyway.
I suppose “programmer with $FOO experience” makes it more palatable; but the core point remains the same.
Makeshifts last the longest.
| [reply] |
But if the system you’ve built is of any complexity, you’ll inevitably pay for the learning curve that actually matters: absorbing the system’s architecture.
You will always have that cost... why pay for both?
It seems your points are predicated on the assumption that you must... but, the truth is that developers aren't actually that scarce these days (though we may wish we were.)
-sauoq
"My two cents aren't worth a dime.";
| [reply] |
