Summary: "How to use Elm at work"

I’m lucky to say I’ve been able to use Elm at my jobs because of engineering leadership who saw its value.

But most companies need to be convinced of why they should take a chance on Elm.

It can be done! Here’s how:

It can be tempting to try to convince your team to use Elm when its merits seem clear to you.

But this will not help others to see Elm as a benefit more than a cost—and no argument you make will be as convincing as proof.

Does your project have any bug-ridden features that constantly divert resources and frustrate your team?

These are great opportunities to demonstrate—not argue—Elm’s reliability.

Attempt to use Elm to solve one of the problem areas you identified.

Choose something that’s small in scope, and easy to revert. This way, the risk will be as small as it can be.

Has your experiment successfully solved your company’s problem? Now is your opportunity to explain Elm’s technical benefits.

Show others on your team what you did, and make yourself available as an educational resource.

Having proved Elm’s benefits, identify more problem areas and run similar experiments.

Little by little, you can introduce Elm into your codebase more extensively.

This summary comes from Evan Czaplicki’s retelling of success stories from engineers who have introduced Elm into their codebases at work: https://elm-lang.org/news/how-to-use-elm-at-work

This post was originally a Twitter thread as part of Ship 30 for 30.