Pippa Hillebrand

The best way to submit a good talk for a conference, is to have reviewed submissions in the past.

Is this a globally true statement? Unlikely. I believe it makes a difference. I do not have a brilliant track record of having talks selected in the first round of reviews. I also, in some ways, don’t have a whole stack of things I could talk about in new and interesting ways in a conference setting. So, I am not surprised.

I consider it an honour and a privilege to be part of the review panel for DevConf talk submissions. I may not be close friends with everyone involved, but I have had enough positive interactions to be able to say that the organisers work very hard to ensure a high quality of talks, and a broadly diverse panel of reviewers. It is a developer conference, meaning obviously there is technology behind the call for speakers, and the review system. I can’t tell you where they found Sessionize, but it has some really cool features. Which well crafted talks benefit from, and poorly crafted talks are penalised by. If you want to hear the opinions of people potentially more qualified to give this advice, there was a panel conversation in 2023 which really broke down a lot of these topics.

Reviews for DevConf 2025 are under way, and before even getting through the full set of submissions, I am beginning to remember my “pet peeves” as a reviewer. I am aware that I may be biased, and I do work to ensure that bias does not creep in too much. For example, I do my best to rank front end development talks fairly, even though I am vocally a back end developer by trade. If you’re concerned that one reviewer with such opinions might skew the vote, remember that it is a panel. We each have our own preferences, and there are front end developers doing review work too. I want to go through some of my personal lessons learnt from reviewing talks, in the hopes that someone may find these interesting the next time they are submitting.

Pet Peeve 1: Failed to read the instructions

The submission instructions for DevConf are thorough, complete, and very well written. For those who have submitted and spoken at conferences before, they may seem like too much work to go through. But they are there for the speaker, not just for the organisers. I am also very aware that many developers don’t read instructions or documentation. I frequently skip steps because I think I am cleverer than I am. As a reviewer, it is shockingly obvious who didn’t read the instructions. Here are some things which are explicitly called out in the CFP, and which I have seen done in submissions.

• Talks we shy away from: Marketing or sales pitches – rather get a client to share their experience using the tech!
• Anonymous Review: This is an anonymous review process so please do not enter personally identifying info in the description or notes.
• Hints for submission: The outline field should be a set of bullet points of the content you will be presenting.

I get it. All of these things are written “below the fold”. The speaker probably didn’t scroll that far done the page, and so just never saw them. They are pretty important though. Let’s go into why.

Sales Pitches

These make for surprisingly boring talks. Unless you are at a conference specifically dedicated to the service you are talking about, you need to bring in real world experiences. Having a walk through of “how I solved this problem” which happens to have all the examples using the tech is far more compelling to listen to. I have sat through talks which tell me I should use a particular technology to solve a problem I didn’t have, and enjoyed them. They were not framed as sales pitches or product announcements. And that is what makes them stand out.

Personally Identifying Information

Sessionize is a pretty amazing piece of technology. Every submission is given a random speaker name (usually a pair of colours) to avoid subconscious bias against specific demographics. There are some things which it may be difficult to remove from the abstract or outline, and may associate you with a specific demographic. But there are some things which are very easy to get right (and if you get them wrong you definitely didn’t read the instructions). For example, including your name in the abstract or talk outline. I am actually not sure what the positive side of this behaviour is. For the event, your name will be associated with the talk, there is no need to include it in the abstract. You can even make the abstract more powerful (and avoid passive speech) by using “I”. Now it is personal, which attracts attention. The down side, is that now the reviewer has to consciously fight the potential subconscious bias. When you have between 250 and 400 abstracts to read, most of them many times, that extra cognitive load adds up.
Including company names, and organisation names, is not quite as bad. In fact, sometimes that can be helpful. Giving better context on the nature of the talk. It is a fine line to walk though, as it may be a small company with not many people who are willing to give a talk. So think twice, and then decide if it is really necessary.

Outlines

It took me a while to understand this one. And the more talks I’ve reviewed, the more I’ve appreciated it. You don’t have to write the talk until it is accepted. In fact, in many cases I recommend not doing so, unless you are writing it to serve more than one audience. Writing a good talk can be a lot of work, and doing so without having the payoff of presenting it is painful. So, how does the outline help? It shows that you have a sense of flow for a talk. It also shows that you have thought through how much you can fit into a 40 minute session, whilst still leaving time for Q&A. It also provides you with the benefit of being able to build on it when you do start writing the talk. It can happen that the organisers have to change plans at a late stage. If you are accepted late (because you were ranked just below the cut off point, or something) you might be writing the talk in a hurry. Having a set of bullet points to work from can be a talk-saver at that point.

So. If you’re submitting a talk (a bit late for DevConf 2025, but there are more conferences) read the instructions from the organiser. They are there to help you submit a talk that works for the specific audience. Some of those instructions may even benefit future submissions. Don’t let them be intimidating. They are there for you.

Pet Peeve 2: Jargon

This is specific to DevConf, and may not be applicable to other events. In fact, for a security or data conference there may be a certain expectation of jargon. Even so, avoiding it can be helpful. You are presenting the talk in order to share knowledge or information with the audience. Assuming that they know all the terms you are using may be counter productive. If they already know them, then what do they gain from your talk? If they do not know them, how do they know your talk is relevant to them?Terms and words which are specific to a framework or concept may be terms you use and hear every day, but I may have never seen them before. You have enough words in the abstract for these definitions, and it doesn’t weaken the submission. In fact, I would say it shows that you have considered the broader audience, and are able to define the terms you use, indicating deeper understanding.

Pet Peeve 3: It’s all anyone is talking about, I’d better do a talk about it

Congratulations. You have fallen into the simplest trap in the talk submission book. That’s not to say your submission will not be accepted, but rather it needs to be twice as good to be the best. There have been moments when I have read two different abstracts, and thought “I cannot tell the difference between these two talks, let alone which will be better.” That probably means neither will be selected, as neither is unique enough to stand out. If you can bring a unique and personal twist to the topic, then it will rank higher. It will be a more interesting talk, engaging developers outside of the specific field. Something that comes up a lot (over multiple years) is testing. We all agree it is important, but what new and interesting thing do you have to bring to the topic and the developer community? I have fallen into this trap in the past, that talk, unsurprisingly, was not selected. When you look at the calibre of the competition, you realise when you are outclassed. If you still want to submit on a hot-topic, maybe go through the playlists of previous talks, and use those to understand what made them special.

Pet Peeve 4: Wrong length abstract

I know, we don’t want to read an entire essay. The thing is, one line isn’t really enough either. I don’t have a silver bullet for writing good abstracts/overviews. What I do have are some things which make my eyes glaze over, and others which leave me with too many questions. A long, multi-paragraph, overview can be a good thing. If the author is engaging and can make it flow. It may end up looking a little odd in the final agenda, but that can be workshopped later. The same length, where it is dry or jargon filled (see point 2) is going to make my eyes glaze over before I read the whole thing. Remember, chances are this is the 50th overview I am reading in this particular review session.

It is a good thing we have a little more than a month to fulfil our review duties, we can take breaks to write peevish blog posts.

The pendulum swing to a very short overview doesn’t make it any better though. If you are trying to fit the talk overview into a tweet, you are not going to have sufficient details to engage a potential audience. Not always, sometimes you want something snappy. But if your talk falls into peeve 3, and you only have a couple of short sentences, it is going to be less compelling. Remember, this conference is packed, five talks happen in parallel, and attendees have to choose which they will attend in person. You need to have enough detail to stand out from the others in the time slot, but not so much that no one reads the whole thing.

Bonus: A positive bias

Not all bias is bad. You might not even call this a bias, though we shall have to see how that pans out. I find that I am far more likely to rank a front end talk positively (particularly against topics I know well) if I learn something from the overview, and find myself wanting to hear more about the topic. In general this is what I am looking for in talks. Obviously one that I think is going to get a lot of attention will be ranked high, but one which can turn my normal bias on its head is clearly well written.

Conclusions

I started this post by suggesting that reviewing submissions makes you better at writing them. I stand by this, even as I use my own poor submissions as examples. I don’t mind knowing that I have improved my own talk submission game. I also don’t mind not having a talk accepted when I have see the calibre of the competition. I still have room to improve, both as a nuanced reviewer and as an experienced submitter and speaker. The pet peeves I’ve mentioned here might not end up being everything which annoys me (I’m sure my list of irritating buzzwords will grow), but if you can avoid these traps, you’re well on your way to writing an abstract I’m going to enjoy reading.