Good Programmers Can Adapt to Any Language
For a very long time, I have thought that the best way to hire programmers is to ignore the languages that they know because languages are ephemeral. They come and go. It's not hard to learn the language. If you've got a project and it happens to be in Elixr - you don't need to go out and hire an Elixr programmer.
The time it takes to pick up a language is very short compared to the time it takes to master programming itself. - Uncle Bob Martin, the Clean Coder speaking on the alphalist CTO podcast Episode #58
You need to go out and hire programmers - good programmers - and then they can pick up any language at all. The time it takes to pick up a language is very short compared to the time it takes to master programming itself. It’s always a mistake, in my opinion, to go out hunting for the programmer, that know e.g. Java - that's just dumb. Find programmers who know how to write code in any language and hire them. After all, your ideal hires believe:
Software is not a 9-5 coding job. You don't just do it to earn your paycheck. You are counted on to uphold a certain level of ethics and morals and standards and disciplines. _ - Uncle Bob Martin, the Clean Coder speaking on the alphalist CTO podcast Episode #58_
Hire Broad-minded Devs- Not Ones Boxed Into a Specific Language
You might be looking for a Ruby specialist but you don’t want to attract people who are only interested in particular languages. Because that person’s narrow focus will hinder their growth.
Do you want to attract people who are only interested in particular languages? That person's got a problem - that person's got narrow focus. - Uncle Bob Martin, the Clean Coder speaking on the alphalist CTO podcast Episode #58
The best programmers are broad-minded - open to exploring other languages if the solution requires it. An ideal hire would be able to say ‘Ruby? I know Ruby. Ruby is great. These are the pros and cons of using Ruby. I have never used Ruby before but it looks like a good fit here so I will learn it.’ This attitude would apply to all languages you throw at them - be it C or Java or Closure etc.
It is probably a mistake for a programmer or an employer to get hung up on the languages.- Uncle Bob Martin, the Clean Coder speaking on the alphalist CTO podcast Episode #58
Encourage Knowledge Sharing Among Devs
You need to encourage knowledge sharing among employees, especially through pair programming and mob programming. Instead of just having one Elixr programmer, you will have N Elixr programmers since everybody who worked with the original guy who knew Elixir will now know it. Therefore you will have continuation if that one original Elixr coder leaves the company.
“One of the ways to run a successful software team is to make sure that the software developers do not isolate themselves in funny little silos. e.g. “I'm the Elixr programmer. I touch all the Elixr code. I don't touch any of that other Go or horrible code that everybody else works on.” That's a very unhealthy attitude…. If you're creating a team that incentivizes that kind of specialization and does not focus on the sharing of information between the members of the team, you're headed for trouble, you're headed for that last Elixr guy to leave.- Uncle Bob Martin, the Clean Coder speaking on the alphalist CTO podcast Episode #58
Everybody on the team should have a nice broad experience. They should be able to touch the Elixr parts. They should be able to touch the Closure parts. Maybe they should even be able to do a little Assembly language. I also don't want people focusing on particular avenues. I don't want the GUI guys. I don't want the database guys. I don't want the middleware guys. And it's okay if you know the GUI better than the middleware, but you should know the middleware too. It's okay if you're a really good database guru, that's fine, but you should know how to do a little GUI work too. And it's fine if you're a Java programmer, but you ought to be able to do a little Ruby. We don't want to be narrow specialists. And if you are creating a team that incentivizes that kind of specialization and does not focus on the sharing of information between the members of the team - you're headed for trouble, you're headed for that last Elixr guy to leave.
In Conclusion Languages are great but they shouldn’t take the focus away from actual software craftsmanship. Languages are just tools at the end of the day and a good programmer is equipped to pick up any of them and use them to build great things. If you focus on just a language specialist AKA snob, you might not only lose out on great talent but you will also be limited by their narrow perspective. Furthermore, you need to make sure language knowledge spreads throughout the organization and every programmer on your team can recognize parts that are just beyond their specialty.
