Haskell has a hiring problem.
There aren’t many Haskell jobs, and there aren’t many Haskell employees. Haskell employees tend to be senior engineers, and the vast majority of job ads want senior-level Haskell candidates. The vast majority of Haskell users do not have any professional production experience, and yet almost every job wants production Haskell experience.
Why is this the case?
We write fancy code. Here’s a familiar story:
Boss: You’re going to be allowed to make a new project in whatever language you want. Even Haskell.
Employee: Oh yeah!! Time to write FANCY HASKELL!!
Employee writes a ton of really fancy Haskell, delivers fantastically and in about 1000 lines of code. Everyone is very impressed. The project grows in scope.
Boss: It’s time to hire another Haskeller. What are the job requirements?
Employee: Oh, they’ll need to know type-level programming, lenses,
servant
, Generics, monad transformers,mtl
, and advanced multithreading in order to be productive anytime soon.
The boss then has trouble hiring anyone with that skill set. The project can’t really grow anymore. Maybe the original employee left, and now they have a legacy Haskell codebase that they can’t deal with. Maybe the original employee tried to train others on the codebase, but there was too much to teach before anyone could do anything productively.
Finally, someone gets hired on - they have several years of Production Haskell under their belts. But where did they come from? Another Haskell company, most likely! Now that company has a job to fill. Where do they fill it from? The same pool of candidates that they just lost someone to! They can’t hire juniors or train folks for the same reasons.
This coming year, let’s break the cycle.
Let’s write junior code.
Let’s write simple, basic, easy Haskell.
Let’s get bogged down with how much simple code we write.
Let’s make jobs for juniors.
Let’s hire juniors.
Let’s train those juniors into seniors.
Let us grow Haskell in industry by writing simpler code and making room for the less experienced.
Let’s not delete all of our fancy code - it serves a purpose! Let’s make it a small part of our codebase, preferably hidden in libraries with nice simple interfaces. Let us share the joy and wonder of an Actually (Mostly) Good programming language with the people that haven’t had the privilege and opportunity to work for years in it already.
Kudos to Marco Sampellegrini who wrote basically the same post as me today. Kudos to Michael Snoyman who has been championing Boring Haskell for a while. And kudos to everyone else who has contributed to making Haskell easy, and not just powerful/fun/flexible/fast/amazing.