“Which language should I learn?” — answering with real market data
If the rise of national movements like Code.org, CodeSpark, and the TechHire Initiative are any indication, there’s a strong push in America to get more and more people into programming.
It’s still too early to gauge the success of these programs. But one thing is certain: it will result in more people asking, “Which language should I learn?”
I’m sure every developer has heard this question. Cousin Sally hears about the nice perks at your job, so she decides to look up how to be a programmer like you. Once she starts researching, she finds out there are about 50 different languages to learn and doesn’t know which one to pick.
Let’s face it: we don’t have a good way to help her decide. Many of us have strong opinions in favor of the languages we currently use, and these opinions are usually based on technical characteristics that have no meaning to non-developers.
Example: Cousin Sally asks me, “Which language should I learn?” Knowing that I’m biased towards Ruby, I now attempt to be as objective as possible. “Well, it depends. Do you want an object-oriented language or functional?” Seeing her blank stare, I try another angle: “Do you want a good language for fast prototyping? Or maybe something with some type safety?” Sally’s still scratching her head.
Sally is not going to care about cross-compilation, static typing, or programming paradigms. All she cares about is getting a nice job with good pay.
This has inspired me to develop a new measure for programming languages like the TIOBE index or TechEndeavor benchmarks. Unlike any existing measure, it’s based entirely on economics, from the perspective of a job seeker.
Introducing the job-dollar
This is actually a challenging problem. You have to take into account the total number of jobs in the market, the number of other job seekers competing for those jobs, and the average salary they’ll expect to receive, all in a semi-realistic way.
I’ve encapsulated all of this in a measure I call the job-dollar. A job dollar is an objective measure of the strength of the job market for entry-level workers using a given programming language and framework. It is a measure of work, like kilowatt-hours, and it measures how much work the market has done for you.
Since job-dollars are a comparative measure, it’s important to make sure we’re comparing apples to apples. For example, it’s not quite fair to compare the search results for “Java” with the results for “Ruby on Rails,” because “Java” would match jobs over a range of different platforms and frameworks, unlike “Ruby on Rails” which would only match one platform and one framework.
So what should we search for — just the language, or language/framework pairs? Getting hired is all about proving you can be productive from day one. That means a beginner should have some familiarity with the frameworks and application platforms out in the real world. So my data looks at language/framework pairs.
The dollar value of a resume item
I found it helpful to solve a simpler, more general problem first: how much is a single item on my resume worth? In other words, if I have 2 years of experience in Node.js on my resume, how much is that worth to me in real dollars?
We can arrive at an estimate by taking the chance I’ll get a job and multiplying it by the average salary:
dollars = (chance * avg_salary)
To find the chance of a person getting a job, we could just take the total number of jobs and divide it by the number of resumes. So if there are 5 jobs and 10 resumes, the chance of each person getting a job would be 0.5, or 50%.
dollars = ((jobs / resumes) * avg_salary)
We still need to consider a person’s level of experience. If someone has 5 years of experience, don’t they have a better chance of getting a job than someone with only 1? Let’s change our formula to apply a strength level to our candidate based on their years of experience, placing a fictional ceiling at 10 years of experience:
dollars = ((years_exp / 10) * (jobs / resumes) * avg_salary)
This is pretty much the most simplistic model possible.
Because we are answering this question for non-developers, we are looking at a very specific edge case: the dollar value of a resume item with zero years of experience. This presents a problem:
dollars = ((0 / 10) * (jobs / resumes) * avg_salary)
Our simplistic model is a bit too simplistic — because of that zero, the result will come out to $0.00 every time.
A better chance estimate
No one would think that a person with zero years of experience has 0% chance of getting a job. If that were true, no one would have jobs! Everyone starts somewhere. We need a better model, where your chance at year zero is not zero.
We can and should draw inspiration from real life. Let’s think about the interview process. Companies do not consider every resume on the internet when hiring. They filter these resumes down to just a handful, using some imperfect process, and then pick the best candidate from that handful. In this model, a candidate at year zero has a nonzero chance of getting the job if theirs was the only resume considered.
Example: I am at year zero, and the jobs I am applying to will select either 1 or 2 resumes to look at. If they select 1 resume, I have a 100% chance. If they select 2 resumes, my chance is 0%. So all told, I have a 50% chance on average of getting the job.
This comes out to look like this:
The full formula in pseudo-math-notation:
chance = avg(1..max_resumes as resumes -> {strength ^ (resumes-1)})In English: take the candidate’s resume strength to the power of the number of other resumes selected, for every possible number of resumes, and average them together.
I used this strategy in my Ruby estimator, but I refined the model slightly to make it more realistic. You no longer have an equal chance of being compared with zero, 1, or 2 other resumes, but instead, the probabilities approximate a normal distribution.
Word problems
Let’s do some basic examples.
1. I’m a Scala developer who’s the best in the world. I have a 100% chance of getting any job I apply for, and Scala jobs, on average, pay $10. So my Scala experience is worth $10.
2. I’m just getting into Android, and I have very little experience, so I have a 10% chance of getting a job. Android jobs, unfortunately, pay $1. 10% of $1 is 10 cents. So my Android experience is worth 10 cents.
We’ll come back to these examples later, once we discuss job-dollars.
Arriving at job-dollars
But let’s back up for a little bit. We have a pretty good idea of the dollar value of a resume item, so isn’t this enough? Why do we have to move to a new measurement called the “job-dollar”?
It’s a simple fact that when you’re looking for a job, there are a lot of factors to consider besides salary that can’t be quantified. Not every job is going to be located in an area where you want to live or working on an interesting product. As a job seeker, you always want options. We have to consider salary together with the total number of job options, like so:
jobDollars = jobs * dollars
Now, let’s look at our two fictional developers again.
1. Our Scala developer’s experience was valued at $10. But say there are only 10 jobs. So the amount of work the job market is does for this developer is $100 job-dollars.
2. Our Android developer’s experience was valued much lower, at 10 cents, but let’s say that there are 1,000 Android jobs. Ten cents times 1,000 jobs equals $100 job-dollars, so the two come out equal after all.
With job-dollars, we are getting closer to a proper basis for comparing the job markets attached to different technologies. The only problem is that job-dollars are theoretical. There’s no reality to them. We need to anchor this into something we can easily understand.
Introducing the Javagrad unit
As a baseline unit of job-dollars, allow me to introduce what I call the Javagrad. One Javagrad is equal to the amount of work the current job market does for one computer science student fresh out of college using Java Swing, looking for an entry-level job.
This makes sense to me as a baseline unit. You would expect a recent college grad to be well-equipped to enter the working world, though slightly behind the times. I don’t actually know if they’re still teaching Java Swing. If not, then it’s a good measure of how far we’ve come since I was in school, and if they are, then it’s a good reminder to update the curriculum!
In July 2016, one Javagrad is equal to about $4,324 job-dollars.
Give me the data!
Now that we have this measurement, there’s a lot of interesting observations we can make about the current job market for programmers. Let’s look at just a small sample of technologies:
Ruby/Rails = $62,625 job-dollars = 14.5 Javagrads
C#/.NET = $114,343 job-dollars = 26.4 Javagrads
Java/Android = $46,958 job-dollars = 10.9 Javagrads
Swift/iOS = $57,044 job-dollars = 13.2 Javagrads
Javascript/Angular = $100,014 job-dollars = 23.1 Javagrads
Javascript/JQuery = $94,997 job-dollars = 22.0 Javagrads
Javascript/React = $91,659 job-dollars = 21.2 Javagrads
Here we start to see the subtle interplay between the three factors (jobs, resumes, and pay):
- .NET is the strongest back-end framework because of the abundance of .NET jobs, including entry-level jobs. Microsoft open-sourced the full .NET stack and ported it to Linux in 2014, which created new opportunities for C# developers.
- Angular, JQuery, and React are all equally strong on the front-end. These three Javascript frameworks have fantastic pay for beginners and low competition as well.
- Ruby on Rails is still a better choice than learning either native app platform, because it combines a strong job market with good pay and low competition.
- iOS beats out Android for native app jobs. Although iOS has fewer entry-level jobs than Android and those jobs offer lower pay, the competitive environment is much more favorable.
This is only the economic part of the picture, from the perspective of a job seeker. Neither language attributes, such as expressiveness, tooling, and performance, nor community attributes, like beginner-friendliness and library ecosystem, are represented here. Nor does the model take into account how the job market might change in the future. Stakeholder value and personal value are also left out.
That being said, for beginners who just want to get a good-paying job, I hope it’s clear that job-dollars and Javagrads provide the best answer to the question, “Which language should I learn?” at a given point in time.
Conclusion
All of my market data (jobs, resumes, and salary) comes from Indeed.com, and unfortunately, curating this data is still a manual process. The good thing is that it’s not a very large amount of data, but I do want to encourage product owners and developers at Indeed (and every other job-hunting site as well) to consider incorporating this measurement into their site directly.
As more people enter the developer workforce, it is getting more important that we give newcomers a clear and up-to-date picture of which technologies will benefit their career most. Learning a technology takes a lot of time and effort. We owe it to newcomers to help them make wise decisions.