Onboarding to Elixir

Underjord is a tiny, wholesome team doing Elixir consulting and contract work. If you like the writing you should really try the code. See our services for more information.

I’ve worked with a number of clients on Elixir projects and I’ve onboarded myself, I’ve been onboarded and I’ve onboarded others. And compared to my experiences with PHP/Python/Javascript and my limited experience with C#/.Net I have experienced quite a difference.

Elixir projects tend to be very consistently laid out. Especially Phoenix-based web projects. The basic Phoenix generators provide a fair number of opinions on where things go. Even without that the general shape of an Elixir project is surprisingly stable.

So across a few different clients I’ve seen a number of Elixir projecs that have a few years on them and while there were variations such as not actually utilizing the module hierarchy and putting all of it in the widest possible namespace or overriding some common conventions, overall even the old projects were very reasonable to explore. They tend to flow from the mix.exs projects file and from there you can logically follow what parts of the system are started as you run the application. That will let you figure out what routes it exposes, what work it does in the background and much more. The Elixir supervision tree (inherited from Erlang) makes the shape of the application more clear to you as a developer.

My first onboarding onto an Elixir project was a project that essentially predated Phoenix having a stable release and so it was built right on top of Cowboy and WebSockets. I was pretty familiar with Elixir already. The guy who introduced me to the system and product on the other hand, was doing some Elixir, but was primarily doing other work. I estimated some work for this client, around a 100 hours, for the initial engagement of adding some API endpoints to provide some new functionality for external parties. And then I built it. Knowing Elixir but with no experience of this particular system and without the strong conventions of Phoenix I successfully over-delivered with some added niceties at a couple of hours shy of the estimate. I like to think I’m competent at what I do but I’m not convinced I would have that turnaround on a similarly sized Python or PHP project. The compounding complexity tends to be much higher.

Comparatively the same work in a PHP client’s code base would likely have taken me around twice the time. Why? Mostly due to clarity. Elixir is a functional programming language with a very strong pragmatic streak. It makes it easy to write clear code, rather than clever code. Comparing two codebases is of course anecdotal but it lines up with all my experiences of dynamic OOP code bases vs Elixir code bases. The consequences of making changes are much clearer, the data you have access to and how it gets passed around is plain to see. It removes a lot of guess-work.

Same Elixir code base, a number of months later I’m the person who will onboard a new developer. He has been doing PHP for a long time, no Elixir experience. No real issues, he certainly spent some time delving in and picking up the syntax and concepts of the language. He is at the time of writing productively the main maintainer of the code base. I think we had two video pairing sessions to introduce the concepts and how the thing was set up. It really didn’t take more.

Another client, a significant fintech code base in Elixir. A few different services, some with Phoenix, some without. I was brought on, given help to get things set up and started. Due to the strong conventions around how Elixir and Phoenix is used that mostly entailed giving me credentials and answering some questions on specifics. I believe I had my first commit the same week. My first major contribution was probably the next week and then we were off to the races.

So bringing on people that know Elixir tends to go well in my experience and I’ve even had good luck bringing on an experienced PHP dev that didn’t know Elixir. How about less experienced folks?

I’ve introduced at least three coding school students to Elixir during their internships or part time work with me. They typically knew some PHP, some Python and some Node.js at that point but hadn’t really used any of them in anger. One is presently working professionally with a production Elixir application and another is currently working with me as an assistant developer and doing well using Elixir on client work.

I haven’t found much difficulty in teaching Elixir or training people into the language. There are some Functional Programming concepts to work through and some habits to break. Thankfully Elixir does not look or feel incredibly different from your typical OOP languages. Most of it will be familiar to any developer. It simply brings some very different powers to the table.

One of the things I find makes onboarding easier is that you can effectively approach Elixir both bottom-up and top-down depending on what you are trying to do. If you want to get a foundational overview of what the application is and how it hangs together, look at the supervision tree, the dependencies and you can absorb the shape of the system. And the moment you need to implement a small change or add something, you can figure out the place where those things happen in the system and work there, in relative isolation and you don’t have to know everything about the surrounding system to be productive. Immutability and no shared state makes your system easier to reason about in separate parts. And that means you need to know less to make useful changes.

I’ve picked up another client’s Phoenix project without any guidance or real introduction to the code and been able to provide changes on the same day. Just by knowing my way around the conventions. Certainly this will vary by person and experience but it isn’t just due to some stroke of brilliance on my part. Strong conventions and a clear language where code is easy to reason about.

All in all, I’ve found onboarding in Elixir to be ridiculously straight-forward compared to a lot of other projects and I think that’s an important factor and I believe it says something about the long-term ease of development as well. A lot of Elixir developers tend to describe “boring” Elixir projects that just keep working and are easy to maintain.

Boring is a rare and powerful property in software systems. Especially when they can achieve exciting outcomes such as near real-time, strong concurrency and parallelism with distributed computing just baked in. Nothing quite like it.

If you want to hear me (and others!) go on about Elixir in further detail I’d suggest BEAM Radio but if you’d rather get more variety in topics I’d suggest the Regular Programming podcast or my newsletter.

Underjord is a 4 people team doing Elixir consulting and contract work. If you like the writing you should really try the code. See our services for more information.

Note: Or try the videos on the YouTube channel.