First of all, my apologies for not continuing the blog onQUrl yet. For a couple of reasons, I have not been able to continue the work there yet. I will get to it soon.
One of those reasons is the subject of this blog: my Qt Developer Days presentation. This year, the organisers decided to make one double session for all things related to the Qt Project and roadmap, presented by Lars Knoll, Marius Storm-Olsen and myself. With the Munich event is only 2 weeks away from now, the past week and this week has been dedicated mostly to finishing it.
Qt Developer Days is a very high-level event with very good presentations and presenters. Usually the presenters are the trolls: the people actually working on Qt come to present the work they’ve been doing and the technologies they’ve developed and are maintaining. In the past, these people invariably were working for Trolltech or Nokia, but there have always been speakers from other companies like KDAB or ICS. This year, reflecting the opening up of the Qt Project, there will be an unprecedented number of companies and other affiliations represented. My friends at Cutehacks, Woboq, and INdT will be coming.
One of those presenters is me. This will be my fifth year attending and the fourth presenting. Going to Developer Days is a blast, as I get the opportunity to talk not only to other Qt developers, whom I see only a few times a year, but also to customers and users of Qt. Most of the time, people come very open-minded and are eager to learn, so they will pay a lot attention to you. More than that, they try to squeeze every bit of information from you. In 2009 and 2010, I spent my time outside of my presentations basically going around and talking to people, answering their questions or introducing them to others who would have the information they needed.
Dev Days isn’t all joy though: the hardest part is making the presentation. Every year it’s like that: I look forward to Dev Days for about 11 months, then get stressed in the month leading to Munich, which is when I have to make the presentations. For 2008, I had two technical presentations; for 2009 I had one technical and one Qt in Use (Business) presentation. Last year, I had it easy: one co-presentation with my (now) colleague Rusty Lynch and a session discussing the Open Governance, which required only 5 slides. This year, it’s going to be different: it’s a double session, so we have to talk for 2×55 minutes. And coordinating three presenters, living in two different continents, is not easy.
The first thing we did was to figure out what we wanted to talk about, which is when we wrote our abstract. Next, we tried to identify our audience: the people who go to Qt Developer Days are very often commercial customers, who in their majority are writing desktop applications for in-house use. There’s also a good portion of embedded systems developers. And due to Nokia and MeeGo, a growing number of mobile developers. Most importantly for our purpose, the average Dev Days attendee is very interested in upcoming technologies, but not so much in actually contributing. Since we have a double session, we’ve thought of dividing according to such an audience: the average attendee for the first part, pitching a little about contributing, then dedicating the second part to the contribution process and the structure of the Qt project.
That is our current thinking, but with more than two weeks until the actual presentation, we can still change. (Yes, I know the deadline for the presentation was last Friday…)
Personally, the way I do presentations is to create a “wireframe:” I open LibreOffice in the Outline mode and start typing the slide titles, given the abstract and theme of the presentation. I try to apply a couple of techniques I’ve learnt during the years: one is to have the “red thread” — and no, it has nothing to do with multithreading. The idea is to have one common theme that is always present in every slide, building up to compose the bigger picture. Another is called MECE: Mutually Exclusive, Complementary Exhaustive. It means each slide does not overlap with the others in terms of ideas (or worse, contradict), but the grouping of slides forms a whole, with nothing forgotten. Finally, there’s the Pyramid Principle, in which you structure your ideas hierarchically: you construct your argument by having supporting ideas, each with supporting ideas, then you simply “trasverse the graph”.
With your presentation in mind, then you have to put yourself in the audience’s place and mindset. The audience comes to your presentation with a preconception of what you’re going to talk about, which might be right or wrong. In the first few slides, you have to answer the question “What’s in it for me:” why should the audience pay attention to the presentation. If you fail to explain that in the first few slides, when people are still quite attentive, the attention might wander away.
There are techniques to regain the audience’s attention, though. Be very attentive to your voice: do not speak in a monotone. Every now and then, break the cycle, by either blanking the projector or by doing something in which the audience needs to pay attention to you, not the slides. In fact, it’s a good idea not to have much text in your slides because of that: you didn’t come to read the slides to the audience and not having something to drone on, you’re forced to think. If you can, add images, graphs or code to your presentation, but don’t overdo it.
Most importantly, engage with the audience. Make the audience feel that they’re part of the session. So ask questions which cannot be answered by “yes” or “no” — questions starting with “what” or “how” are usually good ones — and give some time to think. And also ask a question before closing a topic and moving on to the next one, to make sure you leave no stragglers behind. If you need to stop, go back, and repeat something, so be it.
Questions during the presentation are usually a matter of taste of the presenter. I prefer to have the questions asked whenever they are most relevant, so I instruct the audience to interrupt me and ask when they feel they need to. I recommend doing that, but paying attention that you don’t spend too much time addressing one person’s needs and lose 99%+ of your audience in the process. Be sure to thank the person for questions (“I’m glad you asked”). If you’ve made a good use of the Pyramid Principle, you’ll probably get questions you’re about to answer anyway.
And at the end, make sure you have left enough time for questions and that your audience knows where to find more information, by repeating links and email address that you might have mentioned during the body of the presentation. Usually, time for questions is not a problem in Dev Days, as a 75-minute slot is quite long and talking for 55 minutes is very hard. But it’s good to plan ahead anyway. And in case there are no questions at the end, you should have one or two up your sleeve that you can ask and answer, or have a ringer do it for you.
I strongly recommend rehearsing with some colleagues a week or two before the event, so you catch opportunities for improvement, where to ask questions, interact, etc. On the actual day of the presentation, make sure your laptop works with the projector, the slides can be read from the back of the room and arrive a few minutes early, to put yourself in the right mind. And then relax and let the presentation speak for itself.