PSConfEU – lessons learned

PowerShell Conference Europe was closed more than a month ago, but that time was filled with the content from that conference. For the first time you don’t need to remember where to find videos – it’s actually quite hard to forget it. Thanks to Tobias all videos from this PowerShell conference can be found under URL (surprise – surprise!) PowerShell.video What is great about these videos from my point of view (a speaker that is not as experienced as many other presenters, with pretty wide margin for potential improvements) is the fact that most of the sessions where record with picture in picture technology – you can see both the screen shared by the speaker and the presenter in person. In other words: I can learn from example (by watching the best) and from my own mistakes.

But that’s not the only source of wisdom: this year I had a few serious mishaps that resulted in both large portion of stress and some serious mistakes in my presentations. In this post I would like to share what I’ve learned from the mistakes I made, what I think went good and what I would like to continue or even expand on.

Before I went to Hanover I told my wife that it’s pretty important to get the first presentation right. But there are two sides of this coin. Once you fail on the first, it’s hard to shake it off and get following presentations right.

And boy, my first session (“Hell Freezing Over – PowerShell on Linux and GitHub”) – even tough I felt well prepared, came out well below my usual level. And the reason for that was pretty bad technical issue and absence of “plan B”  that I could use in the presence of that problem. So what happened? My laptop’s video driver was causing issue that would prevent me from connecting external monitor. Actually, without any monitor connected I already had 3 screens: 2 in the “duplicate” mode and one completely invisible, in the “extend” mode. You can see explanation of the problem here. In the end I managed to present, but I was presenting using 3rd screen. Read: any window started would show up on the screen that was (both for me and the audience) completely invisible. I was planning to do most of my demos on Linux VM, so once I could see it, I was not willing to attempt anything else. The problem though was that my VM (despite my attempts and help from friendly attendee, Tobias – thanks again mate!) was not internet-connected. I was convinced that this is not a problem until I’ve tried to demo PowerShell installation, showing GitHub issues, using REST endpoints… A lot of learning material on that one already… Let me list them in more-or-less order of importance, at least from my point of view.

1. Always record demos and copy presentation/ code/ slides to USB stick. Live demos are the best, but if everything else fails, it’s better to show a movie than troubleshoot/ apologise all the time. And organizers probably have a laptop that “just works” on which it is not necessary to move a window from the invisible, ghost screen to the one that people see in front of them.
2. Prepare much, much more demos. If I would have more demos of PowerCLI on PowerShell Core, I could spent much more time on that during my presentation and absence of Internet would not be a problem. Just be sure to know how long (more or less) each demo takes. It’s also not great if you have to stop a demo in the middle or skip some sections when things just work.
3. Test equipment and system behaviour. Even if your laptop worked just fine with external monitor last time you’ve used it and you don’t recall installing any updates since. I had exactly that problem: my video driver got updated (probably I just confirmed suggested update when asked without giving it second thought) and this version had a bug that caused whole multi-screen mess. If I would look at the graphics settings before I went to Hanover, I would spot that there is something fishy going on before and could avoid all the mess.
4. Make sure your backup plan for no-network scenario (or any other backup plan that you want to prepare) actually works. Disconnect laptop, disconnect VM and test, test, test. I was convinced that copying RPMs for packages that I wanted to install on my Linux VM would solve the problem in absence of network. Instead, yum decided to check dependencies and was not able to figure them out. If I would test it before, I would knew that my “backup plan” was giving me an illusion of safety net. Trust me: the net like that is not something you want to rely on when you start to fall…
5. If possible, test your setup as soon as possible. I’m glad that my session was just after lunch so I had some time to figure out solution or work around for my problem. Else I would not be able to start on time. If you present you have responsibilities, so try to test even if it means you won’t be able to see session before yours, or you will have to skip some good time with other attendees/ presenters. Or like it was in my case – skip lunch. Ouch…
6. Something I got as a feedback from friends who attended my session and were also many times in presenter shoes: don’t apologise every five minutes if things are not working as you expected them to. People in the room already know that you are sorry. And odds of people entering the room after presentation started (read: number of people that were not able to hear your apologies) is pretty low. So apologise when apologies are due, but don’t do that every five minutes.

For my second session (“Knock, Knock, Knock – Linux at Your Door”) I was prepared way better. First of all I’ve fixed issue with video driver and I’ve tested connection before any other presentation on that day (in the room where I was going to present) to make sure it really works. If it wouldn’t work I still had some time to find a better solution. Also my backup plan for no-network was more solid. I just recorded parts where I install packages from internet. If it would fail, I could play video and just bite the bullet. As attendee I usually don’t like when people just pretend to do things and replay some recordings, but I think there are times when going “live” is not crucial for demo quality.

So, was my second session perfect? Certainly not. But to realize that I had to watch the recording (that’s were picture-in-picture started to give me some ideas on what I can improve). Moving on to lessons learned from session number 2:

1. Gestures are important too. I was watching myself present and I realized that I had been doing something weird with my face that day. It looks like my forehead was a center of some super-itchy infection. I was scratching it like I had nothing better to do with my hands. Not only it looks weird, it was not helping with my voice “distribution” at all.
2. Either speak up, or shut up. Few times I had some unexpected problems, including dying internet close to the end of presentation. When I noticed such problems I muttered something to myself. Instead, I could just turn the whole thing into a joke or just ignore it and move on. I’m pretty sure bad memories from the previous day were to blame for that reaction, but in the end – who cares? As with any other professional situation, I should focus on here and now.
3. Never assume people follow you or subject you present on. Few times I behaved like I was sure that people in the room where also there day before on my PS on Linux session. Why? I really don’t know. Perhaps because both sessions were kind of Linux related? Still: when there are 4-5 tracks at the conference there is really no benefit (at least in my opinion) in building relations to the content that attendees might not have seen. That includes both your presentations and presentations that came before yours. I did the same mistake with Ben’s presentation that I’ve mentioned. It’s better to focus on the subject at hand and avoid any “in the previous episode” digressions. It works with TV Shows, but sessions during conferences are more like movies.

Finally, the last day came. And I would say that I pretty much liked how my last session (“TabExpansion Plus Plus in Examples”) came out. The only thing that I got from this one: always make sure that people responsible for supporting conference (in this case nice lady responsible for starting the recording) are present before you start the session. I was already wrapping up my intro to the session when she stormed in the room and notified me that I can start talking NOW. Oops?

So was it all bad? Nope. There were two big highlights in my opinion, two things that worked out very well.

First one: the idea with asking my kids to draw pictures that I could later use in my presentations. They nailed it. I gave them some ideas, but for the most part – it’s all their work, including ideas. It gives me confidence that nobody will accuse me of using their work in my presentations without payment/ permission/ proper credits. It make my presentations different and a bit unique. I get pictures created with my content in mind. And proud dad in me is satisfied. And last but certainly not least: my kids feel like a part of my team!

Second: using physical objects. In my second presentation I’ve used puppets to role-play situation of Windows admins when talking to Unix/Linux admins. In my opinion it was a very good way to start presentation and get people interested in the rest of the content.

To summarize: I could prepare better, I could perform way better, overall it could be much better, but I hope people that were attending my presentations enjoyed it and I didn’t waste their time. You can see for yourself: all my sessions are available online. Unfortunately, first one was recorded without first few minutes, so you won’t see me explaining my unusual monitor setup. In order of appearance:

1. Hell Freezing over: PowerShell on Linux and GitHub.
2. Knock, Knock, Knock – Linux at Your Door.
3. TabExpansion Plus Plus in Examples.

Please let me know what you think. Were there other mistakes I made that I missed in my overview? Did you attend/ enjoy any of my sessions? Any feedback is welcome, negative feedback is preferred.

Advertisement