Recruiting Software Developers: Language Matters
When I first proposed that we start doing all of our new development at Democracy Works in Clojure instead of Ruby, one of the first concerns brought up by my colleagues was developer recruitment. The assumption–which I agreed with at the time–was that pulling from a much smaller pool of talent would hamper our ability to find people with experience in our language-of-choice (let’s leave aside for now the debate over whether that should be a priority in the first place). It was probably the biggest concern we had with moving to the new language.
Then a funny thing happened1. As soon as we became “a Clojure shop,” smart, experienced developers wanted to work with us. Rather than being yet-another-Rails-shop and having to convince highly-sought-after Ruby developers why they should work here instead of there, we were one of the few places offering developers who had discovered this new, better way a chance to use those sharper tools to build real software used by real people (and get paid to do it).
This surprised me as much as anyone else, but it makes perfect sense in retrospect. Good developers are always driven to further their skills, and as a result are nearly always aware of more innovations in software development than they get to use in their day jobs. Clojure is one such innovation, but that’s a topic for another blog post (or 12).
Moving from Ruby to Clojure moved Democracy Works towards the kind of developers we wanted to hire (regardless of what language we were using), and it was a less crowded space so more of them noticed.
Far from being a challenge we had to work to overcome, our move from Ruby to Clojure has been hugely beneficial to our developer recruitment–both in terms of quantity and quality.
-
Quite literally: We found one of our developers because he overheard someone at a farewell party for our summer interns say that we were moving to Clojure and Datomic. Also, we talk about Clojure and Datomic at parties. ↩