An often overlooked option is to look for a great programmer who knows any other language well and is willing to learn your shop's pet language. Hire him, provide some learning room, and he'll be up to Level Competent in no time compared to the time you need to spend looking for "a great Volvo driver".
Couldn't agree with you more. I've never been a big fan of the "good programmers are rarer than unicorn's teeth" school of thought, since both developers and business folks have their own self serving reasons for believing it, and because it's just not true in my experience. More likely is that there may not be any good programmers available that fit the exact slot they're looking for. If they'd just give a programmer who's 85% of the way there a little time to come up to speed, they'd fill their chairs with competent programmers in a fraction of the time. But instead, they'd rather hold out for a genius with years of experience in their exact little universe - and in so doing, screw themselves out of the much-larger-than-they-think universe of good developers out there.
That is correct, but hiring staff and recruiters speak a different language. At least in my experience, I used to get phone calls that a so and so firm needs a Django developer. While I used Pylons and Python extensively, and probably could learn Django lingo on the job, they wouldn't hear of it. In retrospect we were both right.
I've seen companies that have tried this and failed miserably. While programming languages share a common basis there are significantly different paradigms between say Ruby, C++ and Perl. While a good programmer could probably pick up any of these languages it'll probably take them a few years before their productivity is at the same level as someone of the same ability who has experience in that language.
It's key that you do have people who are already good with the language on the team for them to learn from, but if that's in place, a genuinely good developer is going to be able to pick up on the new paradigm pretty easily.
A few months, agreed. This time drops with each successive language. In addition to learning the language, a developer must learn the ecosystem. Perl and CPAN, Ruby and rubygems, etc.
I'm not talking about learning the syntax of the language, but things like design patterns, maintainability and readability. You need to read a lot of code to understand what works well and doesn't and it's language specific.
Understanding the Ruby way of doing things is different from understanding Ruby. Understanding when to use meta-templates in C++ is something you only learn by reading a lot of templated code.
After a few months you'll probably have only worked on a single code base on a tiny part of a project. You've no-way of understanding the ramifications of your design decisions will have on the project in 2-3 years time. You need to see multiple projects go from design stage to long term maintenance to understand issues such as where bugs get introduced, how code decisions impact maintainability, etc.
That's what I'm talking about, too. Design patterns aren't that hard. Maintainability and readability are obvious, if you've got good examples to follow.
Sure, it may take a couple years for a developer who's absolutely stuck in the mud. But a good developer already knows multiple languages, already is familiar with multiple paradigms, and is capable of meta-cognition to recognize what the new patterns are, how they are useful, and apply them.
"Understanding the Ruby way of doing things is different from understanding Ruby. Understanding when to use meta-templates in C++ is something you only learn by reading a lot of templated code."
Very true - and that's why truly good programmers will promptly take it on themselves to read as much code in a given language as they can get their mits on after having learned it's basic concepts, syntax, and so on. Precisely because every language comes with a sizeable corpus of lore, best practice, idioms, and other such things that are the closest things programming has to an oral tradition.
I am not convinced this is a good point against hiring someone who lacks depth in your language. It assumes that people already on the team have the same ability as the potential hire. This does not reflect reality. Different people learn at different rates. I have seen new people pick things up very quickly and surpass those who have been programming in that specific language for years. I am one, myself, with my present job. It is true there is a ramp-up time, but it varies with the person.
For some people, different paradigms do not present challenges; they are just different approaches to the same problems. It might be easier for people who dabble around in multiple paradigms to adapt to the new language.
It probably depends on how far the language is from the developer's experience.
I can imagine it will take a developer only familiar with ruby, python & js quite a while to become productive in assembly language.
However, a good developer that knows e.g. python, php & c really well (moreso if he generally know *NIX really well) will probably not take an inordinate amount of time to become productive in perl.
Are there good programmers who aren't familiar with the standard paradigms?
I went out of my way to study functional, OO, logical and assembly programming just so I wouldn't be trapped in an imperative mindset.
And I don't really consider myself to be any too great, because I know that there's so much more to learn and I won't live long enough to learn all the things I want to.
That's also a great way to avoid stupid coworkers. If a company thinks you can't get up to speed on a new language quickly enough to be useful, it's probably because their current employees are incapable of doing so.
