Speaking At RailsConf

Emily Xie

May 20, 2015

A couple weeks ago, I gave my talk Coding: Art or Craft? at RailsConf, the largest conference for Ruby on Rails, a popular web development framework. I'd spoken before at smaller venues: at local meetups and by teaching classes for Girl Develop It Boston—but none quite as large as RailsConf, which attracted over 1000 attendees. I’d also never been to a tech conference, so I had no idea what to expect. Here’s what I learned about the process as a first-time speaker on the big stage:

1. The Proposal: Dust yourself off and try again

Writing the proposal was not a quick deed. Though I’d been contemplating the topic for a while, it wasn’t until I saw friends tweeting about their submissions for RubyConf, a three-day symposium hosted by the same organizers as RailsConf, that I decided to hop on the bandwagon. I cobbled together an outline over a week of lunch breaks and then rounded out the final draft over a weekend.

I turned in my RubyConf proposal a day before the deadline, only to get a rejection email in exchange some weeks later. I wanted feedback on ways to improve, so I reached out to the organizers. I figured it couldn’t hurt to try. As I wasn’t expecting a response, I was pleasantly surprised when I heard back. Though I originally chalked rejection up to the fact that my submission was either uninteresting or not quite up to snuff, it turned out that the proposal itself was good. It was merely a matter of numbers: RubyConf had few slots for non-technical presentations. They told me to shop it around to other conferences and to submit it to RailsConf as well.

I wasn’t planning on resubmitting to RailsConf as by the time the CFP opened some months later, I’d been too far out of the Rails game with my new PHP job. But one night, feeling particularly adventurous, I decided “why not?” I literally did a copy + paste of my old proposal into the new one, changing only the words “RubyConf” to “RailsConf.” To my shock, my talk was accepted.

What I’d learned from the process is to simply dust yourself off and try again—especially if you are applying for something as selective as RailsConf or RubyConf, both of which had nearly 500 proposals this past year. Your idea is probably great—you should feel empowered to know that if you put enough time and effort into your proposal, you are merely up against a game of numbers—which isn’t a terrible game considering that there are so many conferences out there for you apply to for your debut.

2. Preparation: It’s all about the hours

Talk preparation takes time. For my non-technical talk, it involved research, creating a narrative arc, synthesizing new ideas, forming an argument, and making it all cohere. (In fact, having delivered both a technical and non-technical talk in tandem, I found the former comparatively more straightforward.) It’s a lot to do—so prepare for some serious hours. For me, this meant spending every weekend for a month typing away in the corner of a library.

After I got the content down, I started practicing delivery. Rehearsing by yourself helps, but nothing compares to a live rendition in front of friends who can give you feedback on points that are unclear, places that get boring, or jokes that fall flat. I gave two dry runs of my talk to a live audience; both times, I received valuable advice that led to small tweaks that made a big difference.

Including research and rehearsal, I spent nearly 80 hours preparing my talk. I assumed that I was an abnormally slow worker, but I discovered at the speaker dinner that the hours I clocked were close to the norm. One seasoned speaker purportedly totaled 150 hours, which goes to show that everyone—regardless of their level—was putting in serious time and effort.

3. The conference: It’s go-time!

My talk was on the last day. Because I had already done the work and felt prepared, I wasn’t too stressed save for a couple hours the night before when last-minute moments of doubt set in (“Oh gosh, what if my friends were just being nice to me when they gave me feedback? What if my talk actually sucks!?”) and in the liminal 20 minutes beforehand, where you can’t do anything except nervously mull over your lines.

Stepping on stage almost felt dramatic—the din of chatter died down as I looked out into a wall of faces washed out by flood lights. Particularly memorable was that moment of arresting quietude before my first line. Once I began speaking, however, my nerves dissipated, and I delivered my talk without a hitch. Looking back, I realized there are more reasons to be confident than to be nervous. Attendees self-select themselves into your talk; they are there because they are interested in your topic. No one wants you to fail because watching that is painful--they all want to be entertained and for you to do your best. And if you are standing on that stage, remember that the conference chose you over hundreds of other talk ideas. Before you’ve said a word, you’ve got a lot of people who already believe in you, and want you to succeed.

You have much to gain and little to lose from speaking. So if you’ve been thinking about it, submit that proposal. I’m really glad I did. RailsConf was an incredible experience. I had the opportunity to meet some interesting people—I even ended up sitting at the same table as DHH, the creator of Ruby on Rails, for the speaker dinner! I made friends, got to visit a new city, had fun, and gained new perspectives from watching a diversity of talks. It was an amazing experience for these reasons, but above all, perhaps what was most satisfying was knowing that I took a chance, put my ideas out there, and in return, was able to make a small contribution to an ongoing discussion in tech.