RedDotRubyConf 2014 (RDRC 2014) has just ended, and what a rush! I could literally feel my head expanding from speaking with all the developers from around the world. This is the first time where I had the privillege to be a conference speaker.

I could write about how I enjoyed the talks, and all the cool people I’ve met and learnt from, and how some of us were genuinely worried about Ruby not being able to handle multicore, but I guess that won’t help anybody much.

There was one thing which bothered me for quite a bit.

Where are all the local speakers?

I was pretty dismayed to see a general lack of Singaporean speakers. The speaker lineup was awesome, no doubt. But I know for a fact that Singapore has no lack of talented developers. I personally think it boils down to a lack of confidence. The mere thought of standing in front of 300+ really smart people and presenting a technical topic can be enough to turn any potential speaker away.

I would know, since that kept me from speaking in RDRC 2012 and 2013. After RDRC 2013 (and watching way to many Confreaks videos, I was determined to speak at the next conference. It wasn’t that I particularly enjoyed speaking to a large crowd.

It was more like me aspiring to be like the speakers – simply being able to stand in front of a crowd and share their knowledge with the community. Furthermore, I think many fail to recognise how incredibly lucky we are to have people like @winstonyw, @jaryl, @alaricesoh, @seanxiesx, @yinquanteo, @jmpak and Kevin Yeung to organise a Ruby conference right here in Singapore. And frankly, I think every conference organizer’s hopes to have as many local speakers as possible.

So, here’s me sharing my experience of speaking at RedDotRubyConf 2014, an (awesome!) annual Ruby conference that is held in Singapore.

Step 1: Planning ahead

In reality, I had around a year to prepare. It starts with having a New Year’s Resolution. (Unlike the rest, this one I followed through.) I began by volunteering to speak at local meetup groups. I wish I could tell you that all of them went well, but I screwed up each of them in various (and unique) ways. Which was kind of the point.

After screwing up on various occasions, I started to realise what worked and what didn’t. For example, live coding is hard. Also, don’t do it.

Each talk took quite a bit of effort to put together. But it gave me practice on designing slides, organising and condensing material, explaining concepts in a simple way, and handling questions from the audience.

Another thing which I felt worked pretty well is blogging about bits of the talk that you think might be interesting, and seeing the reaction it gets. It also gives you a chance to really think about the topic as you are writing it.

Step 2: Find something to speak about

What interesting things have you been doing lately? If you are struggling for an answer, then you probably won’t have nothing interesting to speak about either. Again, one good place to search for potential ideas is once again Confreaks. So stop playing Candy Crush, 2048, or any of those time-sucking games. Find. Something. Interesting.

Read the abstracts and pick out the topics that interest you. See how they are written – obviously they are good, otherwise they wouldn’t have been accepted in the first place.

Step 3: Submitting the CFP

Look out for CFPs. Follow the conference Twitter handle for updates. Simple stuff.

Now that you have done some interesting stuff, and have probably seen enough examples, you can start writing the Call for Proposal, or CFP for short. First, start early. Writing the CFP for me was harder than I thought.

Asking for feedback from people who gave talks in similar conferences is also invaluable. For that, I had Sau Sheong and Lu Wei to thank.

Most conferences I know of also allow more than one entry to be submitted. So don’t stop at 1! Here’s mine:

Step 4: Preparing the material

I started around 2 months before hand. Getting to start was tough. Do I design the slides first? Do I work on the example code first?

I found what worked for me was to get a rough outline of the presentation, then develop the rest of the content around it. Also, the process is not necessarily linear. I started in the middle portion of the slides, worked towards the end, then started at the beginning … you get the drift.

Developing the code examples was slightly trickier. Part of the stuff I wanted to present, I sort of knew it would work in theory, but I haven’t tried it out at that point of time. That contributed to some of the unneeded anxiety. When I finally got the code working, I felt a huge weight lifted off. So, have your code ready ASAP. (Mad props to Chris McCord for sharing his Elixir ideas which ended as part of the presentation.)

I was super ready to give live coding another try, despite my failed attempts before. The more I read about other speakers’ experiences, the more I decided that it was out of my league. ScreenFlow to the rescue! I recorded my demos and embedded them in the slides. No context switching, no typos, no screwups.

Here’s my favorite recorded demo:

Step 5: Practicing

At this point of time, I had 2 weeks left, and getting slightly panicky again. Now, the focus was on the script.

Now, simply writing down the script, and thinking it sounds good isn’t going to cut it. There are a couple of reasons for this. Unless you mouth the words out, you are not going to realize the words that you mis-pronounce, or sentences which just sound awkward when you say it out loud. I had to modify a substantial part of my script after I went through this process.

Once I had that ironed out, it was time to test it out on a live human audience. The victim in this case was my wife. She had to go through at least 5 rehearsals, which I think isn’t too bad (she might claim otherwise). The comments that resulted were hard to swallow, but I knew they were right. So I kept going until she gave me the green light. That was just the day before the conference.

Before the Talk

I was totally looking forward to speaking. Also, the talks before mine just flew by. Protip: Go to the washroom before your talk. Because …

Payoff

My colleagues at Neo didn’t sleep throughout my presentation, I managed to get a couple of questions from the audience, and no one threw me out of a Ruby conference for talking about Elixir. By all measure, it was a success.

The other nice side effect is people come to you, instead of having you go to them. I have to work on randomly approaching somebody and “OHAI I’M BEN!”. I would rather much prefer people approaching me. Unless they are going to throw me out of a Ruby conference.

Having people tell you that your presentation didn’t suck is also quite comforting.

My Slides

In case you want to check out my slides, they are on Speaker Deck.

Ending Notes

Preparing for a conference talk took way more effort than I thought – just like any software endeavour. But, it was well worth the effort. I particularly enjoyed meeting the people after my talk who shared similar experiences, and not to mention a nice sense of accomplishment.

I’m writing this to encourage anyone who might be sitting on the fence with the CFP to just say “screw this, let’s give it a shot”. Who knows, it might be the best thing you did for yourself.

On to RDRC 2015!