Noel Rappin Writes Here

I’m going to be conducting a few of the tracks for this year’s RailsConf, specifically the Novice, Testing, and Crafting Code tracks. I’m very excited, this isn’t an opportunity I’ve had before.

What I want from all of you is awesome proposals. I want to have to make hard decisions. I want to be inundated with all your amazingness.

Because I want to hear from all of you, here are some opinions on how to best present yourself in a speaking proposal.

Yes, You Can. In Fact, Please Do

In response to my initial round of begging for proposals on Twitter, somebody commented that they didn’t think they were the most qualified person to talk on a particular subject.

To which I have three cheesy but true responses:

• A conference that was limited to only people that really though they were the most qualified person to talk would be depressing, if not completely horrific.
• You are absolutely the most qualified person to tell me what you think on a particular topic.
• This is how you become qualified. You study something, you teach it to other people.

In other words, please don’t let that stop you. If you don’t submit a proposal, you have zero chance of being accepted.

(In a similar vein, here’s a talk I once gave about how everybody has technical writing in them. Video’s poor, but audio is okay.)

I can’t speak for any of the other conductors, but I’m also looking for people who want to give shorter talks (10-15 minutes) with the idea that we might have a session that is 2 or 3 awesome shorter talks. If that interests you, definitely mention it when you submit.

What Should I Talk About?

Let’s say, for the sake of argument, that I’ve convinced you that you should submit a proposal to RailsConf or the conference of your choice.

But you don’t know what to talk about.

Here are some ideas. This is the kind of process I go through when I try to get ideas for a talk, though by writing it down I’m making it more systematic.

Think of these as prompts and use them as starting points to find an idea for a talk that excites you.

These are far from the only seeds for good presentations, but it’s a start.

• What is the last thing you spent more than 15 minute trying to figure out?
• What is the last tool, process, or code you wrote that made you excited enough to tell somebody else?
• What was the last question you asked a more senior developer?
• What was the last question a more junior developer asked you?
• What do you wish somebody had told you a year ago?
• What was the last blog post or presentation in the community that you disagreed with?
• Do you have a hobby or interest that informs your work?
• What is the best line of code you wrote this week? How could you tell?
• What was something you did for the first time in your last project? How did it work out?
• What was something you did for the last time in your last project (or something you stopped doing for your last project)? How did that work out?
• What is a tool or process you would like to learn more about?

Once you have an idea, try to answer these questions about it.

• Who is the audience for this? It often helps to think of one specific person that you’d like to talk to.
• Is there a story here? What is the beginning, the middle, and the end?
• If a person watches this talk, what will they be able to do after the talk that they would not have been able to do before?

UPDATE 1/19 It seems worth pointing out that I’ll be speakng at MountainWest RubyConf this year. The talk is on Smalltalk, and it’s a direct result of a presentation I saw and wanted to respond to (I didn’t actually disagree with the presentation, but I had another take on the topic). Also, I know for a dead certain fact that one of the other speakers is a much bigger Smalltalk expert than I am. And I am going to take may own advice and not let that bother me.

What Makes A Great Submission

I have opinions on the actual submission – watch for updates after I dive into the actual submissions.

I’m going to share with you the first rule of submitting anything. This rule is applicable to any situation where a person has to spend a lot of time evaluating submissions – resumes, conference proposals, writing submissions all included.

Rule One: The person reading these submissions is always looking for a way to save time. Don’t give them a reason to reject you out of hand.

That means: if they have a format, hit the format. If they have a word count, hit the word count. Spell words correctly. Write in grammatical English. Sure, the reader might take extra time to figure you out if you bend the submission rules. But why take the chance?

Have somebody else read and edit you if you can. Find a buddy and read over each others. (I’m willing to be your editing buddy – contact me via this web site).

In most cases, the talk descriptions on conference web sites are taken directly from the submission – look through some, and see what makes them compelling.

Specifically for conference proposals:

• Make sure you specify: a) who the audience is, b) what they should expect, c) what they will learn.
• For a long time I was afraid to give out details of my talk in the abstract for fear of “giving stuff away”. That was a bad idea. You need to give people an idea of what to expect. (The RailsConf CFP has a details field that lets you put in details for the organizers and not the abstract – use that)
• You don’t have to explain why you are an expert, but if you have a particular reason why you might have insight into the subject, mention it. This reason is not at all limited to you having vast experience on the topic.

Good luck, and I look forward to hearing from you.