I don't remember the initial impetus for the insanity—I'm sure it was something innocuous like a tweet that made me envious, an aspirational comment from an acquaintance, something—but I got it into my head that I should be "doing" public speaking. I enjoyed going to conferences, but my company would only pay for so many: hotels and flights and tickets and time off all add up. So, I figured: public speaking. I could try that. I went to a workshop at my company for public speaking in the context of giving better internal presentations and I thought to myself, "I think I can do this. I have an outline for a talk already! I must be capable of this."

And... wow. To this day with a number of successful talks under my belt, domestically, internationally, I still don't know what the fuck I was thinking. Rather like thinking I might be able to join the track team in high school, thinking learning Russian would "Be pretty easy I bet", dying my hair blonde from a box I bought at a drug store, and numerous other catastrophic failures that I've had in my lifetime the ignorance I had in those brief, darling moments in which I started applying to conferences was precious, like a child that is cute but that you can tell it will grow up to be quite ugly.

Preparing Talks: Tips from a Nervous Speaker

People sometimes ask me about speaking at conferences. I imagine this is because they, like me, find it awe-inspiring and batshit that certain people, for whatever reason, occasionally (or regularly) stand in front of crowds and educate them on things. I assume they ask because notoriety seems rather glamorous from afar, as does being perceived as an expert, as does working for such and such company, which is what people who stand on stages all seem to do.*

I always aim to serve in whatever small way I can to the collective knowledge of the brain-net-mesh that is The Internet, so here is, without fanfare: my own horrific way of coming up with 25 minutes of content that people then watch without seeing the week-long unwashed, unkempt, dungeon creature that is also me stooped in some weird corner at 3am in the morning the day before she flies out to give it. I am nothing if not honest. You may read this and think, "Wow, uh, never mind" or, worse, decide that this still sounds like something you think is a worthwhile pursuit. To be perfectly honest either way I am so, so sorry.

Step One: The Proposal

As I often start by staring at the submission page for a conference I'd like to be a part of, we'll call this Step One. There are two routes I go down here: either, "What do I want to learn", or, "What do I have to teach."

"What do I want to learn" is often easier to generate ideas for, but harder to create a talk around. This is because not only will you be creating a talk of your findings, you have to learn a new, challenging thing in the process. For this path when I'm writing my abstract I do this: I write a fictional story in which I know how to do a thing that I actually don't, but I wish I did. "And at the end of this, you'll know how to do it to." An example of this for me was Type is Your Right!, in which upon acceptance I panicked for three months teaching myself about web typography and progressive loading techniques. These talks tend to induce a great deal of stress but they are also talks worth being very proud of. The immense societal pressure to learn This New Thing will, of course, force you to do so even if you are perhaps not the best at doing this without external pressure.

"What do I have to teach" is a question that for whatever reason in my experience people have trouble asking themselves but I encourage this introspection: these talks are often easier to give, as you've already learned and understand whatever it is you're shaping your talk on.

We all know how to do things, as elementary as they might feel to us. If you have spent hours over an incredibly frustrating problem only to find you spelled something wrong breaking your build, or example, or a time you stayed up all night because you accidentally deleted an entire project, or any other remix of the multitude of terrible things that can happen with computers: Congratulations, you've learned things. You can teach those things to other people who are hoping they don't end up in that situation.

After you've written up your small description of what you want to talk about you come to the part of the form that says, "About", meaning, about you. Who are you.

One of the questions I received was how you decide whether or not something is worth presenting at all, which is a good question. And the "About" part of that form is an important part of answering that question. Why are you giving this talk, anyway?

Should you look over your talk abstract and not see yourself in it, stop. You should ask yourself, "Could literally anyone give this talk?" If you feel this way after writing an abstract reflect and think upon what it is that you bring to it.

My very first talk was on JavaScript and prototypal inheritance. It wasn't a very good talk. It was my very first one. One must start somewhere. I was not inside the proposal at all, really, which I later learned was something to watch out for later.

What made the talk mine, in the end, was discussing the various different ways in which you see prototypal inheritance in the wild—the specifics here don't really matter so we can skip them—and how different learning styles means that different methods work for different people. As a designer, where oft times the method of creating the solution is adjacent and unimportant in comparison to the solution itself, creating a talk in which I had no thesis on the right way to do something and instead proposed that these are all possible solutions to the problem of passing along information felt very intrinsic to me, as a human, as a designer, as a learner, and it made my talk feel very much mine.\*\*

(It also had cute pictures of my grandparents and how they both learned, as their nearly polar-opposite learning styles served as parallels to the technicalities I went into.)

No one knows what it's like to be you, in your experience, doing what it is you do. There are people parallel to you, doing very similar things, trying to do them better, who can benefit from what you've learned, you can benefit from seeing someone like themselves on a stage. Once you figure what that thing is, you have the granules of your talk, your blog post, your whatever, your story.

Sending it around to your close tech friends and repeatedly asking DOES THIS SEEM INTERESTING? WOULD YOU ATTEND THIS IF IT WAS MULTITRACK? WHAT DO YOU THINK YOU'D LEARN IF YOU WENT TO THIS? isn't a bad idea either.

Step Two & Three: Writing and Researching

Building a good talk starts with a story. When it comes to cadence I like to arrange my talks thusly:

If you remember five paragraph essays from high school this is not dissimilar—consider it a lazy person's way of creating a story arc. There are so many great talks that don't follow this structure. In fact, if you have a good idea, fuck this structure and go with whatever you came up with—it's probably much better. This is just an option. Normally my fallback option when I'm nervous.

The introduction is for getting pleasantries out of the way, introducing the problem, and sharing the "high" of the talk: what people are going to get out of it. The problem is where it's doom and gloom: We don't know how to do this well, and golly gee, isn't it the worst. The high is a glimpse into the promised land at the end of this 25 minutes in which they will know the solution, have immaculate understanding. Or they'll finally know how to write a callback. Whatever it is you're giving the talk on.

The middle is the how, the substance. The substantive answer from how one goes from the nothing to understanding.

In the ending, you recap. They've been enlightened, bettered, from being here, learning from you.

I say "research" as part of this section, as often time you are doing these do things simultaneously.

As for the actual how of writing talks: I don't write in Vim, or create my slides alongside it, or anything else. I write my talks in a dumb text editor, because my text editor is pretty nice. I only write during this period. I don't even sketch, unless it's to write on paper instead of on my computer. I write down every word I will say, down to the letter, even the "Hi my name is Helen", as awkward as it looks on paper. I write down the jokes I'll say if I can't get my computer to work. I write down all of it.

After I've written it all down, literally everything, I read it. And then I read it again. And then I read it again. And then I read it again. I edit edit edit.

Then I do a part that I hate: I share it with people.

Step Four: Sharing Your Initial Draft

An important part of writing your talk is getting other people to look over it, particularly if they're the sort of people you might expect to find in the audience. I've had entire swaths of my talk just be wrong. I've had typos. I've had people tell me that my talk made no sense without pictures, can I please add those. I've had people tell me I sound condescending. All of this was good to know before I gave the talk.

I'm not the best at receiving this sort of information synchronously. In fact, I didn't let anyone read over my college essays because I was so terrified of the idea of having to sit there and watch them give me feedback in real time. While I've gotten better at this—I no longer quake in front of clients when I'm showing design proposals, for example—I still often prefer to receive talk feedback asynchronously. Writing down your talk in its entirety allows you do this: you now, in essence, have a blog post you can share with others, and about which they can email you later. (It's even okay to say, "If you'd be willing to write up your thoughts in an email that would be preferable." People generally will comply.)

I generally share my drafts by dumping them into a private gist. You can do this in any number of ways—private Google Doc, Medium draft, whatever—whatever if your preferred method of receiving feedback.

Step Five: Creating Your Slides

This step is near the end on purpose. If I have a good story, feel really great about what I've created thus far, have gone over it a bunch, received feedback from people... making slides goes pretty quickly. They just fall in to place.

This also means THEY ALWAYS SEEM TO HAPPEN AT THE LAST MOMENT AHHHH.

Making slides is always part of anyone's \~\~creative expression\~\~, so I won't go into typefaces I use or anything like that. (Find ur own damn typefaces! Just kidding, we all just like different things.) Instead, here are guidelines and random tips I have stashed away that you can cherry pick based on your needs:

• Slides with too much content are lame. Say a lot, but give the content on your slides room to breathe. Pull on the important parts. See last point for how this relates to code.

• Just because they're slides doesn't mean you can't have illustration, animations, and other ways of expressing your content. They’re slides. You have your content, you’re basically done. Make these fun to do.
• It’s okay to have blank slides. Sometimes I just want to say something and having a slide feels superfluous. Sometimes I actually want the audience to pay attention to me, not the slides. By putting up a black slide, the audience turns to you naturally because there’s nothing else to look at.
• Big code blocks are really hard to parse. Throw up a ton of code and you lose people since conference talks aren't generally how we digest code. As a few alternatives you can a) only throw up a line of code, or if that's not possible b) throw up a block with the line that’s relevant highlighted, and highlight lines or blocks as you talk about then. (Blog post, not a talk, but I love how this post puts the created elements alongside the code so you can see them in tandem.)

I tend to make mine in Keynote. Reveal.js is also popular. Spend some time poking around for something you like, but not too long. Honestly, so unimportant, which is why I'm still using Keynote, really. Who cares what my slides are made in?

Step Six: Practice

Now you get to awkwardly talk to yourself for days straight in empty rooms! Hah. Hah hah hah.

If this article thus far has not already illustrated this properly I will step off this slow-moving airport walkway to tell you that so much of this process is just like you with an instrument you never got very good at in middle school practicing alone, particularly at the beginning. You might practice a great deal and be all right. You might not practice enough and be... well, bad. On your first try you will not be a concert pianist, unfortunately, and it is quite likely one of your parents will shout downstairs angrily at you to "Shut the fuck up because if I have to hear Für Elise one more time I'll kill myself". As one of my high school English teachers once said after a very odd story in which she cursed out a man in Japan because he offered her a seat next to her husband on a bus which she interpreted as an act of patriarchy, "Life, she is a lonely journey." As is preparing conference talks by muttering them in your hotel room to yourself in a panic 18 hours before you give your talk.

Which is all a long way of saying that the first time you give a talk it was be absolutely awful. I've given a fair number of talks at this point and honestly, every time I give a new talk for the first time, it's just plain bad.

Rehearsing by yourself is an important part of this. You should give it a few times to yourself in a low-stress situation, and you should time it to make certain it matches up with your time slot—overshooting your time slot can be construed as rude if you mess up other nervous speakers' starting times, and no one really pays attention to the talk that's between them and lunch.

The first time you get through your talk out loud you'll most likely babble through it incoherently, so do it twice more to get a more realistic sense of timing. Then, if you can, give it standing in front of a significant other or best friend with your slides to get a better sense of cadence. Then, mostly importantly, give it to a group of people—a local meet up (local meet ups always seem to need more speakers), or to your coworkers during lunch. The more you do this, the less nervous you'll sound, and this is good. Refrain from asking your significant other four to six times whether or not your talk is "interesting", as the deflated "yes dear" will not help your confidence and will probably lead to one of the more ridiculous fights you'll have as a couple.

Step Seven: Day-Of

Day-of is a little nerve-wracking. I try not to consume caffeine as a general rule, as it tends to make me yet more jittery. If that were possible.

I also like to pick an outfit that I feel really confident in, and that I don't think I'd fall over in. (Heels are a good example: I am fine with wearing them, but typically not a brand-new pair.)

I also do my makeup and hair, because you're gonna be on stage. You should look amaze, girl.

Some other things I like to make certain are in order:

1. All notifications are turned off.
2. Talk is backed up somewhere like Dropbox or iCloud or a USB stick.
3. My desktop background is something nice.

If you're speaking, it's also okay to hole yourself up in your room after your tech check to be quiet and alone before you give a talk so you aren't a babbling, gross mess in front of other people. And after you've given that talk: enjoy your wonderful Cloud Nine euphoria.

Writing Emotionally Tough Things

Some talks are emotional. A eulogy, for instance. Sharing story of harassment. Sharing any story where the base note is one of tragedy, really. These stories unfortunately exist in tech, as tech is merely a subsection of the human experience.

Under rather sad circumstances at the beginning of the year I had to help someone prepare a eulogy. The person giving it ultimately printed it in size 24 font, broken up with memes to cheer herself up as she gave it. Pure genius, really.

Step Eight: Later, and On Improvement

You've put all this damn work into your talk. You should consider giving it again, assuming you enjoyed the process. After giving talks I like to see what stuck with people on Twitter and what I remember from the talk itself and make improvements—modify where cadences were off, put in pauses where I should chill out and drink water, remove phrases that I saw I used too much, over and over. Stuff of that nature.

It's okay to give the same talk in multiple places. Lots of the big folks do; making talks takes goddamn ages.

If you're looking to improve, part of this process involves watching recorded videos of you speaking, as terrible as that sounds. It is awfully cringing but worth it to learn, say, that you throw you hands around a lot unnecessarily, or you have a very odd resting face that could be construed as a smirk, or any other of odd things that, were you aware of, you could have fixed.

Giving talks is pretty stressful. It's also fun, and an interesting way to grow. Giving talks has gotten me jobs, has helped me meet new people, and has helped me make some incredibly close friends who I would have never met otherwise. You get to travel places you might have have afforded otherwise, and allows you to see cities the way the conference organizers see them: as the beautiful places they are.

(Ah, that must have been the tweet I read in the beginning.)

f you write one after reading this, let me know—I wish you the best of luck in everything. To wrap up, here's my very first conference talk where I followed none of my own advice. Ah to be young and naïve again, no?

If you read this and though, wow, she seems competent, I have two talks I've been on the circuit for: How to Get Designers Into Your Codebase and Type Is Your Right!: Performance and Web Typography. Send me an email if you think they'd be a good fit for your conference.

* Hah! Except me. I work no where and know nothing.

\*\* I also straight-up called my grandfather a nerd in this talk. It's like, the opening line. I'm terrible progeny.

Tags

• conferences
• learning