Over the weekend, I gave a talk at Droidcon Vietnam about data binding and Plaid. One person told me that public speaking seems to come naturally for me and today I would like to illustrate how that came to be.
As a general rule, I am not comfortable talking about topics that I barely know. Meaning, I would not submit a talk proposal about something that I haven’t used in an actual app. Some people are okay with proposing topics and then researching about them, but that doesn’t work for me.
Idea
For the longest time now, I have been trying so hard to convince people to give data binding a try. There are a ton of posts out there about it, but for me they all seem so… abstract. Dare I say it’s sort of similar to that thermosiphon example we are all so familiar with.
I have always loved Plaid and I always turn to it for ideas on how to interpret something. If you follow me on Twitter, you’d probably noticed how I always use it for my samples or tips.
I learn best by doing, so I thought we could really use a practical, real-world example of how to use data binding in an actual real-world app with real-world use cases. The people most skeptical of data binding are those that are in the midst of working on an app, and I thought maybe a little nudging to show them how easy it can be might help. What could be better to illustrate this than something they already have access to?
So if you feel like there is nothing for you to talk about, that simply is not true. If something made you go “I wish X exists to help me learn Y”, that’s a talk idea right there.
Code
I spent a whole bunch of time writing code for this talk. And by whole bunch I mean ~40 hours worth of work spread over three weeks. It may seem like a long time, and it is, but it may as well be because I’m slow. ^-^
Text
I started up a Google Slides draft right as I started working on the code. That helped me come up with an outline organically. At this point, the slides all consist of short titles that would probably make sense only to me, and links to PRs that I create against my repo. If there is a particularly interesting thing I run across, I note it in the slide too.
Slide draft
And then of course, there’s the inevitable three days I spent looking for a suitable presentation theme. I use Slide Carnival, and it took a lot of false starts before I finally settled on Viola.
I then spent another ~20 hours writing and re-writing and fixing up the formatting. I make sure I format the code on my slides nice and pretty. Here’s a recipe for you:
Formatting code in Google Slides is so easy; there really is no excuse not to do it. I even made a gif! pic.twitter.com/1iLZpfQxwA
— Zarah Dominguez 🦉 (@zarahjutz) March 7, 2016
Edit: Or you can use Roman Nurik’s cool code highlighter for slides
I use speaker notes a lot when drafting my presentation. They are not word-for-word scripts of what I want to say though, but they do help me remember the point I was trying to make and is a good coach during practice runs.
Talk
I like to be well-prepared in anything that I do, especially with public speaking where I feel like people are judging every word that comes out of my mouth.
It helps me a lot to actually say out loud what I mean to say during the talk whilst writing my slides – things do sound different when said aloud. This way writing slides is already a practice run of its own.
After I’m done with my slides, it’s time to do the first of many runs. I start a timer and then say everything I want to say. It would then give me a rough idea of how much stuff I need to cut (if I took longer than my allotted time) or add (if I went under). I do this run and cut/add as many times as required until I hit the target time +/- at least a couple of minutes.
The night before I should give my talk, I try to do at least three full-length runs. Crazy, I know, but that’s just me. I tend to stumble on some words, so I practise saying those, too. I try to lessen looking at the speaker notes after each run – just glancing down at them if I find myself lost or forgetting the main point of a slide. For my last run of the night, I practise with my clicker.
On the morning of my talk, I do another run. If I can, I look through all my slides at least an hour before my slot to make sure that I remember everything.
What I mean to say is this: Giving a talk does not come naturally for me. It takes a lot of hard work and practise and patience.
And I think this is something that we should all remember. Most of the time we see the result, but we rarely see the blood, sweat, and tears paid to bring about that result.
Ask for help. Ask someone to look at your slides and give feedback, ask your local meetup group if you can do a practise run with them before your talk, ask a person who is in your target audience to listen to you practise, ask for a second opinion.
PS: I think this talk is worth giving one or two more times, so please let me know if you want me give it at your event! :)
PPS: I would like to reiterate that this is my process – it may or may not work for you as everyone has their own style. :)
Thanks to Nick Butcher for letting me mangle his code and for early feedback on my drafts, Yigit Boyar for being patient with my stupid questions, Hugo Visser for the late night code reviews, Michael Evans for listening to all my whining, and Francois Blavoet and Frederic Barthelery for reading through the drafts of my preso.