5 ms·

My team has been using Clojure for the past 6 years, and we have the opposite experience. Most new developers we've hired haven't used Clojure before, but they

by yogthos 10y ago

My team has been using Clojure for the past 6 years, and we have the opposite experience. Most new developers we've hired haven't used Clojure before, but they were able to become productive doing useful work within weeks. The fact that we're using Clojure tends to be a positive factor for attracting candidates as well. A number of candidates we've interviewed mentioned that Clojure was the reason they applied for the job. They heard about the language and they were interested in trying to work with it professionally. In addition, we hired contractors and co-op students to work with our team, and they were able to pickup Clojure as well. At this point I would actually use Clojure as a filter. I'm rather suspicious of any developer who wouldn't be able to learn Clojure.

felideon 10y ago
Where are you located? It's hard to find people (a) willing to make the jump and (b) making the jump effectively. And when you do, you can maybe tap into x number of devs for your team, but trying grow to 2x devs is much harder.
- yogthos 10y ago
  I'm located in Canada, and work at a research hospital in Toronto. We have a number of companies using Clojure in town, and run a meetup. As part of the meetup we're also running a Clojure workshop, so that helps a lot. I also found that hiring students for junior positions from university works great as well. They don't have preconceptions about how to do development, and usually have easier time picking up new paradigms than devs who've been working in a particular one for a long time.
dominotw 10y ago
curious, how big is your team size? >but they were able to become productive doing useful work within weeks. Sure anyone can learn clojure syntax in a day and write imperative code in it. But not sure if everyone can throw out their thought patterns from decades of OO and learn an entirely new paradigm of thinking about code. One of the issue we had was precisely this, people who were just starting to write clojure were writing code that looked and felt totally different from people who have been doing it for years. Imagine paying this huge cost for every new dev in a large org.
- yogthos 10y ago
  My overall team is about 30 devs, and we're broken up into teams of 3-5 devs. My immediate team consists of 5 developers. >Sure anyone can learn clojure syntax in a day and write imperative code in it. But not sure if everyone can throw out their thought patterns from decades of OO and learn an entirely new paradigm of thinking about code. We don't have to hire everyone though. We just need to find one person who fits the team. A lot of developers nowadays are already familiar with functional patterns, so it's actually not that challenging to start doing stuff in Clojure. We also do code reviews and pair up as needed. Developers are a long term investment, so spending a bit of extra time to get somebody onboarded is well worth the effort in my opinion. We're using jira/bitbucket internally. Our process is that everybody works on branches, and when you finish a feature you tag somebody for a code review. We found that this helped us catch any non-idiomatic code fairly quickly.
Jach 10y ago
How do you convince management to treat getting up to speed with a programming language (and your group's particular usage of it) as just another cost of onboarding? Or even better, how do you make the case to whoever is in charge of hiring that they shouldn't bias prior experience to the company's language over newcomers too highly when adequate proficiency is only a matter of a few weeks. All else being equal I think most hiring managers would naturally take the dev who already knows the language, but if it doesn't take long to learn the language up to the company's standards then it's not all else equal, all is effectively equal and another metric is needed.
- yogthos 10y ago
  I guess I'm just lucky to work at a place where technical people make technical decisions. The management does not decide what languages are used or how developers are onboarded where I work.

by yogthos 10y ago

felideon 10y ago

Where are you located? It's hard to find people (a) willing to make the jump and (b) making the jump effectively. And when you do, you can maybe tap into x number of devs for your team, but trying grow to 2x devs is much harder.

yogthos 10y ago
I'm located in Canada, and work at a research hospital in Toronto. We have a number of companies using Clojure in town, and run a meetup. As part of the meetup we're also running a Clojure workshop, so that helps a lot. I also found that hiring students for junior positions from university works great as well. They don't have preconceptions about how to do development, and usually have easier time picking up new paradigms than devs who've been working in a particular one for a long time.

dominotw 10y ago

curious, how big is your team size? >but they were able to become productive doing useful work within weeks. Sure anyone can learn clojure syntax in a day and write imperative code in it. But not sure if everyone can throw out their thought patterns from decades of OO and learn an entirely new paradigm of thinking about code. One of the issue we had was precisely this, people who were just starting to write clojure were writing code that looked and felt totally different from people who have been doing it for years. Imagine paying this huge cost for every new dev in a large org.

yogthos 10y ago
My overall team is about 30 devs, and we're broken up into teams of 3-5 devs. My immediate team consists of 5 developers. >Sure anyone can learn clojure syntax in a day and write imperative code in it. But not sure if everyone can throw out their thought patterns from decades of OO and learn an entirely new paradigm of thinking about code. We don't have to hire everyone though. We just need to find one person who fits the team. A lot of developers nowadays are already familiar with functional patterns, so it's actually not that challenging to start doing stuff in Clojure. We also do code reviews and pair up as needed. Developers are a long term investment, so spending a bit of extra time to get somebody onboarded is well worth the effort in my opinion. We're using jira/bitbucket internally. Our process is that everybody works on branches, and when you finish a feature you tag somebody for a code review. We found that this helped us catch any non-idiomatic code fairly quickly.

Jach 10y ago

How do you convince management to treat getting up to speed with a programming language (and your group's particular usage of it) as just another cost of onboarding? Or even better, how do you make the case to whoever is in charge of hiring that they shouldn't bias prior experience to the company's language over newcomers too highly when adequate proficiency is only a matter of a few weeks. All else being equal I think most hiring managers would naturally take the dev who already knows the language, but if it doesn't take long to learn the language up to the company's standards then it's not all else equal, all is effectively equal and another metric is needed.

yogthos 10y ago
I guess I'm just lucky to work at a place where technical people make technical decisions. The management does not decide what languages are used or how developers are onboarded where I work.