| « Introducing a new error handler for PHP projects | The best way to improve team productivity » |
There’s been a lot made in the last 24 hours about the process of submitting and accepting conference talks, including whether or not such talks should be written beforehand. There are many valid points of view on the issue, and here are a few of my thoughts.
When it comes to creating conference talks, I typically start around November and come up with a few new abstracts focusing on topics I think or know are important in the PHP community. My general wheelhouse is focused mainly on the beginner to intermediate-level developer; rarely do I offer an advanced talk, mostly because I believe that conferences are best suited to the beginner and intermediate level developer.
Even though I may create new abstracts, I rarely go completely off the rails and step into a subject area I’ve never taught about before. It may be a good idea in code to never repeat yourself, but when it comes to teaching developers, repetition of the same themes (even in different packaging), is crucial.
Much of the current discussion surrounds whether or not the talks have been “written” before they’re submitted, and whether or not we should require developers to write their talks before submitting them to a conference.
The problem with the current discussion is it focuses on having produced slides as the basis of a talk being “written” or not. To me, this is a mistake. Slides are useful, but they are not in and of themselves a talk. If writing slides is the equivalent of writing a talk, then you don’t need me as a speaker; I can just email my slides to your attendees.
Slides help us to do things that are difficult to otherwise accomplish, including providing visual aids for the listener. But I could accomplish the same thing with a live coding demonstration or a white board. I don’t need slides to give a good talk.
Instead, I focus on the things that makes a great talk: mastery of the subject, concrete and specific examples that the audience can internalize and use, and a little bit of humor.
I don’t submit talks that I couldn’t give on the spot if asked. In other words, when I submit a talk I’m submitting something that I know intimately, in depth, at the time of submission. Even though I’ll do additional research to make the talk even better, if a conference organizer called me and asked me for a five minute sample of my talk, I could provide it with no questions asked.
Submitting a talk on a topic that you have little experience with does a disservice to your potential audience. This is where talks become soft and audiences are left wanting. When you’re not the expert in the room, your audience feels cheated of their time and money. Being the expert doesn’t mean being a know-it-all, but you should know enough to know more than your audience!
At the end of the day, giving a talk is a skill. My first talk bombed terribly, and I practiced giving it for hours beforehand. After more than one hundred speaking engagements, I find myself practicing less (but always practicing), and delivering far superior talks to that first failure. And yet, even today every time I give a talk it gets better. The last time I give a talk will be better than the first, the fifth, the fifteenth.
I think this issue essentially boils down to respect. When developers submit a talk, they’re making a promise to the conference organizer and their potential audience that the talk will be well-prepared, well-written, well-researched and well-executed. Writing your slides in the hallway two hours before your talk is disrespectful to the audience that paid a lot of money to be there, the organizers that honored you with their selection, and your topic. Submitting a topic that you have no experience with is similarly disrespectful.
How do we make things better? There are a variety of ways, but all of them have tradeoffs. We can choose not to have an open call for papers, and instead invite speakers, but this can stagnate a community. We can demand slides up front at submission time, or give greater weight to talks that have been given before, but this limits the pool of potential talent to those who have spoken before. The idea I like the best (but haven’t seen proposed) is a true call for PAPERS – requiring 500 to 1,000 words on a topic to be submitted along with the abstract. This would cut down submissions, but also cut down junk submissions, and have the effect of showing a reasonably decent preview of the talk.
After all, that’s what conferences used to be: the presentation of research papers by academics who had done tons of work beforehand. We still retain the original title (a call for papers) but none of the rigor or high expectations. Maybe we need a decent dose of both.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 3/3/2015 at 8:04 am
Anna Filina (@afilina) wrote at 3/3/2015 9:31 am:
Although there are junk submissions, these are typically rare. Nonetheless, asking the speakers for a brief outline can at least prove that they have strong knowledge of the topic and is not too much of a strain on the speakers.
One thing about level of attendees: my conference gets 1/3 beginners, 1/3 intermediate and 1/3 expert attendees. A great conference needs some expert talks too.
Oh I noticed that my article within the same period on that specific topic was not mentioned. In case you’re interested: http://afilina.com/should-conference-talks-be-written-in-advance/
Brandon Savage (@brandonsavage) wrote at 3/3/2015 9:38 am:
Thanks! I missed your article somehow. I’ll update mine with a link.
Sam Tuke (@samtuke) wrote at 3/3/2015 11:26 am:
Great post, thanks!
| « Introducing a new error handler for PHP projects | The best way to improve team productivity » |