Recently I noticed the number of the same two questions being asked again and again on different Haskell resources. The questions were “How to get a Haskell job” and “Why is it so hard to find Haskellers?” Although these two are coming from the opposite sides of the hiring process, the answer is really just one. There is a single reason, a single core problem that causes difficulties of hiring and being hired in the Haskell community, and we should clearly articulate this problem if we want to increase the Haskell adoption.
We all know that there are many people wishing to get a Haskell job. And a visible increase of Haskell jobs looks like there should be a high demand for Haskellers. The Haskell community has also grown like crazy past years. But still, why is it so difficult to hire and to be hired? Why can’t companies just hire any single person who demonstrates a deep knowledge of Haskell in blog posts, in chats, on forums, and in talks? And why do Haskell companies avoid hiring interns, juniors and middles? What’s missing in this puzzle?
There are very good economical reasons for companies to prefer developers with some production experience. Juniors do things badly because they lack the basic skills. Middle developers do things wrongly because they lack the knowledge on how the things should be done. Juniors can’t work independently, - especially in the era of remoteness. Juniors need mentoring, which is costly because it distracts senior devs from their work. Being given a right to make decisions, juniors will put the company onto the edge of survival sooner or later. Middle developers may introduce code that will be problematic in the future. They usually don’t see a big picture of business movements, and don’t think about the future of the project. Hiring junior and even middle developers is an understandable risk that many companies just can’t afford.
This is all true for any software companies, but in Haskell, the problem gets much bigger.
The vast majority of Haskellers is coming from a scientific field: CS students, PhD seekers, Programming Language researchers, Math learners, and all the people who are keen to dive into these breathtaking topics. Those people act out of curiosity, they are very enthusiastic and smart, they often know many sophisticated features of the Haskell language. It also seems that they think that this proficiency in deep concepts makes them great developers automatically. Actually, it doesn’t. Being knowledgeable, enthusiastic and curious, and having a wide scientific background is a strict plus, but not a ticket into professional development. In fact, software development requires a quite different mindset, and there is some extra knowledge and skills one should have to be hired.
If you want to be really helpful to your potential employer, you have to do certain things and follow certain rules. You should be able to understand and solve business problems, and you should do this with a full responsibility for the consequences. You are here not because you are so great, but because your employer believes you can help them to advance the company’s being. Your employer pays you some money from their pocket, and wants you to solve the company’s problems. This limits your freedom. You are now responsible for the future of your project. You literally don’t have a right to spend your paid time for doing unrelated things just because you were curious about them. Every decision you take should be justified from the pragmatic point of view. Why? How will this help? What are the risks? What are the alternatives? What real problems does this solution cover?
The Haskell language has an unfortunate reputation of being academic-only. Haskell attracts people with a “scientific” mindset, the community exposes this mindset in all the resources, and this harms the adoption of the language in industry. This finally results in a harder process of hiring Haskellers. Companies don’t want extra risks. Choosing Haskell is a very big risk itself, and it’s a crime to increase it by doing things wrongly.
- Companies need to be sure that people they hire won’t turn projects into an unmaintainable garbage. It’s a risk. Code that is badly designed causes a lot of problems, and the more time passes, the harder this problem becomes.
- Companies need to be sure that their codebases won’t drown in an unnecessary complexity with time. It’s a risk. A code that is penetrated by complex things becomes inaccessible to those who will come after you.
- Companies need to be guaranteed that they will find more developers, possibly less skilled ones who will be able to land into the project and continue its development. A smart code limits your employer’s field of potential workers. This is certainly a risk, too, and this is how you affect the company even if you are not aware about those risks.
But every professional developer should be aware of those risks. After all, there should be no decision making without responsibility for the consequences. To avoid those risks, to even know they exist, a seeker of a Haskell position should learn how to build real world projects, how to design them properly and how to work in a team. And let me articulate this one more time: this is not about knowing Haskell itself, not about knowing Category Theory, not about the ability to read through Pierce's book. It’s all about software as an engineering discipline, and the very set of practices we call, well, Software Engineering. One may be less skilled in the language, but should have at least a shallow understanding of approaches, best practices, principles of software development, better accompanied by some real experience with those.
Software Engineering has a lot of really good points which were sharpened with blood, sweat and tears by the mainstream world. People from popular languages went a long path full of tries and errors, failures and successes. Lot of companies died from doing things wrongly. Statistically, Software Engineering gives companies some guarantees, helps to survive and move fast. There are literally no good reasons to avoid this knowledge in Haskell, because, - I may surprise you, - Haskell is not different from other languages in this sense.
Unfortunately, the idea of having Software Engineering gets into contradiction with the community’s belief that Math and smart cool approaches is all we need to be successful. The topics of Software Engineering (such as avoiding extra complexity) hit into the very heart of the community: the need of pushing the progress in CS, the need to be on the cutting edge of Haskell technologies, the need of getting community’s appreciation when one demonstrates those deep concepts of the language. Software Engineering teaches us to be pragmatic and rational. To avoid emotional exaltation and unhonest inflated expectations from the new shiny cool things. Software Engineering teaches us to not fall into the Cool Thing Driven Development. It also teaches us to avoid inventing a wheel again and again, to stick with proven, reliable, risk-free solutions, to think about requirements the business has, and finally, to interact with that business. To interact with that dirty world full of hidden pitfalls. And a person who wants to be a senior software engineer should understand this clearly.
It’s true that Haskell is a stellar performer that brought a lot of impressive ideas to the world of programming. Haskellers want to push CS even more, and I guess there is a big temptation to act like they are in the academy when they are in industry. It’s nice when the goals of the company align with the need of a person to push the progress, but this should be a deliberate choice and voiced agreement. I doubt it’s a very spread case though. The vast majority of commercial companies are not looking for CS pushers. They just want to get “their shit done”. They pay for this, and this is pretty fair, isn’t it?
I’m really sorry to say that, and really sorry if I destroyed one’s picture of the world, but we should be honest in this if we want to change the situation. Now we can draw a line and answer the initial question: so what’s the problem?
The problem is a discrepancy in the value system Haskellers expose and companies want to see.
Fortunately, this problem is solvable. All the participants should do their own steps to improve the situation.
-
For candidates - need to learn more about Software Engineering, more about how to build real programs and more about how to work in a team.
-
For companies - to clearly state what skills they are looking for. Articulate what they expect from the candidates, and what are tasks they need to solve together.
-
For the Haskell community - allow this industrial mindset to coexist with an academic one. Give it a chance. Don’t bash simple approaches, don’t blame people for not knowing deep Haskell concepts. Don’t refuse to learn from the mainstream.
Because once the industry sees this attitude, it will believe in Haskell, and we’ll all enjoy the increase of Haskell’s popularity.
P.S. If you don’t know where to start with learning, I prepared a lot of materials for you.
-
My book Functional Design and Architecture. It’s currently the only book in Haskell about Software Engineering. Will be useful for every Haskeller who is interested in building real programs, with low risks and good design.
-
Haskeller Competency Matrix. Here you can track your skills and get an idea on how to be a better industrial Haskeller.
-
A set of materials on Software Design in Haskell. This list should help senior software engineers to make deliberate choices in their work.
-
I’m also writing my second book, Pragmatic Type Level Design. You can support it if you want more good books on pragmatic Haskell to be written.