Training Developers

Training developers for a new language is more than simply sending a few of them at a time to classes and conferences. A holistic approach is better. Early adopters are learning and deploying new technology at the same time, and we want to minimize where things can go wrong.

Once we decide to make a commitment to Elixir, our main goal should be to solve a single, focused problem. That may be a small web service, a prototype, or the sketch of a system we plan to rewrite.

It’s also worth shaping our first team of Elixir developers with the future in mind. Experienced developers will be more comfortable with leading the project and working as mentors. Some may have been exposed to functional programming, which will ease the migration to Elixir, and others may have deep domain knowledge.

Remember: We don’t have to immediately train everyone to write Elixir.

At Bleacher Report, they had only two to four full-time Elixir developers in the first year. This strategy gave developers time to learn the language and get the prototype apps into production. Once we’ve established early success and momentum, we’ll be ready to engage the rest of the development staff bit by bit.

Let’s take a closer look.

Establish momentum with early prototypes

Our first prototype will have a tremendous impact on the adoption of Elixir at our company. Start by establishing what the language can do and what it can’t.

An early prototype has to balance the following aspects:

• Tangible business value: We need to quickly reward the business side of the house with a quick win. That win might be fixing a problem they’re seeing in their existing application or establishing a new capability that’s cost prohibitive using older technology.

• Central enough to be seen and big enough to matter: We need a visible political win and a technical win. A trivial problem may not give us either.

• Small enough to permit failure: We don’t want to bet the company on success because we didn’t have enough experience to take on such a large risk.

In essence, we should aim for low risk and high reward, both on the technical side and the business side. At some companies, picking up new technology is a straightforward process. In other companies, we may need to involve our stakeholders in the decision-making and planning to get the maximum political value for the win.