5 ms·

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, prov

by Deestan 16y ago

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

wildmXranat 16y ago
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.
ig1 16y ago
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.
- humblepatience 16y ago
  I agree, but its more because of the frameworks and libraries than the language
- lukev 16y ago
  A few years? Strongly disagree. Months, tops. 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.
  - LiveTheDream 16y ago
    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.
  - ig1 16y ago
    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.
    - grammaton 16y ago
      "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.
    - lukev 16y ago
      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.
- Xurinos 16y ago
  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.
  - chromatic 16y ago
    It assumes that people already on the team have the same ability as the potential hire. The people on the team have a great advantage over a new hire: they know more about the business and the codebase.
- ido 16y ago
  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.
- Natsu 16y ago
  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.
yummyfajitas 16y ago
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. You don't want this job - just move on.
humblepatience 16y ago
The one issue that I have with this, is that it very much depends on what you do at your particular shop. Mainly, we use rails and it takes a while to learn all the individual parts of rails - it's just just a different way of writing the same code snippet, like changing languages, but an entirely different way of doing web development (MVC, Rest, Activerecord, Activeresource, Erb, Migrations, Testing) than .NET or PHP often is. So it's a lot easier to switch languages than to switch frameworks and open source communities (we use lots of community contributed gems in addition to rails) It took me about 6 months fulltime to get comfortable, and it would probably take a less enthusiastic developer longer.
grammaton 16y ago
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.

by Deestan 16y ago

wildmXranat 16y ago

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.

ig1 16y ago

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.

humblepatience 16y ago
I agree, but its more because of the frameworks and libraries than the language
lukev 16y ago
A few years? Strongly disagree. Months, tops. 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.
- LiveTheDream 16y ago
  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.
- ig1 16y ago
  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.
  - grammaton 16y ago
    "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.
  - lukev 16y ago
    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.
Xurinos 16y ago
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.
- chromatic 16y ago
  It assumes that people already on the team have the same ability as the potential hire. The people on the team have a great advantage over a new hire: they know more about the business and the codebase.
ido 16y ago
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.
Natsu 16y ago
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.

yummyfajitas 16y ago

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. You don't want this job - just move on.

humblepatience 16y ago

The one issue that I have with this, is that it very much depends on what you do at your particular shop. Mainly, we use rails and it takes a while to learn all the individual parts of rails - it's just just a different way of writing the same code snippet, like changing languages, but an entirely different way of doing web development (MVC, Rest, Activerecord, Activeresource, Erb, Migrations, Testing) than .NET or PHP often is. So it's a lot easier to switch languages than to switch frameworks and open source communities (we use lots of community contributed gems in addition to rails) It took me about 6 months fulltime to get comfortable, and it would probably take a less enthusiastic developer longer.

grammaton 16y ago

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.