Thoughts and Feelpinions on Public Speaking

Recently I had the pleasure of being part of the Perth Visual Studio 2019 Launch Event! This was fairly nerve wracking as I'd never done any public speaking before, and was a deliberate choice on my part to break the ice. I'd signed up along with 6 of my colleagues at Readify, and we split the launch event into several discrete pieces, each of us taking on a separate high-level component of something that made VS2019 tick.

I took on, god help me, the Xamarin changes in VS2019. I have some complicated feelings with regards to Xamarin but I have a great deal of respect for the underlying technology and what it accomplishes within the constraints set by the respective native platforms. And after glancing across the landscape of what VS2019 was changing I thought, 'stuff it, I'm doing this'.

I had an absolute blast.

However (and there's always a however lol), there were some things I didn't particularly enjoy. I also learnt a great deal, about public speaking and event planning in general which I thought I'd talk about in this blog post. This is a retrospective, of sorts, in which I'll talk about my experiences with this event - both good and bad - and the learnings I've taken out of it. Now, I tend to run my retros in a similar way across most of my engagements (whether or not this is a good idea is a debate for another day), so I'll break down like this:

What went well?
What didn't go so well?
Are there any learnings/improvements for the future?

Lets dive in!

What went well?

To start with, my presentation. I felt very... comfortable with what I was doing and what I was presenting. I think this is essential if you're ever planning on public speaking. That's not to say must know every single thing about what you're talking about, but you definitely need to know enough that you can at least find out the answer if you get thrown a curveball question at the end... Which I guarantee will happen. My general vibe tends to be quite conversational when presenting (which is nicely in line with my blogging style, actually!), and I felt it flowed mostly well when it came down to it. Practice is also very important, unless you're a veteran and/or you know the content like the back of your hand. And even then, I'd still say you want to practice. You don't need spend hours and hours practicing (I think I probably spent an hour and half in total practicing my 20-ish minute presentation), but it helps from a flow perspective.

The event went by without any major technical problems, aside from a few times the Demo God saw fit to smite some of the demos the team was presenting. That's very much a normal presentation "thing" as far as I'm aware so I don't think it's a thing we need to stress about.

The team worked really well together, and given the amount of people we had speaking, it was awesome to see everyone come together and give feedback where necessary. And this includes both good feedback as well as constructive criticism. Having someone/some people you can trust to provide solid, honest feedback is essential for public speaking. Especially for someone like me, who can go a little too off the deep end sometimes o.O

I got a few curveball questions during my presentation that threw me completely. To the point where internally I was thinking "shit, how on earth did I not consider that?!". So I simply said "I don't know." Better to say "I don't know", and go have a chat to them afterwards and find the answer together than to try and bluff your way through it. Technical people can be pretty brutal so trying to bluff your way through something can be a recipe for disaster. Thankfully I avoided that pitfall.

What didn't go so well?

Initially I went way, way to deep for what was supposed to be a high-level, 20 minute presentation to an audience that potentially didn't care about Xamarin. I went compiler deep. Now, while the compiler changes were an essential part of what had changed under the hood in Xamarin for VS2019, the level to which I was explaining things was far too detailed for a session like this. The main learning I've taken out of that is to make bloody sure you figure out who your audience is and adjust your content accordingly. I took longer than I should've to get this through my head, but I got there. :)

Something I realised throughout this process was "I don't like being constrained with the content of what I'm talking about." When I said above I went too deep, I really meant it... But holy shitsnacks I had such a blast on the way! And it made me really sad to have to cut content to fit the audience. The extra context-setting this information had, from a Xamarin perspective, was really fascinating. At least to me :) The next talk I plan to submit will definitely be on my own terms, and I'll let the people/selectors voting on talks decide if they care enough to hear more. Though the active choice of talking about what I want to talk about is really important. It washes away any fatigue you might having being up late trying to finish your presentation because the content is riveting.

The Demo Gods took a few potshots at some of my colleagues during their presentations. Now while this wasn't ideal, and even understandable, it still broke the flow of the presentations. There's actually a couple of learnings I took out of this;

Demo's are fraught with danger. Coding is hard in a nice safe environment at your desk during your day-to-day work, let alone live-coding in front of an audience. Be very wary of this if you're choosing to do a Demo, and specifically a live-coding session. I actually decided to cut one of my demos at the 11th hour, due to some really, really, really frustrating shenanigans with Xamarin.Android that were simply not playing nice. I wasn't trying to do anything particularly tricky either, exacerbating the frustration I felt. I found that sometimes its a good idea to cut a demo if you feel it puts the general flow of your presentation at risk.
You should always have a backup if your demos go pear-shaped. This can take the form of extra slides that you can talk to, or perhaps even have a short video recorded in advance that you can fall back to. Then you simply speak to the demo, and you minimise the risk in throwing off the flow of your presentation.

Another thing I didn't particularly enjoy was the anticipation in the lead-up to the presentation. Unfortunately I am in the habit of "just wanting to get started/get it over with" when it comes to getting stuff done, and this also applies to things in my personal life. This is something I'm actively working on, so hopefully this will get easier as time goes on.

We got made aware of this event with a little less notice than we'd usually like. As such this resulted in the team putting a few extra hours here and there. This isn't a massive deal, but very annoying. My main learning from this is if I'm submitting to do a talk I want to have the content and demos prepared before I submit. This takes away that time pressure, and gives me more time to refine and practice the talk.

Are there any learnings/improvements for the future?

This section forms a neat summary of some of the learnings I've outlined above.

Know your content well enough, and make some time to practice. By yourself, and with others.
Understand when to take constructive feedback, even if it kills you a little inside. Other people will have perspective you wont, and that can be very valuable.
Understand the audience you're presenting to, and make sure you tailor the content accordingly.
When putting your hand up to talk, pick content that you're passionate about.
Demos can go horribly wrong, so make sure you have a fallback you can rely on.
Don't be afraid to cut a demo if it feels too risky, or you can't get the code to behave when you're coding it by yourself.
It's ok to say "I don't know" to questions that throw you for a loop.
Ideally, have your content and talk planned out before you submit. This will take a good amount of pressure off and you'll be much more comfortable putting your hand up to talk at something.
Next time I'm going to record myself, even if its just audio. I know during practice I was using a lot of filler words like 'um' and 'so', and for the life of me I can't remember if I was doing that during the actual presentation lol. It went by so quickly I blinked and was sitting back down. I was annoyed I didn't think to do this, so its something I'll be addressing next time. This is so I can hear my presentation style for myself and make my own criticisms and improvements.
Buy a presentation clicker. These little gizmos are wonderful, and provide something useful for your hands to be doing, you can use it to emphasize a point, or actually point at things. Fun.

And there we have it. I'll have a blog post covering the content I talked about come up in the next few days, but until then hit me up on Twitter if you want to chat some more about what I've talked about today :)