Tips On Submitting A Conference Session

In the last 3 or so years, I’ve had every conference submission I’ve entered, rejected. Now that doesn’t mean I haven’t spoken at any conferences – I’ve been invited to a handful and have had a ton of fun at them. But for every conference that I’ve submitted a session too, I have not been selected. It’s not fun being rejected 6+ times in a row. The worst part, though, is not getting any valid feedback on why. I ranted about this for a while on Twitter yesterday, and got some interesting feedback.

The Worst Part

The worst parts of the constant rejection include not getting any feedback on why, and the constant growing self doubt. But the absolute worst rejection was from CodeMash last year, where they passed me up in favor of some other guy that wanted to do a Marionette session. I heard reports that it didn’t go well… and they chose this guy over me, the creator of Marionette. That one still stands out as the most crushing rejection.

But enough self-pitty-crap. You’re here the find out WHY and how to fix it, right?

The Submission

I ended up posting one of my recent submissions to a gist so that I could get some actual feedback. This is the basic session submission information that I’ve been using for a while now. I change it up from here, based on the specific talk that I’m going to give, but it generally looks like this:

Scaling JavaScript Apps With Backbone And Marionette

Nearly everyone understands how to build a simple JavaScript application these days. From the classic “Todo” JavaScript app, to simple forms-over-data jQuery apps, we’ve all been around that block a few times. With the recent explosion of JavaScript MV* tools and frameworks, though, many of us find ourselves in over our heads, looking at patterns and practices that work well for small applications and pages but fail when scaling to anything substantial.

In this session, Derick Bailey will give you an introduction and walk through of many of the patterns and practices that your JavaScript applications need to be scalable. You’ll learn why copying Ruby on Rails’ pattern of “Models”, “Views” and “Controllers” folder names is wrong for scaling JavaScript apps, and how to correct that . You’ll learn about the necessity of separating the various concerns of your application. You’ll learn about patterns that aggregate and coordinate functionality from other parts of the system, how and when to properly decouple disparate areas of your application through messaging patterns, and more. And all of this will be illustrated with Backbone, MarionetteJS and additional plugins and patterns that can give you an edge in creating scalable applications in JavaScript.

I asked people to tear this apart for me, and tell me what I have been doing wrong. I got exactly what I wanted, and I have a lot of great tips to move forward, now. 

The Raw Responses

There’s a lot of useful tips in the raw responses, and lessons that can be picked from the responses. Rather than just trying to summarize things, though, I’m just going to post the responses directly and add my reactions.


Ok, Scott’s probably right. My beard is amazing. But it’s probably more likely:


Here’s one of the problems: semantics. “Scalability” is an over-used and abused word these days. When I say “scalability” in that abstract, I mean scaling to 10′s of thousands of lines of code, dozens of feature areas, sub-applications and general code size. I’m not referring to number of users since this all runs on client-side, one-person-at-a-time browsers. 


Dually noted, and something I need to clarify in my abstract.

 

This is more likely the largest issue, and is the most common thread of feedback that I got. I spent years learning to take the emotion and extraneous fluff out of my written communications because I worked for large corporations where CEO’s wanted logical justification for me spending $100,000 on servers and software. Hand-waving doesn’t go over well in that environment, but apparently it’s what you need in a conference submission.

 

Rob Conery responded to my gist, with this:

##Taking The Suck Out of Javascript with MarionetteJS

Many have heard of Single Page Applications and, even though most of us in the room might not admit it, have experimented with the idea late at night… only to face the inevitable self-loathing and vacant, soulless feeling the next day. In this talk Derick Bailey will show you a happier path for building Single Page Applications, using Marionette together with BackboneJS.

Marionette helps to structure your Javascript applications – doing the things you don’t want to do (or have tired of doing thousands of times over) – and it won’t leave your code feeling bloated and lifeless.

This sparked a small response line in twitter:

Screen Shot 2013 03 15 at 10 36 05 AM

Even if it bums people out, it’s a much more exciting and entertaining abstract. I would go to this session.

 

hmm… I’m considering this, though I think Jon Skeet might have problems with me claiming to be him. :D

 

Also very true. Anyone that has read me blog or articles knows that I have a hard time being concise. I definitely need to work on the length of abstract, which would also help move it toward the goal of more excitement. Less to read means I have to pack more information and punch in to fewer words.

 

In a separate email conversation, Steve Smith (@ardalis) had this to say:

Rob’s comment is great. Short, exciting, attention-getting abstracts are the best, but they’re not easy to write. What’s at least as important to those selecting sessions for an event is the speaker themselves. If you’re well-known, especially for the topic, that matters far more than the abstract. It’s also helpful to include your speaking background, so that those who don’t know you at least know you’re not new to speaking. Including ratings can help, too, as in: “Presented a similar talk to 100 developers at XYZ code camp and was rated 9.2 out of 10”

My first pass at abstracts usually look a lot like your initial one, which is kind of like the standard Microsoft product naming convention of describe-what-it-is-in-general-terms. If I’m submitting to something I already know I’m accepted for, I usually won’t spend a lot of time trying to sex it up, either (like, for a user group, for instance). But for something like TechEd or any other larger event where I don’t necessarily already have an “in”, I’ll try to spend more time making the abstracts more exciting, and also demonstrating my past experience.

There’s a lot of great summary in here, for sure. I’m not sure I buy the “celebrity” angle at this point, though. In spite of being invited to speak about Marionette (among other things) and in spite of Marionette being the most watched Backbone framework on Github, with my name all over it, people still reject my sessions in favor of other people. 

Unless you’re Jon Skeet, Addy Osmani or Paul Irish, you’re going to have to beg your way in to most conference submissions. You’re going to have to pay attention to the detail and make the submission exciting, or you’ll be passed up in spite of your name being all over the project that they want to hear about.

 

Lastly, @kellabyte capped it off with a dose of reality for all of this advice:

 

While this is true, I’m grateful to have received this feedback! This is infinitely more useful than the generic, patronizing “we had too many great submissions to choose from” responses that conference organizers like to send.

What Other Advice Do You Have?

I know I have a lot of work ahead of me to improve my submissions, and I’m still looking for more advice and more feedback. What else would you add to the conversation? What other tips and tricks do you have? 

I don’t want others to have to go through this. Help us all learn from your lessons and patterns in successful session submissions. Post in the comments here, or in a response blog post. Just be sure to share your tips with the world so that others can hopefully avoid the mistakes and learn from the successful lessons.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs SignalLeaf.com - the amazingly awesome podcast audio hosting service that everyone should be using, and WatchMeCode.net where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in AntiPatterns, Community, Education, Retrospectives. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • I like the direction Rob went in with his approach, but agree wholeheartedly with Kelly that saying “JavaScript Sucks” isn’t the best approach. I try to aim for exciting, not alienating. Tongue-in-cheek or not, lots of time devs are marking multiple session they want to attend in a time slot at a conference, and not annoying them unnecessarily keeps you in the race….

    • To be fair, I think the spirit of the “Take The Suck Out of JavaScript” part was that many developers can identify with stumbling through something and ending up feeling like what they built sucks. As in, “I’m not an expert on creating scalable js applications, so mine kinda suck.”

      That’s how I read it anyway. It made the talk sound interesting and helpful to me, not really like it was accusing JavaScript of sucking, but identifying with “how I feel” about my current state or something.

  • Dennis van der Stelt

    Put some overly hyped keywords in there : Azure, CQRS, Event Sourcing, MVC4, ServiceBus, Typescript, NoSQL, etc, etc. And indeed, keep it short, but just enough to let people know what it’s about.

  • Edwin G. Castro

    It is unfortunate that your original abstract isn’t getting you selected because it gives me the information I need to decided whether I want to attend your talk or not. Then again, I don’t put a lot of emphasis on “sexiness”, I prefer to let the quality of the content capture my interest. Please don’t change the way you communicate. You’re better than just about anybody else I’ve read or listened to!

  • Have you seen Jim Holmes’ post on handling rejection? I know it might be a sensitive article, considering your rejection by CodeMash, but he makes some good points and you guys play for the same team ;)

    http://frazzleddad.blogspot.com/2012/10/handling-rejection-from-conferences.html

  • marcusswope

    I understand your frustration with not getting any feedback, but I can sympathize with the conference organizers who probably get so many submissions that it’s not feasible for them to write up a critical analysis on every submission that they don’t accept.

  • Peter

    Honestly it may be your topic. Try something more general or generally helpful, and you’ll bat better than 0/6.

    Side note, the idea that the creator of a framework is passed over for someone else speaking on the same topic is terrible, sorry.

  • Jon Skeet

    Feel free to claim you’re me, so long as you also claim you’re you. If nothing else, it’ll cause some interested confusion.

    My personal philosophy has been to gradually make my conference abstracts sillier and sillier, until people start rejecting them for being too silly. That hasn’t happened yet.

  • Michael L Perry

    Get to know the conference organizers personally. It has worked for me on more than one occasion. And if you still get a rejection, you at least have an avenue to ask for candid feedback,

  • Derek thanks for sharing your experience, and insights on this process. I just submitted my first talk to CSS Dev conference, and tried to take some of what you said/learned into account with my abstract.

  • If I were you I be happy

  • Very impressive article. I have read each and every point and found it very
    interesting

  • nice. i love you

  • Get to know the conference organizers personally.