The past few years I visited and spoke at a lot of PHP conferences. PHP Benelux, Laracon EU and US, PHP UK Conference, PHP World are only a few of the conferences I thoroughly enjoyed. Visiting those conferences can be recommended to anyone interested in PHP. Regardless of which level you're at you'll learn some things and you'll meet interesting people.

The past year something has bothered me about the traditional formats most conferences in the PHP ecosystem seem to adhere to. I recently went to DotJS: a JavaScript conference which was organized very differently from the majority of PHP conferences I attended previously.

In this blog post, I'd to highlight what PHP conferences, in general, could consider copying from a conference like DotJS.

Shorten the talk length #

Let's start with the biggest thing that annoys me at PHP conferences. In general talk slot length is around 50 minutes. That's way too long for a default. At DotJS the default slot length is about 20 minutes. To me, a default between 20 - 30 seems much better than 50. I'm not saying that every single talk should be condensed to 20 minutes, but a large percentage of talks I saw at PHP conference would be better if they were shorter.

Of course, shortening the default slot length brings some challenges. An organizer needs to find (and possibly pay for the expenses of) more speakers. For the speakers it's harder too. They need to be prepared better. At DotJS every speaker was very economical with the time given. Personal introductions were kept to a minimum. Slides were very polished. Most of the things said were very to the point.

You might think that 20 minutes is too short to really dive deep into a subject. I beg to differ. In most cases good preparation can do miracles. Here's a talk by Wes Bos were he explains async await in 15 minutes.

Wes spends 20 seconds to introduce himself. Then he just dives in. He clearly explains all the concepts. After this talk you should have a pretty clear idea of what async/await does. Not every single option or use case is explained. That's not necessary. You can look up all the intricacies and use cases in your own time.

When talking to fellow speakers they told me that they've sometimes added segments to their talks just to get to fill the time slot given. Conferences should make clear to their speakers that quality, not quantity is important.

As an attendee, I went to talks where I figured after 5 minutes that the subject was nothing for me. I still had to ride out the remaining 45 minutes. With a shorter talk slot, there's less time wasted.

Lowering the default talk slot time will result in more polished talks and more speakers at a conference. Both are a big win for the audience.

Again, I'm not saying that every single talk should be like this, but a high percentage of talks I saw at conferences could be better when shortened.

Make lighting talks a first-class citizen #

Not every talk should have the same length. It's perfectly fine to have a talk that is longer than the default slot time. Examples of this are a closing keynote, a kind of deep dive talk, or maybe a very prominent speaker that just has a lot to say. It's equally fine to do a very short talk. This is often called a lighting talk. Those could be as short as fine minutes.

Again, if you think that 5 minutes is not enough to demonstrate something well. Here's lightning talk by Suby Raman where he explains how to GPU shader programming in WebGL

This kind of talk certainly doesn't aim at teaching you everything on shader programming, but gets you interested enough so you can do some research yourself.

The cool thing that DotJS did with lightning talks is to present them between the regular talks at the main stage. So after a couple of regular talks, there were 3 or 4 light talks. So in a time span of just 20 minutes you could see 4 talks with wildly ranger subjects. Pretty cool!

Appoint a master Of ceremony #

At most conferences the speakers just walk up on the stage and start their talk. That's fine, but it could be better. This year at both DotJS and Laracon US there was a very good master Of ceremony that introduced the speakers and communicated all the practicalities (and told some jokes) to the audience. At Laracon US the MC was Justin Jackson, at DotJS it was Christophe Porteneuve. Both had prior experience MC'ing at conferences and did an excellent job.

The benefit of having an MC is also that speakers don't need to introduce themselves - the MC does that - so they have more valuable time present actual content.

Don't do a Q&A #

Traditionally at PHP conferences, a talk is followed by a Q&A session. Rarely such a session is interesting for the entire audience. Sometimes a speaker needs to beg for questions. For some fellow speakers I know that a Q&A session is their biggest source of stress: "What if I don't get, or even worse, can't answer questions from the audience". Protip: if you don't know the answer to a question, just answer "I don't know. If you want we can look it up together later", there's no shame in that.

During most Q&A sessions a large part of the audience stays seated not because they want to hear the Q&A session, but out of respect towards the speaker. While politeness towards the speaker is certainly recommendable, we can solve this Q&A problem better: let's just not do a Q&A.

When I give a talk at conferences nowadays, after my talk is finished, I politely tell the audience that I don't do a Q&A. I invite people that have a question to meet me in front of the stage where I will be for the next couple of minutes. I also assure them that it's ok that they ask me question if they bump into me anywhere during the conference.

This way people that are not interested in a Q&A can escape the room. The small group of people that walk up to me are people that all are interested in small Q&A. Because I don't have to address a big audience, it's easier for me to interact with them.

DotJS went one step further. They didn't do any Q&A's at all. Immediately after a talk was over the MC went back on stage and together with the speaker they sat on two very comfy looking chairs on stage. There the MC asked the speaker a couple of well-prepared questions. This is pretty great because:

In general prepared questions are better that questions an audience needs to come up with in a few seconds

The speaker doesn't have to be afraid that there won't be any questions

I don't know if this is the case at DotJS, but in theory, the speaker could get some questions beforehand so he/she can prepare some of the answers

The speaker can sit in a comfy chair

Consider organizing only one track #

I like to go to a lot of music festivals. The atmosphere is great, you get to meet some cool people and of course (if you picked a good festival), the music is great. Many music festivals have multiple stages. While this way you can choose your own lineup, it also causes some stress. Some acts that you want to see might perform at the seem time. Now you have to choose. Have you chosen the right band to see, wasn't the other one a better pick at the time. Choosing is losing! Of course, I'm exaggerating a bit.

The best music festivals I go to have only one track. While you see fewer bands, the line up is mostly very good. Because there isn't any choice, you might end up seeing a band you'd never pick when given a choice. For this kind of festival, the curator is very important. He / she/they get(s) your trust in choosing an interesting lineup. When it works out it's magical: you see a couple of bands you already like and you'll see and hopefully learn to appreciate some artists previously unknown to you.

Conferences are a lot like music festivals. While it's perfectly fine to have multiple tracks, organizers shouldn't throw the idea of going mono track out of the window. If as an organizer you can find a good balance you can let the audience see talks they otherwise wouldn't go to. Attendees can be surprised. They also don't have the stress of choosing between talks.

DotJS is a mono track conference. They succeeded in creating a good line-up of speakers. Going mono track has some other benefits as well. Because there's only one track and talks are around 20 minutes, there is no need for a pause between the talks.

When a speaker was finished his/her talk, the MC and the speaker would go sit in their comfy seats (see above) and start the interview. During that 3 minute interview, the next speaker would prepare his laptop on stage. So in between talks, there was no downtime at all. The audience didn't have to stand up and search for seats after every talk. No time lost. Seeing 3 highly quality talks in one hour is no problem at all.

Attendee seating #

Most conferences have a stage and the audience in front of that. There's nothing wrong with that. But also in this aspect DotJS did slightly better than other conferences. They had a normal, elevated audience seating you see at many good venues. But on besides that they also had chairs surround the speaker and some sitting bags in front of the stage.

While there's nothing wrong with a traditional setup, doing something original or creative can be very cozy.

In closing #

While most PHP conferences are good, they could be better if they choose to implement one or more points from this blog post. Keep in mind that all the above is just my opinion, I didn't do any research around this at all.

Meeting of people is in my mind one of the most important benefits of attending a conference. Reglar conference goings refer to this as the hallway track. It's the time spent at the conference when not in talks. While I've critized the way talks are organized at PHP conferences, the hallway track is always fantastic. Be sure to skip some talks from time to time, and go meet and talk to people.

Together with Dries and other collaborators I'm currently organizing a conference of my own: Full Stack Europe. I'm not promising that our conference will adhere to all points made in this post, but I'm sure FSEU will be influenced in some way by how DotJS is organized.

Do you have any remarks on my thoughts? Do you have any ideas of your own to make PHP conferences better? Let me know in the comments below.