In 2004, Paul Graham wrote an essay on the perks of picking a less-popular language.
If a company chooses to write its software in a comparatively esoteric language, they’ll be able to hire better programmers, because they’ll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don’t learn merely to get a job.
Keep in mind that this essay was written fourteen years ago. Python’s adoption, tooling, and community has soared since then. It is no longer an obscure language for hackers.
The underlying point is that by using an esoteric language companies can dramatically improve their hiring pool. Perhaps, Paul Graham drew the insight from his own experience in choosing Lisp for Viaweb. In the essay “Beating the Averages,” Paul Graham writes:
After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening— that’s starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried.
However, I think Paul overstates the benefit while ignores the costs. If there is a singular benefit of a better hiring pool, there are several pitfalls.
Hiring is Harder
Consider a codebase that uses a functional programming language. When it comes to hiring people, it’s true that programmers versed with functional programming would be, on average, better than those who aren’t.
However, the hiring pool itself would shrink massively. Learning a language is an investment, and not many people are using their spare time to learn a new one. As I have seen it happen, demanding functional experience soon becomes an unreasonable expectation. The company has to lower the criterion and train engineers in functional programming instead.
Does the advantage still stand if you have to resort to hiring from the bigger pool?
A vibrant, contributing community makes a lot of difference in the pace of software development. If an open source solution already has solved a problem that you’ve, you don’t have spend hours doing the same thing. And this is not just about libraries. Tooling, tutorials, examples, conferences, and number of peers, everything is better for a mature language.
A newer language might have a growing community, but the problems (like migrations, monitoring) are still being solved from scratch. Three years back, I wanted to write an app in node.js and was very disappointed to find that there was no solution for database migrations that was as good as Django’s.
Talent might be better, but the cost of rebuilding everything is significant.
Familiarity of a Language Isn’t a Great Criterion
The code is no concern to users. What matters is it helps them achieve. By focusing too much on what is just a means to an end, shipping might take a back seat.
Knowledge of a specific language isn’t an incentive that is aligned with users’ goal. There is no difference between a product shipped in Java and one in Clojure. Good shippers (hackers, if you may), which is what most companies are looking for, can make use of any language. In fact, they should be content with whatever is at their disposal and focus on solving problems. An esoteric language is fundamentally a wrong factor to motivate a programmer with.
Preferred language/framework is a personal choice. I prefer to choose a stack that has worked for me for all the years, while somebody may believe that newFooLang benefits in the longer run. I don’t think it’s wise to sideline all programmers who are perfectly happy with their choice of technology.
At a closer look, even the benefit isn’t significant. Facebook was pretty successful in hiring and retaining talent and it was written in PHP. I can speculate that most of the tech companies, when starting out, wrote their software in a popular language. Hackers pick languages that are familiar to them.
Additionally, the pool you are hiring from isn’t the most important thing in making quality hires. Having better processes, culture, and management can all be significant factors in building a great team.
Good engineers must be concerned with solving problems that users have, not the tooling used in the solution. Paul Graham’s idea promotes a wrong order of priorities.