Earlier this week a fellow PHP public figure tweeted saying that I write great session proposals for conferences. After I finished blushing I reached out to him and we talked a bit about what it was he likes about them. (Whatever I'm doing right, I want to know to keep doing it!)
Based on that, I figured it would be educational to dissect how I go about writing session proposals for conferences and hope that conference organizers don't catch on to my tricks. :-)
The audience
Session proposals are aimed, primarily, at one audience: The conference selection team. It's nice if they're also read by the conference attendees, but let's be honest, most people don't read past the title. Besides, only a small fraction of your session proposals will even be selected, period, so your primary audience is "let me give this talk, please!"
A typical conference selection team will be reading dozens or hundreds of session proposals. Many PHP conferences have more session proposals than they do attendees (some by a wide margin). That means conference organizers are going to skim, they're going to skip over anything that doesn't catch their attention early on, they're going to skip based on the title, and many if not most will automatically discount anything with obvious typographical and grammar mistakes.
Whether those are "fair" or not is entirely irrelelvant. When you're reviewing 600 proposals for 20 session slots, it's a necessity.
That means first of all, proofread your submission or go home. Get a friend to read it if you need; that's fine. But if you don't capitalize things, have runon sentences, stray commas that appear out of nowhere, or otherwise have sloppy writing, it doesn't matter how good of a presenter you are, or think you are. Organizers will ignore you, because figuring out what you meant is not a good use of their limited volunteer time.
The title
It's amazing how much the title of a talk can matter. It's just a few short words, but often those few words are all someone will see before deciding to attend your session or bother reading the description.
A good title is reasonably short, self-descriptive, contains the appropriate buzzwords for your topic (and no others), and has enough of a "hook" to make someone want to read further (or attend). Sometimes that can be very bland; other times it's "punchy" (whatever that means). But it should capture enough of the essence of your session that someone can decide if they want to attend that vs another session in the same time slot. (If the answer is yes, the selection committee will probably want to attend, too.)
Let's look at a few titles of talks I've given, as examples:
- From zero to Silex
- Short: Check. Buzzwords: "Silex". This title takes no time at all to read, implies that it's going to be about the Silex framework, and that you're starting from "zero". What's zero? Unclear. Zero knowledge? Zero code? Both? This one could have been better, I think, but certainly did the job. Organizers know it's a beginner-level Silex talk, and if they care about having one of those they can read the description.
- Functional PHP
- Very short. Just two buzzwords: "functional" and "PHP". Well, now we know what the talk is. But there's also a subtle pun (as in Zero to Silex as well); are we talking "it works" or "functional programming?" Both, really. The description makes that clear. I gave this talk over a dozen times so it apparently worked.
- Aphorisms of API Design
- Another talk that had a very long shelf life. Fairly short. Two keywords: Aphorisms and APIs. APIs are obvious. Aphorisms? "Gee, I wonder what that's about? Let me click through and see." This one was half self-evident (API design) and half "hook". I originally gave it in 2011, and kept on giving it for several years. By the time I retired it, though, the hive mind had decided that the "W" in "API" stood for "REST" people were confused that I was talking about interfaces, not about REST. On the one hand, meh, change with the times. On the other, crap on a stick, people, APIs existed long before REST and will exist long after it, get over yourselves.
- Everything I need to know about software management I learned from Fred Brooks
- Kitch, pop culture reference, and... nothing. "Software management" is a medium buzzword. "Fred Brooks" is meaningless if you don't already know who Fred Brooks is. It tells you absolutely nothing about what the talk is about, but it wastes a full 1.5 seconds of your time to tell you nothing. It's way too long, and would probably break most schedule layouts, especially on mobile. This was a horrible title, and no conference ever picked it until...
- Software Management Lessons from the 1960s
- I renamed it. Now it's been picked up several times. It's the exact same talk, but now it tells us more in half as much text. "Software management" is still there, OK, so this is a project management talk. Probably not much code. (True.) "From the 1960s", wat? That's novel. I wonder what it's about... (That's exactly the response you want the selection comittee to have.)
Don't go for the overly-kitch titles. Short and descripive wins. If you can work in a pun, great, do so. It breaks the monotony. But informative wins over entertaining when selling a talk.
The pitch
Most of my session proposals break down into a simple 3-paragraph format. Sometimes they're not actually three paragraphs, but there's still a clear 3-part structure to them. For most conferences that works fine, except for a few that have very very short space restrictions on their description field. (Lookin' at you, php[architect]...)
There's no one right way to write a session pitch, but I've found the 3-part pitch works well for me. A 3-part pitch has (you'll be amazed to hear) three key points, in order:
- State the problem
- Tease the solution
- Explain how you'll provide the rest of the solution in the session
The session itself may or may not follow the same structure; it's fine either way. (I often don't.) The key factor here is that you're setting the stage, and putting the reader into a mindset that there is a problem to be solved: Then you solve it. In just a few short sentences you're creating a demand for your product (your session), and then fulfilling that demand.
Yes, writing a session proposal is just like marketing. If that makes you feel dirty, you won't get many sessions accepted.
Even then, you have only a few short sentences to make the case, so make them count. Let's look at a few examples, again from my own archive:
Functional PHP
Functional programming. Some see that term and think "functions? You mean procedural programming. I've been doing that for years." Others see it and think "you mean that crazy academic nonsense that no one understands? Pfft!"
In truth, functional programming is fundamentally an approach to software development, not a particular language or syntax. With modern PHP, it is an approach that is now more readily available and powerful than ever before. Even if you're not writing in Erlang or ML, there is still much to learn from the principles of functional programming to help write better code.
This session will discuss the history of functional programming and how it compares to other programming paradigms (procedural and object-oriented). We will then discuss by example how functional concepts and techniques, plus language capabilities in modern PHP such as anonymous functions can make our code more robust, maintainable, and bug-free. Even without a truly functional language, there is much we can learn from functional programming as a technique.
Three paragraphs. The first paragraph sets the stage: There's confusion around what "functional programming" is and means, and people don't take it seriously. The second paragraph gives the solution: No, this is what Functional Programming really is, and yes it is relevant for you, PHP developer. The third paragraph states what will actually be covered in the session: history, comparisons to other styles how to use it in PHP, and how it's cool to do so. There's no ambiguity about what it's about.
Software Management Lessons from the 1960s
"The Mythical Man-Month" is one of the seminal books in the field of software project management. It was written in 1975, based on experience from the 1960s. Is it even still relevant?
Turns out, it is. Technology may have changed dramatically but people have not. Managing software projects is about managing people, not bits, and creative people engaged in intellectual endeavors are notoriously hard to predict and manage. (Just ask my project manager.)
Fortunately, many of the lessons-learned Brooks' presents are still relevant today. Some are directly applicable ("adding people to a late project makes it later") while others are valid with a little interpretation. Still others fly in the face of conventional wisdom. What can we learn from that?
This session will present a modern overview of the ideas presented by Brooks and a look at what we can still learn from them even today.
Four paragraphs, but that's OK. We now know what this talk is about: "The Mythical Man-Month", a book by Fred Brooks. Problem: Is such an ancient book even relevant? Should we care about old stuff? The second and third paragraphs together provide the response to that: Yes, we should care, because much of it is still relevant. The problem "people don't know their history" is solved by "so let's learn that history". The final paragraph says very succinctly what the session will do: Present a "modern overview" of the book and the parts that are still relevant.
Yes, it's a book report. So what? It's a good book report that's been given as a keynote, twice, and I'm about to give in a 4th country. :-)
PHP 7(.1): The New New PHP
The next era in the life of our favorite language has come. PHP 7 brings numerous improvements to PHP, from minor syntactic enhancements to major engine changes to a new, stronger type system.
What does it mean for developers? What exactly are the new tools at our disposal? Are the changes in PHP 7 worth the upgrade? We'll try to answer that question, and make the case for upgrading sooner rather than later.
Here's a short one, only 2 paragraphs. The same three points get covered, though. Problem: PHP 7 (and 7.1) is new and shiny and fancy (set the stage), but there's some uncertainty about if it's "ready". Solution: Hell yeah it is, let me tell you why! How: I'm... going to tell you why. This description is very short and to the point: This is a sales pitch for PHP 7 and proud of it. Organizers can see in a matter of seconds exactly what they're going to get with this talk. Whether they want something that unabashedly positive, well, that's their call. The talk will be (and it was).
Make your code do your job
Throughout history, advancement has come from reducing the amount of work that needs to be done by humans and letting technology do it for us. Long before computers, humans were letting our technology work for us in order to make ourselves better.
So too with programming. We have the ability in PHP, as in many languages, to make the language syntax itself find bugs for us. It's called "types", and is a far too under-utilized part of the language. Even many seasoned developers don't realize the benefits that come from having strict, explicit types in their code rather than relying on haphazard "duck typing".
This talk will make the case that your best way to improve your productivity as a developer is to make your language itself do your work for you. With PHP 7's improved typing support that is now even easier than ever.
The title on this one is a little less descriptive than the previous ones: It teases without answering. What's this about? It's about code, we know that, and it's about about making code do things for us. Which is...?
The description on this one is three paragraphs, but they don't correspond to the 3 parts of the pitch, really. It starts off with a setting and history lesson: Technology should make us and our lives better. That should happen in programming, too. The first paragraph is the hook, and the final problem statement is in the middle of the second paragraph: "types are far too under-utilized". Solution: Let's "make the case" for them. Specifically, that the language should "do your work for you".
The three-part structure is still here, but it's more subtle:
- Technology should be used to make us better as humans, but a lot of people are missing out
- You should use types more!
- I'm going to yell at you about why you should use strict typing in PHP 7
(NB: I don't actually yell.) Even though the structure is different, the basic premis is the same. The selection committee can read it in about 20 seconds and come away knowing what the session will talk about, the angle it will take, and why it's important.
Caveats, so many caveats
Of course, every conference is different. The style I've developed and shared here won't work for every conference. php[architect]'s call-for-papers limits you to about half the length of what I have above, if that, so I always have to edit them down to bare bones to fit. PyCon, by contrast, wants a full blow-by-blow outline. I don't know how to even submit a CFP for them without writing the session first (which I almost never do otherwise). Often you'll need to vary your approach for a different set of organizers or a different community with its own expectations.
To be sure, there is no guarantee that even with this approach you'll get your session picked. With 600 sessions for 20 slots, competition is steep. Even speakers with a strong reputation, a strong topic, and a solid pitch get rejected regularly, not because there's anything wrong but there's so many others doing things just as right. Don't take it personally if none of your sessions are selected for a conference. You may need to improve the pitch, or you may have nothing to improve at all; there were just too many people applying for too few slots.
All that said, while there's no guarantee that your session will be picked if you submit, I can 100% guarantee that you won't get selected if you don't submit. There are several CFPs open for conferences in the first half of 2018 right now. Will your session make the cut? Not if you don't try, it won't. If you have an idea for a session, pitch it. Worst case scenario, it does get selected and then you actually have to write it.