Sophie Alpert

October 19, 2018

I’ve been a part of organizing React Conf for the last few years. One thing we do differently from most conferences is that we do dry runs with each speaker in the couple weeks leading up to the conference.

We have them run their full talk and slides uninterrupted from top to bottom, then we give feedback afterwards. Here’s why:

• It fights procrastination. Most of us are bad at planning, and a huge fraction of people will always put things off to the last minute (or in this case, the last couple days). So the silly truth is that half the reason we do these dry runs is to help give speakers a deadline that they can work towards that still has plenty of breathing room before the real thing happens. And this means people will have more time to polish their talk. I usually don’t tell people this upfront because it seems almost condescending, but in my experience the speakers often give me unprompted thanks for setting a deadline for them.
• We get to give feedback. The other reason, which is more natural, is that it gives us an opportunity to give speakers feedback on their draft talks. Sometimes this ends up being general advice that would apply to any talk; other times, we can use our knowledge of the specific conference and format to help people plan. One nonobvious consequence is that sometimes two speakers end up covering similar or overlapping content — when I notice this, I usually get the two to talk to each other so that we can make sure the whole day flows smoothly.

Ultimately, this whole process is win-win: speakers love it because it makes their talks better, and we love it because it makes our conference better.

---

If you’re curious, here are the most common pieces of feedback I end up giving:

• Introduce the terms you use. This piece of advice might sound obvious, but I end up giving it after almost every talk I see. In any large audience, people will have different specialties and varying levels of familiarity with what you’re presenting. Try for a moment to forget what you know and look at the deck with new eyes: is this going to make sense to a beginner or someone else who doesn’t have the context you do? Checking through all the proper nouns (names of tools, libraries, standards, etc.) is a good place to start. Adding an explanation is always one way to fix this, but another is to remove the mention completely — a lot of times, you didn’t need it in the first place.
• Less code on slides. Reading code is hard. Audiences are bad at it. (People are bad at it.) 90% of the time, if you have more than 10 lines of code on a slide, it’s not going to be easy for the audience to understand. Whenever you show a new complex slide, audiences will stare at it trying to figure out what is going on (and they’ll get distracted and miss what you’re saying). Even if your code example is relatively short already, look for extra parts that don’t need to be there and try to cut it down to as short as you can be. If you really need a long example, it can help to introduce it in chunks while explaining it so it doesn’t all happen at once.
• Say upfront where you’re going. Or as I like to say: tell me what you’re going to tell me (and why), before you tell it to me. When you plan a talk, you have an idea in your head of an overall narrative and what you’re hoping that the audience will take away. I recommend giving the audience a rough framing of your talk that they can use while listening. For example, if you’re telling a story about how you built a particular app, add a slide in the beginning with a screenshot of the app, and say explicitly, “I’m going to tell you a story about how we built this.” — and ideally, why they might care. Without this, a 30+ minute talk can end up feeling like going on a long tangent, with a jumble of ideas that don’t fit together.
• More dry runs. You’ll present better if you aren’t trying to remember what you want to say during the talk. Running through the whole talk a few times (especially the day before) will help. And make sure you’re not practicing mistakes either — if you’re stumbling over a live coding demo in your dry runs, you’ll likely stumble over it in the talk. One tool that can also help is writing out a full transcript of exactly what you plan to say in your talk. This sounded a little weird to me when I first heard of it, but I’ve found it really helpful. When you can see the whole talk in written form, it makes it easier to make sure you’re introducing things in the right order and that the flow is right. Then go back to running it by yourself until you have it more or less memorized.