Are Conference Talks Getting Too Soft?

For a few years I’ve participated in various conference CFP processes, and have been asked to speak via CFP submissions (I speak at about 10 conferences each year). Then after the conferences are over I’ve read attendee feedback about the content shared by speakers, including myself. This has caused me to take a second look at talks in general, and to take a closer look at my own talks.

To go into more details, I’ve read and heard feedback from attendees who voiced concern due to the high number of talks that border on being too “soft” for the topic area they cover. Ultimately they are asking, “Where’s what I paid for?” which may be a valid question.

Don’t get me wrong! I’m not saying that all talks should be highly technical, or that soft talks do not carry value. Instead what I’m concerned about is whether talks in certain topics are covered too soft or abstract, or perhaps are a bit shallow to allow more broad coverage, and do not carrying their weight on a conference schedule.

Case of Novices

We all boast that conferences are great places for beginners to learn quickly. I know when I was learning PHP I often felt like I was drinking from a fire-hose at a conference. But the content I heard at conferences taught some items I could use immediately, and the rest became fodder for learned over the rest of the following year. Which worked out well because as a non-speaker I could really only afford a single conference each year.

Fast forward to today. There are community level conferences in almost every region of the U.S. and around the globe. It has never been easier for a beginner to find and attend a conference containing the same speakers and talks that previously were ONLY at the large conferences. Yet, it appears that talks themselves are carrying less and less “meat”. Beginners may leave the conference with some content and ideas, but then need to search for more details to actually learn. But should they? Or should there be a fair mix of practical content to use immediately mixed with ideas to research for the future? I personally lean toward the latter.

It is hard to teach a great amount in a 1 hour talk, but if there is not some immediately usable content an attendee will have a tough time proving to their short sighted boss that it was worth their time.

Case of Veterans

In the community I often hear the mantra “Everybody should go to at least one conference a year”. With the recent explosion of regional conferences there are now many veterans venturing out of the office in search of…more. These well paid high level devs need to justify their time at a conference more than a novice level developers because it’s more expensive for their company to give up a few days of productivity and salary from them.

These developers are able to drink from two fire-hoses, and have a thirst for everything that can be thrown at them. They are ready to see code samples, and even live coding by the experts in the field. However, too often a talk does not live up to the expectations built by the talk abstract which eluded to more. The abstract said they would learn how to do something, but the talk may actually bounce around concepts and possibilities. The veteran walks away vindicated in their current knowledge, but gains nothing new.

The Hallway Track

If I hear another person say the hallway track is the best value of a conference I’m going to PUKE!

Again, let me clarify. I’m a firm believer in a strong hallway track. To have exploration time between talks, during meals, at hack events, and at the end of the day, is priceless. But the best part of a conference should be the talks. Those talks should promote discussions in the hallway track where attendees, speakers, and others continue the conversations and perhaps learn more fine points.

How Does This Happen?

I think there are various reasons why the talks have become softer than traditionally. However, I will only name a few that jump out, and leave the rest to the readers own realization.

First, there is laziness. It’s easier to verbally talk about something rather than create code samples and examples. It takes a great deal of time and effort to generate code that only serves the purpose of demonstration. However, it is much easier to present a bunch of bullet points and remain abstract.

Second, there may be a lack of preparation. I think that many speakers do not spend nearly enough time preparing new talks, or rehearsing them. Therefore it is somewhat thrown together and lacks the refinement of in-depth content and examples. If the talk is not prepared ahead of the CFP, which is fine in some cases, I have seen speakers wait far to long after they are selected to actually create the talk.

Third, the speaker may lack true passion on the topic but was able to get it accepted by a conference. Unfortunately knowledge does not always equal passion. Therefore the attendees suffer, because the talk lacks conviction and quality of someone who truly cares.

Fourth, a talk doesn’t live up to it’s potential the first time it’s given. It gets better with repetition. The talk is not bad the first time it’s given, but it is not 100% either. As a user group organizer I am saddened that so many do not consider speaking at a user group to make sure a talk is vetted before giving them at a conference where attendees are paying for “higher quality”.

The Challenge

Based on the above lines of thinking I’m going to be doing the following moving forward, and encourage others to take on this challenge:

• Tweak my own existing talks to ensure they carry value. Add code examples where they should have been to begin with, include more resources to enforce my words, and even include more live coding and demos to provide deeper understanding.
• Be tougher when rating talks I attend at conferences. I should walk out of a talk feeling like I truly learned something.
• Be more critical when selecting talks to be presented at conferences. I owe it to the attendees, and to the conference organizers to ensure the best talks are chosen.
• Ask to see slides and code for talks in advance if available, and at a minimum set a deadline of when these should be ready if the talk is selected. To ensure the talk lives up to the abstract.
• I will not submit talks to conferences I have not prepared in advance and given at least once to a user group. See the blog post by Cal Evans titled “Airfare and Two Nights in the Hotel” where he writes about this very thing.

Final Thoughts

I am friends with many developers (or used to be :P) who speak at conferences pretty often. I know many of them take great pride in their talks and the preparation of them, and not all of the points discussed in this post applies to everyone. However, I would encourage you, the reader, to consider your own talks and see if you can apply some of these things. I believe that we can all improve in some way, and I personally strive to improve each day.