Many people have written blog posts gushing about how wonderful JSConf 2013 was and why you should try to go next year. They're all true. Here's a bigger challenge: try to speak at next year's JSConf.
You can do it. Here’s how I did.
How do you get a slot?
JSConf has a “community” track where slots are first-come-first-served. I wrote my talk description in advance and checked twitter constantly, knowing that Chris might open the slots at any time. If you want it as badly as I did, there’s a good chance you could get a slot next year.
“But I’m not good at public speaking.” No problem.
Watch the videos from JSConf 2012. You’ll see speakers who are painfully shy, too quiet, stuttering, have live demos fail dramatically, and experience everything else that might possibly keep them from speaking. What you won’t see is any booing. The audience is rooting for them, and learning things regardless.
So don’t worry: you’re going to do fine.
“But I don’t have anything to say.” Just find something.
So my talk proposal was actually just a summary of everything I knew about Cassowary at the time. Plus I promised:
At the time I wrote this sentence it was pretty much a lie: I understood the API reasonably well, but I had only used it for simple things, and I had no impressive demos.
So if you have taken my advice so far, you’ve ignored the fact that you hate public speaking and you’ve hounded the @jsconf twitter account so that you could get a speaking slot to talk about something you don’t yet really understand.
So you have a speaking slot. Remember all that nervousness I told you to put away and register for the slot? Let’s pull it back out and face the fact that, in just a month, you’re going to be recorded on video in front of several dozen people. With that feeling in mind, clear out your schedule and make time for preparing your talk.
“Oh crap, how do I plan a talk in just a month?” Dedicate time to ideas.
Four weeks to go: I spent my first two weeks scouring research papers, blog posts, and demo videos for applications of constraint solvers. This was the most valuable and most fun part of my preparation time. I ultimately picked two demos: one I absolutely knew I could build, and one stretch goal that could turn into bonus material.
Two weeks to go: With two weeks left to go, I hurriedly started constructing the first demo. I wrote a lot of ugly code but quickly learned what I needed to do to make it work. I considered refactoring everything to be nice but instead pushed through adding some last features into the existing grossness.
When I ran across bugs that made me want to punch things, I instead spent twenty minutes preparing my slides. Do not underestimate this: even though my slides only have a few code snippets and perhaps 200 words, they consumed perhaps ten hours of time to write, rewrite, reorganize, and test. I highly recommend going with a browser-based html slide deck.
One week to go: My first demo was somewhat working but pretty ugly, and my slides were partially complete. So it was time to start practicing. I rehearsed the core technical part of the talk several times in front of my wife and my coworkers. People tried to give me feedback, but it wasn’t really making it through. In retrospect, the rehearsals weren’t about getting feedback, they were just about getting myself familiar with the slides and where I was likely to get stuck on tricky wording.
The week of the conference: In retrospect, I should have relaxed and enjoyed myself more. But forget that, no one will ever convince you of it. I freaked out and stayed up late working on my second demo and making minor, inconsequential changes to the slides. Up to about an hour before the talk I was fighting bugs in the second demo and hoping I would have it ready in time.
Right before the talk I made one mistake that I can help you avoid: I expected things to be more organized. I thought a conference organizer would come up, decide when the talks should start and end, etc. So when the talk before me ended way late and announced there would be a half hour break, I assumed this was “official” and waited around. But it turns out the community track just had hotel AV people who were there to record whatever happened. Seeing that we were behind, I should have just jumped up, told people to stick around, and started right away. Then we wouldn’t have missed part of the community discussion that was in the next room. Ah, well, now you know.
During the talk I was scheduled against an awesome live-coding demo, and I remember being bummed about how empty the room looked. Maybe I should have picked a cooler title. That’s the end of what I remember, because the talk itself is a complete blur. I look forward to watching the video to see how it went.
After the talk it turned out the audience size didn’t matter. The people who should have been there were there. Afterwords I was stopped by lots of people who were interested in what I had said and wanted to follow up. And Bryan Hughes called it “probably my favorite talk of the entire conference” in a blog post. So that’s a success.
I feel very confident in this prediction: Whatever you decide to talk about, you will find the right audience. And they will be excited to hear you talk from the stage of JSConf.
What to do
So don’t just make yourself a reminder to get a ticket for JSConf. Consider speaking at JSConf!
- The 2013 JSConf EU Call for Speakers is open until June 12th. I’ve already applied. That page discusses all the help they give first-time speakers, so you have no excuse!
- When you register for JSConf 2014, write your description early, and be ready to pounce when the community track registration opens.
I look forward to hearing from you next year.