Before we start - I'm working on https://cloudash.dev, a brand new way of monitoring serverless apps 🚀. Check it our if you're tired of switching between 50 CloudWatch tabs when debugging a production incident.
You might be familiar with the following scenario.
You've been a developer for a while and you've learned quite a lot along the way. Travelled to a couple of tech conferences, saw a number of tech talks and one day you think - "I can probably do that". This is what I personally thought at the beginning of 2017.
The good news is that this is true - you CAN do that.
The bad news: it's not easy.
Okay, so you've decided that you'd like to speak at the next ReactVueConf Łódź or any conference for that matter. Unfortunately this is only half of the story - you need to submit your talk and most importantly - have it accepted by the CFP committee.
It's highly unlikely that you will get accepted by the first conference you submit your talk to. Or the fifth.
Start with local community events. They're easier to get to than major conferences and you'll get your first experiences as a public speaker in a more comfortable setting. Those kinds of events are often recorded, which is a valuable addition to your CFP. In addition, give a talk at a knowledge sharing event at work. Next up - speaking at a conference.
At this stage, you most likely want to apply to as many events as you can (but don't send a CSS Grid talk proposal to a .NET conference). Be prepared to receive lots of "unfortunately your talk was not selected for X" emails. Or no feedback at all.
Keep on rocking. Read this article about writing a successful conference proposal. Reach out to your friends and/or colleagues for feedback. I personally would be glad to review and offer feedback on your future proposals.
One day you'll get a "your talk was accepted for X conf" email.
Well, you did have slides and everything prepared well in advance before you submitted your talk, correct?
You probably didn't, so let's get to work.
Similar to the movie "Inception", think about a single idea, thought, sentence you want your listeners to take away from the talk. No, you don't need to become a philosopher overnight. A good practice is to try describe your own talk in 5 words or less.
One of the best advices I've heard was:
People can either listen to you or read your slides. They won't do both
Think about that when preparing your content. If you're going to have code on your slides, make sure it's the least amount of code necessary to convey the same meaning.
Slides are not there to contain the content of your talk either. You might not even need words to begin with. After all, the attendees came to listen to you, not to read. Use contrasting colors, make sure that people in the back can see your content.
Having 100 slides is much better than having 10. If you want to show a couple of bullet points (for example - when listing features of the brand new framework you've created) show them one by one. Make sure it's obvious to viewers which item you're currently describing.
Make sure to have your social media handle on every slide (not only on the first one). Putting it in the bottom left/right corner is usually a good practice.
If you can do comedy well, throwing a couple of jokes is going to make your talk more enjoyable to the audience. But for the love of all that is holy - don't try to make your talk funny by throwing a bucket of GIFs at it.
It never works. There's nothing more awkward than a speaker waiting for attendees to get the joke in the hilarious GIF they've decided to add to the slide.
Oh well, you're one of those people.
You're brave (or foolish) enough to do a live demo/coding at a talk. While live demos can transform a mediocre talk into something greater, proceed with caution.
Three pieces of advice:
- Practice a lot, and then some. Doing live demos is a different game than going through slides and you need to be prepared.
- Make sure that your demo works online, offline, upside down, underwater and in IE3. I'm only half joking. Do not assume that you will have Internet connection on stage. Localhost is like your childhood dog, it'll always be there for you.
- Have backups. If your demo breaks on stage, revert to showing the video of the same thing in action. Shit happens, but a smooth recovery can save the talk.
Seriously, practice. A lot. Out loud.
A common mistake people make is going through the talk only in their head. I hate to break it down to you, but your inner voice is much more articulated than you are. This is extra true if you're not giving the talk in your native language.
Buy a cheap clicker (you know, the slide switcher thingy), connect your laptop to a TV (optional), stand up (not optional) and practice out loud.
If you screw something up, do not stop. You won't get to repeat the whole talk on stage so having those prep sessions at home will make you well prepared to any mishap that might happen on stage.
After you did that a couple of times and you feel prepared, ask someone to be your audience and make sure that they give you feedback. Do not take "it went really well, nothing to add" as an answer. They're trying to be nice, there's always something to improve. If you feel comfortable with that, record the talk yourself and be your own audience.
Once you get accepted to speak at a conference, seeing your name next to all those superstars might make you anxious. Weird thoughts may appear in your head.
Those people are industry veterans, and I'm an impostor. I don't want to do that anymore.
Don't listen to that voice. If your talk piqued the interest of the conference organisers - you belong there. I am personally yet to meet an asshole conference speaker and during the speakers' dinner and other activities you're quite likely to feel welcome and accepted.
If you'd like to be on stage - you deserve that.
Keep on rockin'.