Choosing a Programming Language: Recruitment

How do you choose the right language to use for your next project? Use the right tool for the job? Sure, but what does that mean? And how do I know what the right tool is? How do I get enough experience in a new language to know whether or not it is the right tool for the job?

Your choice of language will have several impacts on your project:

  • Finding & hiring new developers to join your team
  • Whether there is a thriving community: both for providing Q&A support and the maturity of libraries & frameworks to help you get more done
  • Training your existing team; discovering and learning new tools; as well as the possible motivation impact of using new technologies
  • Finally your choice of “the right tool for the job” will make the development effort easier or harder, both in the short-term and for long-term maintenance

This is the first article in a series on choosing the right language – we will start by addressing recruitment.

Recruitment

For many teams, recruiting new staff is the hardest problem they face. While choice of programming language has many obvious technical impacts on the development process, it also has a huge impact on your recruitment efforts. If your choice of language has the ability to make your hardest problem easier then it has to be considered.

Filtering

The truth is that most developers will naturally filter themselves by language, first and foremost. Most Java developers, when looking for jobs, will probably start by asking their Java developer friends and searching job sites for Java developer jobs. Recruiters naturally further this – they need a simple, keyword friendly way to try and match candidates to jobs, and filtering by language is an easy way to start.

Of course, this is completely unnecessary – most developers, if the right opportunity arose, would happily switch language. Most companies, given the right candidate, would be more than happy to hire someone without the requisite language background.

Yet almost every time I’ve been involved in recruitment we’ve always filtered candidates by language. No matter how much we say “we just want the best candidates”, we don’t want to take a risk hiring someone that needs a couple of months to get up to speed with our language.

My last job switch involved a change of language, the first time in 10 years I’ve changed language. Sure, it took me a month to become even competent in C#; and arguably three or four months to become productive. But of course it is possible, and yet it doesn’t seem to be that common.

This is purely anecdotal: I’d love to find a way to try and measure how often developers switch languages – just how common is it for companies to take on developers with zero commercial experience in their primary language? How could we measure this? Could we gather statistics from lots of companies on their recruitment process? Email me or post a comment below with your ideas.

Size of Talent Pool

Ultimately your choice of language has one main impact on recruitment: which language would make it easiest to find good developers? I think we can break this down into three factors:

  1. Overall number of developers using that language
  2. Competition for these developers from other companies
  3. The density of “good” developers within that pool

Total Number of Developers

Some languages have many more developers using them than others. For example, there are many times more Java developers than there are Smalltalk developers. At a simple level, by looking for Java developers I will be looking for developers from a much larger pool than if I search for Smalltalk developers. But how we can we quantify this?

We can estimate the number of developers skilled in or actively using a particular language by approximating the size of the community around that language. Languages with large communities indicate more developers using and discussing them. But how can we measure the size of the community?

GitHub and StackOverflow are two large community sites – representing open source code created by the community and questions asked by the community. Interestingly they seem to have a strong correlation – languages with lots of questions asked on StackOverflow have lots of code published on GitHub. I’m certainly not the first to spot this, I found a good post from Drew & John from a couple of years back looking at the correlation: http://www.dataists.com/2010/12/ranking-the-popularity-of-programming-langauges/

GitHub & StackOverflow probably give a good indication of the size of the community around each language. This means if we look for C# developers, there are many times more developers to choose from than if we choose Ada. However, sheer numbers isn’t the full story…

Competition for Developers

We’re not hiring in a vacuum – there is competition for developers from all the other companies hiring in our area (and those remote companies that don’t believe geography should be a barrier). This competition will have two impacts: first if there is more competition for developers using a certain language, that makes it harder to attract them to our company. Assuming market forces work, it also suggests that average salaries for developers with experience in an in-demand language will naturally be higher – as companies use salary to differentiate themselves from the competition. Just because there are more C# developers than Ada developers, the ease with which you can hire developers from either group is partly dependent on the amount of competition.

so-questions-adsI looked at the total number of questions tagged on StackOverflow.com and the number of UK job ads requiring the language on JobServe.com. Interestingly there is a very strong correlation (0.9) – this suggests, perhaps not surprisingly, that most developers primarily use the language they use in their day job: there are large communities around languages that lots of companies hire for; and only small communities around languages that few companies hire for. Of course – it’s not clear which comes first, do companies adopt a language because it has a large community, or does a large community emerge because lots of developers are using it in their job?

There are some interesting outliers: there seems to be greater job demand than there is developer supply for some languages such as Perl and VisualBasic. Does this suggest these are languages that have fallen out of favour, that companies still have investment in and now find it hard to recruit for? Similarly Scala and Node.js seem to have more demand than developers can supply. On the other side of the line, languages such as PHP and Ruby have much more active communities than there is job demand – suggesting they are more hobbyist languages, languages amateurs and professionals alike use in their spare-time. Then there is Haskell, another language with a lot of questions and not many jobs – perhaps this is purely its prevalence in academia that hasn’t (yet) translated to commercial success?

In general the more popular languages have more competition for developers. Perl & VisualBasic will be harder to find developers skilled in; whereas PHP, Ruby & Haskell should be easier to find developers. Besides these outliers, whichever language you hire for the overall size of the pool of developers (i.e. those within commuting distance or willing to relocate) is the only deciding factor. How many companies continue to use the mainstream languages (Java and C#) because its “easier” to hire developers? On the basis of this evidence, I don’t think its true. In fact, quite the opposite: to get the least competition for developers (lower salaries and less time spent interviewing) you should hire developers with Ruby or Haskell experience.

Density of Good Developers

One of the more contentious ideas is that filtering developers by language allows you to quickly filter out less capable developers. For example, by only looking at Python developers, maybe on average they are “better” than C# developers. My doubt with this is if it were found to be true, developers would quickly learn that language so as to increase their chances of getting a job: quickly eliminating any benefit of using language as a filter. It also starts to sound a bit “my language is better than your language”.

But it would be interesting if it were true, if we could use language as a quick filter to get higher quality candidates; it would be quite possible to gather data on this. For example, I use an online interview that could easily be used to provide an A/B test of developers self-selecting based on language. Given the same, standardized recruitment test – do developers using language A do better or worse than those using language B? Of course, the correlation between a recruitment test and on the job performance is very much debatable – but it could give us a good indication of whether there is correlation between language and (some measure of) technical ability. Would this work, is there a better way to measure it? Email me or post a comment below.

Conclusion

Popular languages have more developers to hire from but more companies trying to hire them. These two factors seem to cancel each other out – the ratio of developers:jobs is pretty much constant. As far as recruitment is concerned then, maybe for your next project break away from the norm and use a non-mainstream language? Is it time to hire you some Haskell?

Advertisements

Choosing a Programming Language

What programming language to use is probably the single biggest technical decision facing a project. That one decision, affects every one that follows – from the frameworks and libraries you can use, to the people you hire. So how do you go about choosing what programming language to use?

The truth is, you probably do what most people do and use the same language you used on your last project. Or, if you’re a hipster, you use the latest super cool language. A couple of years ago all the cool kids were on rails. Now the hipsters are trying to tell me how awesome their nodes are. Or that clojures are where its at. Last time I checked, their turing complete language had the same problem solving capacity as my turing complete language. Really what they’re arguing is their language gives them better expressive power: it’s faster to write and/or cheaper to maintain.

Right tool, right job

As the old adage goes: always use the right tool for the job. If you need to automate some command line maintenance task – use a language that’s good at shell scripting: bash, perl, hell even ruby; don’t use Java. If the problem you’re solving needs a desktop client that integrates seamlessly in a Windows environment: use C#, don’t use Java (be quiet Java on the desktop fanboys, just be quiet). If the problem you’re solving involves handling lots of XML and you like stack traces: sure, use Java.

The biggest distinction normally comes down to algorithmic complexity. If what you’re working on has a lot of algorithmic complexity, use something that’s good at expressing it: a functional language, like haskell or F#. Or if, like 90% of webapps, what you’re doing is data in, data out you need a language with good OO power to try and model your domain: Java and C# are both good choices here, along with almost every other modern language out there.

Scala

Or maybe you really hate yourself and you want a compromise: why choose functional or procedural when you can have both? Why miss out on every language feature thought of over the last 50 years when you can have them all, baked into one mess of a language? Yes, if that sounds like you, you probably think you’re a hipster but you actually missed the boat by several years: its time to learn you some scalas.

I suspect part of the reason Scala is gaining so much popularity is that it finally gives all the frustrated Java devs the language toys they’ve always wanted. Java really is an unbelievably retarded language now, it’s incredibly frustrating to work in. As someone that’s just switched to C#, I’ve relished all the new language gadgets and geegaws I’ve got to play with. Have they made the code any better? With lots of toys comes lots of complexity and variety, making code hard to understand and hard to maintain.

The thing is, Java is a toy language: any idiot can write decent idiomatic Java. The trouble is, Java is a toy language: everyone is forced to write screeds of noddy idiomatic, idiotic Java, no matter how much of a ninja rockstar they are. The best thing with Java, is it stops all the ninja rockstars from showing how ninja they are by writing undecipherable crap. I fear the impact lambdas will have on the maintainability of the average Java codebase as everyone starts finding new and confusing ways to express everything.

Hiring

Another reason to choose the right programming language, is it affects the developers you can hire. But does it really? I work in a C# shop now, do I turn down Java developers? Hell no. A good developer is a good developer, regardless of the language. To dismiss potential recruits because of the language they know is retarded.

And the trouble is, if you think that hiring only python or node developers will get you a better standard of developer: you’re wrong. The pool will simply be much smaller. Maybe the average quality of that pool will be higher, who knows, who cares? I only need one developer, I want her to be the best I can hire – it makes no difference where the average is.

Language has no correlation with ability: I’ve met some very smart Java developers, and some truly terrible hipster developers. I’d rather cast the widest possible net and hire good developers who are happy to use the technologies we use. To do anything else is to limit the pool of talent I can draw from; which, lets be honest, is pretty limited already.

Another argument I’ve heard is that the technologies you use will limit candidates willing to work for you – some developers only want to work in, say, clojure. Well, they’re retarded then. I’d rather have people who want to work on interesting problems, regardless of the language, than people who would rather solve shit problems in the latest hipster language. Now if you work for a bank, and all you have are shit problems? Sure, go ahead and use a hipster language if it helps you hire your quota of morons. If nothing else it keeps them away from me.

Lingua Franca

Take a room full of hipster language programmers and ask them to form teams. What happens? Magically, you’ve now got a room full of C# and Java developers. Almost every developer will know at least one of these two languages – they are the lingua franca. Everything else is frankly varying degrees of hipster.

The truth is the most important thing when choosing a language is how many developers on your team, and those you plan on hiring, already know the language. If everyone on the team has to retrain into say, smalltalk; and everyone you hire needs hand holding while they learn the new language – that’s a cost you have to factor in. What’s the benefit you’re getting from it?

Secondly, how easy is it to get support when you hit problems? The open source community around Java is awesome – if you’ve got a problem, there will already be 15 different solutions, some of which even work. If you work in C#, your choices are more limited – but there will be choices, some of which aren’t even from Microsoft. If you’re working in the latest hipster language, guess what? You’re on your own. For some people that’s the draw of hipster languages. For those of us wanting to get work done, it’s just a pain.

In the end, the best advice is probably to use the same language you used on your last project: everybody already knows it and your tooling is already setup around it. This is why Java has quickly become the new cobol.

Software craftsmanship roundtable

Last night was the second London Software Craftsmanship round table. This was a great session with lots of lively discussion. We seemed to cover a wide variety of topics and I came away with loads of things I need to follow up on.

It’s amazing, as soon as you start discussing things with other developers you pick up on lots of different ideas, tools and technologies you’d not previously explored. These sessions are proving to be a great way to find out some of the cool stuff people are doing. So what did we discuss?

*phew* I think that covers it. If I missed anything, let me know below.

So, are you coming to the next one? What should we discuss?