This year I spoke at 17 different iOS events in 15 different countries, each time delivering a new talk. This took a lot of work, both to prepare all those talks and also to fly to events and deliver them live, but it also forced me to work hard to find original, interesting topics, apply a unique take to them, and deliver them with my trademark enthusiasm.
In this article I want to walk you through the 17 talks I delivered, but really I want to talk to you about what I learned along the way. You see, some people watch me speak and think it’s a skill that comes naturally. However, that couldn’t be further from the truth: I work extremely hard at designing and delivering presentations, and if I look casual and relaxed on stage it’s only because I’ve all but memorized my lines.
So, I hope this articles goes some way to showing that I’m continuing to practice the skill of presenting at technical conferences, and hopefully improving too. If anything, I’m rather self-indulgently writing this as much for myself as I am for you – writing things down like this is almost cathartic for me, helping solidify the high (and low) points of my speaking year, and helping clarify in my own head the bits where I thought I did well and just as importantly the places I think I fell short.
To be clear: if you’re looking for a useful article with Swift tips, this isn’t it. This is me reflecting on a year of speaking at iOS events, specifically focusing on my own presentations and what I learned along the way. It is self-indulgent, I know, but it’s the end of the year so hopefully you can forgive me a couple of these!
Anyway, let’s dive in…
2018 kicked off with me speaking at dotSwift with the talk Elements of Functional Programming. dotSwift is a unique event in that talks are only 18 minutes and are presented in grand environments, so I think every speaker there feels obliged to be at the top of their game.
My talk on functional programming was an easy one, which is no bad thing: a conference ought to be a bit of a difficulty rollercoaster, otherwise it can get awfully intense. However, I worked hard to make sure it was topical – there are a number of French jokes in there, including some about the fights over Nutella pricing in France.
Sadly, things didn’t quite go to plan. In particular, you’ll notice very early on that the clicker I was using wasn’t great: I’d press the advance button and nothing would happen, then press it again and sometimes even have it advance twice. When you’ve worked so hard on such a short presentation, every click counts, so this wasn’t ideal. However, lesson learned: I bought my own clicker in the form of the excellent Logitech Spotlight and haven’t had problems since.
My next talk was in London, called Nuke It From Orbit: How to Deal With Massive View Controllers Once and For All. iOSCon has a large venue in London so this was a big crowd, but I had a great time delivering it.
This was the first talk I had given with a specific theme attached to it, that being the movie Aliens. I didn’t push it heavily, but I wanted to dot it through the talk enough to link things together. And the result was a talk that was much better than the talk from the previous year’s iOSCon, where my wide hand gestures had managed to knock off my lapel microphone three or four times. This time around I was smart and threaded the lapel cable under my T-shirt – something I still do.
However, when I watched the recording later on another thing struck me: I don’t stand still. I’m not pacing, or even really actively making any sort of interesting movement. Instead, I’m shifting from leg to leg across three nearby positions – a sort of tripod of restlessness. I made a decision then and there: when I move on stage, I want to do it with intention.
Finishing up the quarter was Appdevcon in Amsterdam with the talk How to Debug Like a Pro. This went mostly smoothly, but there was an issue with my head-mounted microphone – the technician for my room wasn’t aware there was a clip to hold the microphone in place, so it moved around freely. This meant standing weirdly still to keep the microphone active (an antidote to iOSCon’s restlessness?), but even then the volume isn’t terribly stable. Still, another lesson learned: I always try moving head-mounted microphones before the talk starts, just to make sure they are fixed in place.
I submitted a talk to App Builders in Switzerland, but got turned down. No one likes getting turned down for talks, although when I saw the speaker list I saw someone else had submitted a similar talk and felt a little better.
Still, fate had other plans: due to a last-minute cancellation I had to prepare a talk and fly out to Switzerland at short notice. Having to prepare and practice a presentation in just four days was awfully stressful, but I think the finished talk – How to Build a Modern iOS App – worked well.
Except for the pacing.
With so little time to prepare the talk, I was thoroughly restless on stage, moving between the same two or three positions constantly. Standing still on stage doesn’t look great, but being restless is just as bad - my hopes of scrapping this were thoroughly dashed.
So, this time I decided I had to change for real: I actually practiced some of my older talks with me moving only at key points. It sounds strange saying I practiced walking around, but it’s true – I did. I practiced standing still, I practiced walking around, I practiced walking and talking, and so on.
App Builders also taught me two very important lessons, both from Carola Nitz:
Wherever possible, it’s helpful for speakers to sit near the front of the audience. Not only does this mean we’re on hand to answer last-minute questions from other speakers before they get on stage, but it’s also a place where they can see us easily, so we’re able to be a visible show of support for each other.
I learned to meander around the conference during the breaks – literally to wander aimlessly. If folks see you talking to someone else they are unlikely to interrupt, but if they see you wandering around not doing anything in particular they are much more likely to say hello. Ultimately, getting the chance to meet folks and ask questions is one of the most important parts of attending a conference, so this simple change in behavior really makes a big difference.
In June I spoke at two conferences back to back as part of the hectic WWDC week in San Jose: AltConf and NextDoor. I had worked for months on the NextDoor talk, What Star Wars Can Teach Us About Swift: there were multiple After Effects videos, multiple Photoshop jobs, and of course lots of tips for writing better Swift. I flew to San Jose for WWDC week, and literally half my luggage was a Jedi outfit for this talk – I was taking it seriously.
But once again fate had something special in store for me.
I had submitted a talk proposal to AltConf months earlier: iOS 12 in 45 minutes, which was effectively “I will stand up and talk about whatever Apple just announced in iOS 12.” Since iOS 9 I’ve written “what’s new in iOS?” posts on this site, listing what’s changed and giving code examples. So, I figured I could take that work I do anyway, condense it down to 45 minutes, and present in on stage.
That plan was looking good until the WWDC keynote had finished, and I realized iOS 12 was the quietest release of iOS yet. This meant my talk could easily have been renamed “iOS 12 in 4.5 minutes.” Worse, one of the most impressive new features was the ability to build Core ML models using Create ML, which was only available on Mojave.
So, I reluctantly upgraded my main Mac to Mojave while I was in San Jose, wrote up the AltConf presentation, and delivered it well enough. You can watch the live version here if you like, although it’s a bit odd because it shows me speaking but not the live code.
But I had made a terrible mistake.
The next day, I connected my laptop for the NextDoor talk, pressed Play in Keynote, then dashed off to get changed into my Jedi outfit. I had prepared the slides precisely: 15 minutes of the talk logo, followed by three minutes of music so the technicians could adjust their audio, followed by my Hacking with Swift / 20th Century Fox intro and – boom! – my custom Star Wars opening crawl in all its glory. All this meant I could press Play in Keynote and have the whole thing take care of itself while I was getting changed.
It worked perfectly: I had time to get changed, then snuck into the conference room and watched it play back exactly right – it was a real encouragement to see folks laughing at my intro videos.
Then the problem struck: every second or third screen of my talk was either partly or completely black, with lots of image corruption along the way. The presentation I had spent months making, which had 296 slides, was almost completely broken.
Why? Mojave beta 1. While this was mostly a small release, it was still the very first version of that small release, and things were really in a bad state. Fortunately, by this point I knew my lines perfectly and just carried on speaking. Sure, a fair chunk of the jokes didn’t work as well because of the image corruption, but at least the main message was still there. In retrospect it’s lucky that NextDoor don’t record their talks, because this one was a disappointment for me.
As for the lesson learned here, I honestly wish I didn’t have to install beta 1 of Mojave, but I really had no choice. My laptop goes with me everywhere and I rely heavily on it, so if I’m ever in this situation again I’ll probably ask to borrow someone else’s for the talk. Still, in 2019 I doubt I’ll be speaking at two events during the WWDC week – one, maybe, but definitely not two.
(PS: The Star Wars talk was still voted the best at the event, so it wasn’t a complete disaster!)
September is by far the busiest month for iOS events: I spoke at five, turned down a sixth, and there were several others I couldn’t get to because of timing clashes. This makes it a really frantic time – lots of flying around, lots of preparing and practicing talks, and lots of speaking to folks along the way.
The month started in Wales, at iOSDevUK. 48 hours before I had arrived home from a month-long trip to Asia so I was more than a bit sleepy, but I still wanted to do my best – this was a conference I had hoped to attend last year, but had to withdraw from after a biking accident.
At iOSDevUK I delivered a new two-hour workshop called Swift Best Practices. Workshops are, in theory, about small groups, but this one was to a rather full lecture hall, so it was mostly me talking. Alongside that new workshop I was also given the chance to repeat my Star Wars talk so that it could be captured on video, but once again fate had other plans: their radio mic garbled my audio, so the recording was ruined. Yay.
After iOSDevUK I went to the inaugural Swift & Fika in Sweden to deliver the talk How Not to Write Swift. This talk saw the culmination of two efforts from me: I was really working hard on the themed approach to talks (this time it was The Hoodie of Truth), but I was also finally starting to gain control of my movements on stage. I’m not going to lie: it took a lot of work, and it almost got to the point of my movements being choreographed. But now rather than shifting uneasily from leg to leg I was able to pace around some, or to stop still entirely for a time.
From Stockholm I flew directly to NSSpain to deliver the talk Teaching Swift at Scale, where I used Family Feud as my theme. Having already done two talks in a week, I was really tired by this stage, and it wasn’t helped by having a surprise 3am wake up from one of the other NSSpain speakers. Still, after literally falling asleep while working on my slides the night before, I got on stage and delivered one of my favorite talks of the year.
Even though I didn’t have a huge amount of time to prepare, I still had worked hard on my tone. If you watch the video you’ll notice I go from being quite loud sometimes to being relatively quiet, for example – I tried to vary my voice to keep the talk interesting. I also tried to use the full extent of the beautiful stage by pacing around a lot – perhaps too much! But if you skip forward to 13:39 in the video I hope you’ll agree the pacing and tone variation works well, even if the talk as a whole could probably do with being about five minutes longer.
There was still scope for lessons to be learned, though: if you watch towards the end you’ll see I have jokes written in English on my slides, and I hadn’t taken into account the language gap with attendees. They speak great English in Spain, of course they do, but it still takes time for them to read the words, understand them, get the joke, and laugh.
So, at first I just marched on and had to repeat my line after they laughed, but for the subsequent ones you can see me trying to find ways to pause after showing the slide to give them time to respond before I speak. Lesson learned: if there are English jokes on slides then either have a bottle of water handy to inject a decent pause, or just read the words out.
After NSSpain came SwiftConf in Germany. This was a really lovely conference: quiet environment, smart organizers, and a really social atmosphere. But I gave a talk that I really didn't like – the only talk I was unhappy about from the whole year, even after the Star Wars talk hit so many issues. To be clear, this was not in any way the fault of the organizers or anything other speakers; the problem was mine and mine alone.
I wanted to speak at SwiftConf last year, but had to pull out because the aforementioned biking accident. They very kindly invited me back this year, and allowed me to deliver the talk I had planned in 2017. However, between 2017 and 2018 I had come a long way in my presenting skills, so when it came to preparing slides for my talk – Mastering iOS Animation – things just weren’t exciting for me.
So, I made the last-minute choice to ditch my presentation, and instead write an iOS app to do the talk for me. This would allow me to present slides inside my app, then transition directly to live UIKit views where I could interact with my animations.
I practiced the talk maybe a dozen times, and each time I thought “this talk sucks.” It wasn’t interesting. It wasn’t applicable. I wasn’t excited about it. And when I delivered the talk live, it was just as bad as the practice runs – I think maybe I expected that somehow getting on stage would transform the talk from being OK to being good or even great, but it didn’t happen, so instead I gave my worst talk of the year.
Now, on one hand I do set a very high bar for myself. I spoke to one of the SwiftConf organizers who had originally invited me in 2017, and he said “the talk was good, but I was thinking that Paul doesn’t do good – he does great.” At the risk of sounding immodest, I agree with that assessment: regardless of what other folks might think of my talks I still judge them on my own internal rating and strive for the best I can be, and this talk fell short of what I consider my usual level.
I spent a lot of time going over the talk in my head afterwards, trying to figure out why I was so unhappy, and the conclusion I came to is this: it lacked direction. A good talk ought to be like a story, with a clear progression from start to finish and perhaps even chapter markers along the way. This talk was effectively me walking through the various iOS animation APIs, but I wasn’t doing it with a purpose, so it lacked any sort of clear learning progression.
In this case, I spent far too long futzing around with my iOS app and not enough time taking the audience on a journey, and it showed. However, I’m able to look back on this as an important learning opportunity: I realized then there’s a certain kind of talk I deliver well, and when I stray from it I start to struggle. So, lesson learned: if I’m practicing a talk and it doesn’t feel good, it isn’t good.
After SwiftConf was Tech Fest Bucharest, where I delivered a talk about Vapor. This was a bit of a strange event because the iOS track was mixed alongside Android and web folks, and if it weren’t for CocoaHeads Bucharest inviting me to speak in the evening this trip would have been a write off.
Entering October I still had six more talks to write and deliver, but after the experience of SwiftConf I wanted to go back to familiar territory: making a more traditional slide-based talk where I had a clear theme and a clear direction.
It just so happened that Mobiconf got the full force of that shift: my talk there was called Understanding the Standard Library, and my theme this time was stolen from sports television. When someone scores in a sports match the broadcasters will often show a replay, then pause and draw over the screen so you can see things like holes in the defense, or clever player movements. Well, I wanted to do that just for the Swift standard library.
Of course, that meant shifting between code and slides a lot, so I wanted to do something new: I wanted to record videos of me coding, then add them to slides so that I can move straight from a recorded Xcode into slides. So, attendees watched me “typing” on my laptop to download the Swift source code from GitHub and digging through files for examples, but in reality it was all recorded.
The trick here, such as it was, was that I had sliced the videos into small segments. This allowed me to stop at any point and talk freely, without worrying about the video playing without me. So, the illusion was pretty strong – I even hid the clock from my menu bar, so folks couldn’t compare the time.
This talk took a lot of preparation, but it paid off: the talk won a “best presentation” award, and a lot of folks came up to me afterwards to say they appreciated it. That being said, I did make one mistake towards the end, which annoyed me immensely. Remember, each conference gets a new talk, so if I’m going to deliver a talk only once I need to pull it off without mistakes! That (small) error happened because Keynote doesn’t give you a signal when a video has finished playing so I moved onto the next slide before the current video finished.
None of the audience noticed the mistake, but I did, which is why the link above is my re-recording of the talk – I want one good, clean version for posterity.
After Mobiconf was Mobilization, where I gave an extended talk and live coding session about coordinators. This was a new approach for me: some slides, some live coding, and some more slides – it’s effectively the WWDC formula. And you know what? It really works.
I know, I know – Apple have been doing this for years so it’s obvious. But it really works. Showing some code on slides is fine, but showing it in practice afterwards does two important things:
This talk signaled the end of my move to coordinators: I had adopted the pattern fully at this point, and was effectively evangelizing it to the world.
I used the exact same WWDC-style format for my talk at Swift Heroes: Refactoring View Controllers Live. This time I went even heavier towards live coding, and it really worked – I wasn’t presenting anything particularly magical on stage, but doing it live meant folks could follow along each step of the way much more easily.
Although some folks don’t like doing live coding on stage, I chose it for Swift Heroes because I find it rather easy to do. That is, standing up and doing 35 minutes of coding from memory is easier for me than preparing a 45 minute slide deck – that takes days if not longer to do.
Doing a live coding session at Swift Heroes meant that I had a lot of time on my hands because I didn’t have to do many slides, which was helpful because I was preparing my most complicated talk ever for DevFest Baltics. It was called “Core ML for Everyone” and took me an enormous amount of work.
The theme for this talk – the MacGuffin, as I was now calling it – was that Siri was going to do the talk for me. I wanted to start the talk with the cliche of reading a quote from Wikipedia defining machine learning, but then say something like “this talk is about machine learning, so don’t I ask Siri?” And because Siri responded so well, I’d ask her to complete the talk on my behalf.
Of course, Siri could do no such thing, so preparing this talk meant typing out every line for Siri, then syncing it up to me coding in Xcode and flicking through slides so it looked like Siri really was in control. I then took it a step further by adding interactions between me and Siri – she’d ask me questions and respond to the replies, and so on.
Like I said, this took a lot of work, and it’s actually a really stressful talk to deliver – I need to say exactly the correct lines, because Siri’s response is hard-coded. So, if I forgot a line or said the wrong thing, her response would make no sense and the illusion would be broken.
I managed to deliver the talk without a hitch, although in retrospect I should probably have chosen an English-speaking country for this one – Siri’s voice is a bit tricky to understand sometimes, and she talks a lot in this one. I had also definitely underestimated how stressful the talk was to deliver, so I doubt I’ll be going for such a heavily scripted presentation again.
Next up was Swift Alps, which was a completely different kind of event from all the others: it’s real workshops, with small groups of people pair programming to solve a common problem. This was probably the easiest event of the year, because even though I had to write up all sorts of instructions for attendees it was still mostly them doing all the work – I just wandered around providing suggestions.
However, I was struck by how well the Swift Alps worked. Having been to so many other events this year, the Swift Alps was clearly, markedly better – there was no scope for folks to zone out on Slack sitting near the back, or to browse through cat GIFs on Imgur on their iPhone. Instead, everyone had to be involved, had to meet people, and had to try things out themselves. The format of the Swift Alps has since inspired both Swift Aveiro and Swift Island, and with good reason - it really works.
The final talk of the year was at Mobius in Moscow, titled “Squeeze your Swift.” By this point I had grown comfortable with the WWDC approach of mixing live coding and slides to help make ideas really stick, and this talk was the culmination of my practicing that form. I spoke slowly, because English can be a little hit and miss in Russia, but still managed to cover a variety of techniques in about 55 minutes.
This talk was the only one of the year where someone shouted out a question to me in the middle. This is really uncommon, not least because it’s harder than you might think to hear questions from the audience when you’re on stage – at some events you can hardly even see them. Worse, this was actually shouted out by a fellow speaker, which is really unusual. Most speakers recognize that it can be stressful to get on stage, so we’re usually the quietest in the room.
2018 was a year I specifically set out to push myself hard on the conference front, and for the most part I’m happy with the result. Sure, there were a couple of weak spots, but on the whole I think my ability to present has improved. Plus, I think I learned a lot of lessons along the way:
I won’t be speaking quite so much in 2019, but I do intend to continue delivering new talks each time. I’ve found this really does force my brain to work in quite a different gear: I can’t repeat the same talk two, three, or even four times, so I can’t just rely on what worked previously. Instead, I need to constantly be on the look out for new and exciting things to be talking about, which means I certainly don’t get bored much.
I also think it’s time for a fresh challenge, so rather than just attending conferences in 2019 I think it’s high time I organize one. Who wants to come?
SPONSOR Tired of wasting time debugging your Swift app? Instabug’s SDK is here to help you minimize your debugging time by providing you with complete device details, network logs, and reproduction steps with every bug report. All data is attached automatically. It only takes a line of code to setup. Get started for free.
Paul Hudson is the creator of Hacking with Swift, the most comprehensive series of Swift books in the world. He's also the editor of Swift Developer News, the maintainer of the Swift Knowledge Base, and Mario Kart world champion. OK, so that last part isn't true. If you're curious you can learn more here.