Contents
Intro
If you follow my blog, you have probably noticed that my articles usually revolve around some deep technical problems and how to go about solving these problems using the amazing Elixir programming language. These posts usually discuss the technical merits surrounding Elixir and the Erlang virtual machine, but rarely touch on the “human” aspects of Elixir.
The goal of today’s post will be to address some of the non-technical aspects of the Elixir programming language and talk about the profound impact they can have on your engineers and your business. I’ll start off by addressing one of the most common concerns I come across when it comes to Elixir - that being that “It is hard to find Elixir developers”.
Hiring Elixir Developers
In order to substantiate the claims that I will be making, I’ll be leaning on some of my past industry experiences and will be sharing some real-world stories with you (omitting names of course for the sake of confidentiality). To give some context, I have been working with Elixir professionally for over five years now, and while I was not a junior engineer when I took my first Elixir job, I was very much still a novice when it came to the Elixir programming language. In fact, it was after reading Saša Jurić’s Elixir in Action that I actively sought out a job where Elixir would be the primary language I would develop with. You read that correctly - the Elixir language and the Erlang virtual machine made such an impression on me, that I found it necessary to seek out a job where Elixir made up the majority of my work day.
At first I thought that this story was unique to me, but as I became more immersed in the Elixir community and ecosystem, I found that this experience is actually quite common. Many of the engineers whom I work with, actively seek out Elixir specific opportunities because they enjoy the language and the run-time that much (I’ll be diving into specifically why a bit later in the post 😉). This is also supported by a recent StackOverflow developer survey where 68.2% of people working with Elixir, wanted to continue working with Elixir. For some comparisons, Go received a 67.9% rating and Javascript received a 66.8% rating.
This has also been the case when I have been interviewing Engineering candidates for a position at a company. People are genuinely excited about the language, and specifically look for companies using Elixir so they can continue using a language that makes them happy. Not to mention that any time I am part of an interview loop for an engineering position, we always have a large pool of quality candidates to chose from. This sentiment has been corroborated by others as Renan Ranelli describes in his 2017 ElxirConf presentation. This indicates to me that the Elixir programming language has a high retention rate and engineers are enthusiastic about working with it. Furthermore, it de-risks the choice of choosing Elixir for a project out of fear that no one will be available to maintain the project given that the Elixir community is so vibrant and excited to work with the language.
In my opinion, this is also reflected by larger companies adopting Erlang, Elixir and another BEAM languages (see here, here and here for some case studies and be sure to note some of the big names on the lists). Generally speaking, larger companies tend to stay on the beaten path of technology and will rarely adopt something that has perceived risk. Think Crossing the Chasm but for technology as opposed to a product. With some tech giants now adopting Elixir, I’d say that the language is well clear of the chasm and is en-route to greater adoption.
Where to Look for Engineers
Given that the Elixir community is smaller than say the Javascript or GoLang communities, you may be curious as to where to look for engineering candidates. From my experience, the best places to look for Elixir specific engineers are:
Another option is to look for a consultancy that specializes in Elixir. There are quite a few out there so be sure to look around and see whose offering aligns best with your needs.
What if you can’t find an Elixir engineer or don’t have the budget to hire any additional engineers but you still want to reap the benefits of the Elixir community/language and position your company for the future? Luckily, learning Elixir (even as your first language) is easier than you may think.
Learning Elixir
One of my favorite aspects of Elixir is that the language itself is very small yet very powerful. In other words, there are not a lot of keywords or constructs that need to be internalized in order to be productive with the language (at least initially). This in turn has two important effects:
- New team members can be productive with a new codebase relatively quickly (read this article for some more concrete examples).
- Team members new to the language can pick it up rather quickly and be productive in record time.
In fact, when I mentored people new to my team and new to Elixir, it often only took them a few days to get through the Elixir School curriculum and the Elixir Getting Started Guide. After which they were ready to take on feature tickets and contribute to the project. Given that a lot of Elixir code is basic modules and functions, people were comfortable extending an existing project and adding new functionality. The functional aspect of the language also helped people onboard to new projects quickly since they didn’t need to worry so much about mutating object state and the trickle down effects that would have across the system. It was mostly about assembling the require data (sometimes in a struct), passing the data through a series of pure functions, and handling/persisting the result at the end. In my opinion, this pattern allowed new comers to the team to focus on the business problem at hand as opposed to worrying about the nuances of the programming language or run time. They need not worry about pass-by-reference, pass-by-value, or if the downstream functions were pure or not.
You’d be surprised to hear how much mileage you and your team can get out of this “modules and function” pattern. Luckily, the ceiling for the Elixir language and the BEAM run-time is much much higher, and there are resources for learning some of the more complex aspects of the ecosystem such as multi-node applications, stateful processes, macros, and application design via the actor model. Luckily there are some really great books in this department Manning and The Pragmatic Bookshelf.
Another important aspect to consider when it comes to learning Elixir is the amazing developer experience that it offers and how it can help new comers to the ecosystem.
The Developer Experience
An important thing to take into account for both Elixir veterans and new comers is that the developer experience is seriously top notch. This directly impacts how quickly people can pick up both the language, and the ecosystem libraries. For example, HexDocs hosts all of the docs for all of the libraries published to Hex.pm which in turn gives you a consistent method for looking up documentation on all of you project dependencies. Having all libraries using the same consistent documentation tooling makes it easier for you as the developer to know where to find answers to your questions. Elixir takes documentation seriously to the point where it really is a 1st class citizen. This same documentation can also be pulled up in the REPL so you can view the same documentation in real-time as you are trying to work through problems.
Speaking of the REPL, it really is an amazing experience to be able to interact with and debug your live applications through a REPL while you are developing. This enables you to realize the benefits of REPL driven development as you can quickly validate that new functionality is working as expected even before it is fully wired up to an externally consumable interface (like an HTTP API for example).
The last item that I will touch on (because I really could keep going haha) with regards to the developer experience is ExUnit, the 1st party Elixir testing framework. ExUnit as a testing framework really makes it easy for engineers to validate that their code is doing what they expect. And this ease of use extends from junior all the way to senior engineers. Whether you are simply testing pure functions, validating an entire HTTP API calls that hits the database, or validating that GenServers start/terminate appropriately, ExUnit and the BEAM provide all the necessary tools to validate your assertions. One of the things I often hear from people is how easy and pleasant it is to write tests in Elixir.
To color these points a bit, I have a couple of anecdotes from a previous job where my team and I helped a Junior and a Senior Engineer learn Elixir for the first time. Both of these people were on the same team with me and to an extent I (along with other team members) helped them get up to speed and productive in our code base.
The Junior Engineer Case Study
This person had recently graduated from a coding bootcamp where the only programming language that was used was Javascript. As a result, this person was a little overwhelmed at the prospect of learning a new language. After going through the Elixir School curriculum and the Elixir Getting Started Guide, they were ready to tackle their first ticket. After a little bit of pair programming, this person was able to replicate the established patterns in our application and started exposing new functionality via our Absinthe GraphQL API. For someone who was relatively new to programming, I was impressed by how quickly this person was able to complete features and how little polishing needed to be done in the PR phase. And I think that is largely in part to the items priorly mentioned. The language itself is relatively small and so the engineer was able to focus on the business logic as opposed to getting hung up on creating new objects, inheritance, mutable state or run-time nuances like a global interpreter lock or event loop. The concepts where the engineer stumbled were easily addressed after a couple of Zoom calls and some pair programming. A couple of those concepts included pattern matching and macros.
With pattern matching, I found it best to walk through a bunch of examples in my editor with them and show them where you might usually see pattern match expressions, and how to determine what would be executed and when. For example, we walked through several function head pattern matching examples, and by the end of my explanation they understood that pattern matching in Elixir is kinda like Javascript’s assignment destructing, but far more powerful and also useful for application control flow.
When it came to explaining Elixir’s macros, it was mostly a matter of pointing the engineer to the documentation for that particular library and explaining that while these statements look like built in Elixir keywords, they actually are implemented by the library. In this particular case, since they were mostly working with Absinthe, it was a matter of showing them the Absinthe documentation and explaining that under the hood, Absinthe was generating a bunch of code that they need not worry about. All they needed to focus on was the usage of the macro (which was outlined by the docs https://hexdocs.pm/absinthe/our-first-query.html#content) and that learning to write your own macros (which should done only when actually necessary) would come with time as familiarity with the language increased.
This person actually went on to help another team out with a Node microservice after a re-org and often times would shoot me a message telling me how much they missed working with Elixir and how complicated production Javascript and Node were. I don’t mention this in order to throw shade at Node or Javascript, but rather to make the point that even though something may be ubiquitous, it doesn’t make it easy to learn or understand.
The Senior Engineer Case Study
For the Senior Engineer that learned Elixir for the first time, most of the learning hurdles were with regards to higher level concepts. This individual had been in industry for some time at this point and had used a variety of different languages include some functional languages. Going through the Elixir School curriculum and the Elixir Getting Started Guide were still great places to start, but when it came time to really understand what exactly a GenServer is or how to use the actor model to architect a solution, additional explanation was required. While many programming languages have actor model implementations as a 3rd party library, BEAM languages (including Elixir) have it as a first class citizen by way of the run-time.
When it came to explaining what GenServers are, I found that some pair programming and some REPL experimentation really helped drive the point that they are merely processes on the Erlang virtual machine that can be used encapsulate state or execute tasks asynchronously. It was also easy to show the life-cycle of the GenServer and when certain callbacks are invoked. Where things got a bit more difficult was when one GenServer became thousands of GenServers and how best to orchestrate and manage them. This led to discussions about supervision trees, process registries and how to tie all the pieces together.
These discussions were centered around how to architect systems and how the primitives provided to you by the Elixir and the BEAM truly allow you to build robust and fault-tolerant systems. Some of the takeaways from these discussions included how the BEAM really gives you a lot out of the box (like internode communication for example), and it defers the need for external system dependencies like Redis. All in all, this individual was able to be very productive in a short amount of time, and was able to see the merits of Elixir not just for the language but also for the run-time.
Where to go For Help
While at times things may not be all butterflies and rainbows, there are plenty of places to look if you are in need of help. From my experience, the best places to look for help are the Elixir Slack and ElixirForums. While there is the occasional answer on StackOverflow for a question, I find that most of my questions are answered on the two aforementioned platforms more regularly.
Some other resources that I generally frequent for specific questions include:
- Erlang in Anger when I need learn about operational related topics
- The BEAM Book when I need to learn about the inner workings of the Erlang virtual machine.
- The Elixir HexDocs when I need any information on builtin Elixir goodies.
Closing thoughts
Well done and thanks for sticking with me to the end! We covered quite a lot of ground and hopefully you picked up a couple of cool tips and tricks along the way.
To recap, we talked about the ability to hire Elixir engineers in the current engineering market and some good places to look for quality candidates. We also talked about the developer experience in Elixir and how that translates to a gentle learning curve for people new to the language regardless of seniority. Lastly we talked about some additional resources to help you on your learning journey.
Feel free to leave comments or feedback or even what you would like to see in the next post. Till next time!
comments powered by Disqus