August 1, 2011

Giving a Talk at a Technical Conference

Lessons Learned: By Issac Kelly

I gave two talks, and sat on one panel at PyOhio this weekend.

Honestly, It's more than I expected. I didn't really expect for both proposals to be accepted when I submitted. It was fun, but a lot of work. I want to share a couple of things about giving talks while it's still fresh in my head.

Lesson One: You should submit a talk, or panel, or proposal.

There are a lot of reasons for this, but the most important is this: you know stuff that other people don't. You might not believe it, but you do. You might know about how to deal with grumpy clients, or how to write a report that is fun to read, or how to model things in the real world that move really really fast. I don't know how to do any of those things, so I'd like to hear about them. I love this lightning talk from pamela fox on the topic*

Some other reasons: It's a good way to meet people. It's cool to brush up, or formalize your thoughts on something. It's nice practice for talking to less receptive audiences (bosses, clients). People think you're an expert even if you're not.

Lesson Two: If you talk people are going to think you're an expert.

You don't have to be an expert to give a talk. You might even have a better perspective, because you're not an expert. This doesn't change the fact that because you have gusto and will stand in front of a small mob, that you know your foreign keys from your linked lists (well..and you better know that at least). People will ask you questions you don't know the answer to, don't be afraid to say "I don't know"; that's good practice too.

It's totally cool to know, or not to know. Somebody there might know, and pitch in, or not, be cool, it's fine. If this makes you uncomfortable, practice this. Go to the mirror, and say "I don't know off hand, get me your email after the talk and I'll look it up". "I haven't run into that before, does anybody else here have advice for un barring the foo?". "That's outside what I've used beancounters for, but I think that somebody at Google was doing it". "That might be the case, we can talk about it after if you want".

Lesson Three: The quality of the talk is in proportion to the level of preparedness

You might know a lot about a topic, you might know a little, and commit to at least preparing enough to talk on. Whatever the case, prepare. I didn't write a script, or really even guess at how long my talks would take. I wrote an outline, committed it to slides, and went off the cuff. I honestly spent more time making my presentation tool (which, is pretty cool) than I did preparing my slides and talk.

I went to re:build conference on Friday before PyOhio, and it was really apparent that these fine folks had put in a much more considerable amount of time preparing for their talks, making slides that were presentation compliments, not outlines, and really knowing their content (or faking it really well). I was thoroughly impressed, and then embarrassed because I knew that I wouldn't be able to do that well the next two days.

Going Onward

If you're going to prepare for a talk, and don't know where to start, find talks online. Lots of conferences record and provide videos of all the talks. Watch a lot, and take notes on what you like, and copy them.

I'm slated to give two talks at DjangoCon** which my goal is to be better prepared for. Some conversations, and my previous talks I think will help, as well as having seen several awesome talks at PyOhio.

* Pamela Fox: No, Really, I'm Shy:

** Teaching Django to Comrades, and Building APIs with Django and Tastypie