Let's talk about Elm | Oliver Polka

It’s been six years (at the time of writing this article) since I gave my first ever public talk about Elm. Looking back at what I’ve learned since then, I wanted to write a story about how it went down, what went well, what went wrong.

The promise

The idea behind the talk was simple, share the excitement about this programming language I had been using for over a year, which I found really fascinating. The talk was supposed to be a quick introduction to Elm, as I was really surprised not many people knew about it and even fewer people had actually tried it even though we had quite a big mobile and web departnment at the company.

These were my goals going into it:

Introduce Elm to a broader audience at the company;
Showcase Elm syntax, types and functional programming;
Solve common frontend development issues in Elm;
Explain how to inter-op with JavaScript;
Highlight how The Elm Architecture helps with building stable and ready for production code;
Share all my excitement and maybe try to convince some other people to give Elm a try;

Looking back, this was far too much for a 30 minutes talk.😅

How it went down

Since this was my first public talk I greatly underestimated the time needed to cover all the topics and goals I’ve had. The original time constraint for the talk was 30 minutes, and as you can guess it really is not enough time to introduce a new programming language to an audience that had never seen or heard of it, showcasing all the cool things I was super excited about. So not only did I go overtime, I skipped slides and even lost most of the time that was reserved for Q&A.

What not to do

Do not list and talk about every single feature a language has to offer

In all the excitement I had about using Elm for a year, I wanted to show all of it in one presentation. Basically, I’ve tried to squeeze a whole workshop or a tutorial into a short talk.

The question I should have asked myself when preparing the presentation was “What is the bare minimum they need to know so they can follow and not get lost in the presentation”?

Do not try to explain everything

It would be much more interesting to show one error, or some common frontend bug and showcase how to prevent it using Elm or how to solve it with the help of the Elm compiler.

Not planning the talk with the time requirements

I would keep adding and adding slides and information into the presentation without checking for how much time it would take for me to cover all of it. It’s a much better idea to time box the talk, split it into clear sections for example:

3 minutes intro of what is Elm and why I care about it
20 minutes core presentation with examples
5 minutes to talk about why The Elm Architecture is a cool concept that others take inspiration from
2 minutes to conclude the talk

Also one thing that I should have done when I was running out of time was not speed up, and still go overtime. It would have been much better to just do as much as I’m able to do on a calm pace as speedrunning through slides makes it a really bad experience for the audience and worse talk in general.

What went well

Even though the presentation was overloaded with content, I did manage to introduce Elm to a bigger audience at our company. People responded well mainly to my excitement and were incredibly supportive. They provided good feedback on not only the content but also my delivery.

Looking back, it was a small disaster. But thanks to the support I got, I didn’t give up on public speaking after that one failure. I took the feedback seriously, and as you can see from the other stories I’ve shared, the next talks went a lot better.