What do you expect of an Elixir conference talk?

Chat / Discussions
, , ,
1

I have a few conference talks under my belt at this point (three of them to be exact, and countless of talks given at meet ups). I think I have a style by now—some ideas about what it means to give a talk, and my ideas of how to present my ideas; but, I would like to hear what kind of talk you expect from an Elixir conference.

For instance, I’d rather explain something that is obvious to 80% of the room. If I talk about a concurrent system I will give a short intro to concurrency. My latest talk was about the API of a MQTT client; here I showed a slide with two processes sending messages between each other, and that processes can do so because they have identity. I did this to show the only semantic I can produce for my client (in the context of an outgoing publish) has “one natural way” in Elixir (and Erlang).

Do you find this kinda of argumentation and reasoning to be «patronising» ? Personally, when others do it I just accept that I know what they talk about, and find joy in hearing someone else explain it, and sometimes I see ways to explain it to others at a later time. Or do you want more advanced talks ?—and how would they look ?

This question might be all over the place—please feel free to share your ideas about technical talks :slight_smile:

10 Likes
2

I agree with you. A couple of points: even if a lost of the talk is going over things the audience mostly already knows, that means a lot of it is new to them too.
If everything in a 40 min talk was unfamiliar to me as an attendee I would leave there trying to gather it all.
Also, there is a broader audience that will watch it online. Its worth considering that audience too.
The risk of alienating the part of your audience that is new to the ecosystem is greater than patronizing the ones that are experts.

3 Likes
3

I really like the idea of being very clear on the key concepts of the talk. Although an intermediate or higher talk might expect some knowledge of the audience, it makes sense to provide a refresher on the concepts you see as the building blocks that you’re building on later in the talk. That way you’re including the 20% who might not be familiar with those concepts, but you’re also “priming” people’s minds, making it easier for even the 80% of the audience to follow along.

I’d say the trick is knowing what is relevant and what isn’t. Preparing for a talk you’re likely to pick up a lot of information that isn’t strictly necessary for the audience to understand the talk. Putting in the effort to explain those parts would just be confusing. I’m not suggesting you do that though :slight_smile:

5 Likes
4

I don’t find introductory level information patronising. A lot of the better presentations I have seen tend to split the talk into thirds and cover the basics, then some intermediate content and finish with advanced information. I think that it generally means that most of the audience will follow and learn from around 2/3rds of the talk.

Also remember that at conferences a clearly labelled introductory or advanced talk can give attendees some time out to chat to others if the decide to skip it so targeting a particular knowledge level and covering something in depth isn’t always a bad thing.

And titbits of information can surprise even advanced level people. When José streamed some Advent of Code solutions in December and mentioned that IO.inspect had a ‘label’ parameter most of the viewers learn something new. Very few people know everything and those that do are probably okay sitting through stuff they know or they wouldn’t be there.

3 Likes
5

«patronising»

You can’t please every body.

I’ve had to condense a complex subject, time series forecasting with ARIMA, which I usually give 1hr and 30 min talk to 30 min at a meetup. The people who knows a bit more was very critical of the talk.

I think in general I’d like to keep in mind that presenter are going out of their way to share something and they took the time (time is much more valuable than money). The questioners who are aggressive, who doesn’t like it, should give a presentation then if they don’t like it. I do agree there should be effort in putting in presentation but I dislike questioners who are aggressive and never given a talk before.

I think how you’re doing it is fine. You have to set a base line of understanding before moving on to more advance stuff so you can get as much listeners as possible to follow along with you.

If you want to give an advance talk then you need to have an advance audience (meaning that their knowledge baseline is high). If I wanted to give a Bayesian talk I can give it at a Bayesian conference but if I want to give a nonparametric bayesian talk at a Bayesian conference I believe I would fall back to your style. It’s because nonparametric bayesian is very rare in the wild.

1 Like
6

I think it’s good to make short intros about the concepts necessary for the talk as it also states which vocabulary you are going to use, and those who know the subject in another language or with different terms can follow better.
What I don’t like is people spending a quarter of their time speaking about their company and the overall context of the talk. I know you want to thank your employer for sending you there, but that should not last more than two minutes.

3 Likes
7

When I go to a conference, I expect to learn something new, I expect to see an example of something I don’t yet master and to see some light shed onto that topic.

If I feel that I already know 80% of the topic, then I just move on to munch of free food (when there is free food) :smiley:

In all seriousness however, as was previously said, you can’t please everybody. Just make sure you can please your target audience. If you wanna talk about processes, specify at the beginning that your talk is for people who don’t master processes yet.

And also, I don’t find it patronizing. Saying you are patronizing me because you are talking about a basic topic in Elixir is the same as me going to a Buffet and feeling patronized because they have water - it’s the basic element of food and people still enjoy it :stuck_out_tongue:

3 Likes
8

So if you are talking about specific topic such as implementation of some protocol, it’s always good idea to go two steps back and describe what the problem is, what are the solutions out there. Explain that there is this protocol that handles these cases and it’s good because of X, and that your library implements it. And then that something uses this protocol to do Y, better than say using HTTP and there are real life implementations and give examples.

I have seen quite a few talks where they are focusing on their library / implementation of something, without explaining much of what the actual problem this library solves, what can it be used for etc.

With my GraphQL talk I did last year couple times I put like 1/3 of the talk to describe what it is, how was created, what it is used for ect. before I even started talking Elixir. I did a trial run without, and people were confused like they knew sort of what GraphQL is but not quite.

And 2nd thing, if you do the above and spend 15 mins explaining what the original problem is, and there are people in the room that obviously know it well, they will get bored. So, I figured that the first 15 mins where I explain the problem is also good place to insert some jokes.

I got really good feedback after this talk, people really just complained about slides (and rightfully so). But I’m going to use this format one as a template for my future talks (when/if I find some time…). https://www.youtube.com/watch?v=K_9IXTUwVL4

5 Likes
9

Expectation management is a good point. I think I should consider that for my first couple of slides in my future presentations, allowing people to jump track. Side note; I did mention that Tonci was on in the other room, and that he was showing exciting stuff with Scenic at my ElixirConf EU talk :slight_smile:

To me talks are there to inspire—to plant a seed in my mind that I should look up a topic (why that topic is interesting), or that I could use an approach when dealing with a problem. As such I believe you can only remember about 10-20% of what you hear, so I don’t go too hard on every little detail, and every option you can pass into a function when using a library.

1 Like
10

I allotted around 10 minutes for introducing a high level view of MQTT for my Tortoise presentation. I figure that it is a relatively unknown protocol, with a very specific use-case. I actually didn’t go too much into detail, and I mostly covered the aspects I would later talk about in regards to my client design. Had I talked about a HTTP client I would probably have jumped straight to describing the client, assuming everyone knows the basics of HTTP.

It is a fun thought; when does something become so common that we can skip it? I remember the first couple of Elixir conferences where we basically talked about what Elixir is, and why we choose it for our company (or personal project). It is a different time, still exciting, but in a different and better way.

1 Like
11

You are being far too generous when judging people’s level of understanding. I found out many programmers do not know how HTTP works, possibly even after building web apps for years. Simple question like: “is HTTP binary or text based protocol” leaves people puzzled. Not to mention things get very hairy very quickly with HTTP when compression, headers, cookies and reusing connections, SSL and/or next versions (HTTP/2) kick in. So when introcuding new HTTP client I think it makes total sense as well to go two steps back and remind people what we are dealing with.

3 Likes
12

Fair point. I guess fewer people would use it if they knew what it was :slight_smile:

13

I was at the talk. Cheers for what you had to share!

First, I belive some people are showpersons and some are a bit less at that. This has little to do with how inspiring their subjects might be. That being said:

I have heard of MQTT before. I would have loved to hear a comparison with a more common standard such as AMQP and why would one choose one over another. I would have expected to hear about IoT (or whatever) example uses. All that to give it more real-life context.

For me the giveaway from the talk is that there is a first-class support for this protocol in Elixir and that you are the one who deserves the credit for that.

At the conference, I have heard talks that ranged from fully-immersed and f**king-too-fast speaking (ets/ecto), an elaborate yet dull university-style talk (library design), real-life experience (rewriting of apps), purely technical ones (ssl) to talks that shed light on the direction Elixir is taking (broadway and live view keynotes). Yours would fall into the technical one range and, as said above, it’s all about expectations management. People not involved in restrained high-throughput protocols or IoT would have had hard time relating to this (I believe still) niche subject .

1 Like
14

Thanks; I think a comparison between AMQP and MQTT would have been in order. I don’t think I even mentioned that there is no back-pressure, and I could have shown shared subscriptions—and coming up with examples is the hardest thing. But for my next MQTT talk I will definitely work on a better example. But, I had planned for 10 minutes for introduction to the protocol, 10 minutes about the current version of Tortoise, and 10 minutes about the next.

And thanks for your brutal, yet to-the-point and constructive critique (that kind of critique is the best); stuff like speaking too fast is something we can work on. I hope I didn’t speak too fast—I try not to do that. I know my non-native english tongue had problems with pronouncing «quality of service» at points, but now that I am living in an English speaking country I can work on that.

The reason you saw mostly MSC’s in my presentation is because of some critique I got for my BitTorrent talk back in 2016, where one of my friends interrupted the people congratulating me for my talk with: «MARTIN! Great talk…but. You gotta use MSC’s, because we want to know what is inside of your head»

3 Likes
15

I strongly believe, that this is a hard question. But a one worth asking to be sure!

Probably the state-of-the-art is to have labels like: Beginner, Intermediate, Advanced, qualifying the level of a conference talk. I think this is problematic in its own right, because obviously the perception is different for each attendee of the conference. So you could get negative feedback, that your talk is falsely labeled, on both ends.
This is quite a dilemma and true for nearly all conferences.

I believe, that skipping an “Introduction”, and by that I mean a section in your talk especially labeled as such, could help you. Sometimes I find, that people something like “History of XYZ” in your case “History of MQTT” and get stuck in this. I believe this is usually a waste of time.
Comparisons are sometimes a good idea, but if you compare MQTT to a other messy protocol, that hardly someone understands (AMQP/HTTP I’m looking at you) you will loose more people.
A question I like to answer, if I’m facing the problem of giving a talk is: Why is the thing there, I learned to love? Why should people love it as well?

Just sum up the basics and give an example of the basics. It is best, if you use your own words to explain the things you understood and are crucial to grasp you points.
I believe this will cause the audience to listen more carefully and I’m quite every level will take something away from that as well.

I like it if things get things explained in different way. Thing, that I thought I already understood well enough. Usually it turns out there are few aspects I missed.

Just explain what you want/need to, and do not bother with an “Introduction”.

TL;DR

I would probably try to abandon the notion of “Beginner/Advanced…” altogether. Just because it is a problem you can not decide a priori; if you’re going for a talk targeting > Beginner, sum up the expected knowledge in the abstract and at the start of your talk; skip an introduction section, just give a basic example, explain it in your own words and always keep R.Feynman in mind " If you can’t explain something in simple terms, you don’t understand it".

1 Like