Presenting vs interacting online

Today I ‘presented” at the NYC Scrum User Group on “Remote Agile Games“. I’ve been avoiding presenting remotely. I did do a panel. Today wasn’t bad. I think the key reasons were

  • It wasn’t a lecture
  • No slides (or code). Just me and the audience.
  • Enough people were on video
  • Part of it was a game (so I wasn’t speaking)
  • The audience participated, shared experiences, etc

All this made it feel like a conversation. Which isn’t draining the way an online presentation is.

what i learned about live coding at kcdc

This is a post about my experience. For the live blog, see the KCDC 2021 live blog table of contents.

I planned to do 10 minutes of live coding at my KCDC “Intro to JUnit 5” talk. It was an experiment to do more of that in the future. Here’s how it went.

Coding with people watching

This wasn’t as awkward as I worried it might be. I have coded with a bunch of people watching at work before. And I tried mob programming once at an event. I did have to google something I would have been able to copy/paste at work. But that was fine.

My Focus

I’m very interactive when I speak. I watch the audience. I ask them to participate, raise their hands, etc. I look when they look puzzled or their energy level is going down. When my focus and attention are on coding, this isn’t happening.

Why I should have seen this coming

I didn’t enjoy presenting at online conferences because I didn’t get that audience feedback loop. I was ok when on or moderating a panel because I saw the panelists. I’m ok at my team meetings (which to be fair had participants in locations other than mine even before the pandemic) because they are on video.

I did not enjoy presenting to my computer without seeing the audience. And I knew this. It’s why I have been declining opportunities to present at online conferences and meetups. I didn’t connect it to live coding in a room of people. Oh well. Now I know!

handling mistakes in presenting

Yesterday, I gave a presentation to about 30 teenagers about the upcoming FTC (FIRST Tech Challenge) transition from Robot-C to Java. I agreed to do it a week ago while on vacation. This meant I didn’t have any weekend days to actually write up the deck. I wound up doing it the night before. The concepts were fine, but I figured I’d have at least one mistake in the deck.

I proofread the deck in the morning and corrected some errors. But I still felt rushed and like I missed something. I wound up announcing at the beginning that I had two prizes for the first two students who found an error in the presentation. One kid did. (I had a redundant keyword in a method. It wasn’t wrong per se, in that the program still worked. It was non-standard and not what I wanted to show.) This student got a FIRST flashlight in exchange for his finding. Nobody else found an error.

I liked this technique, because I was that kid who saw errors when I was younger (and still do). I was left wondering what I should do with the info. Does the presenter want to know? Should I keep quiet? Will the presentation be given again? By stating that I wanted it brought up early on, there was no doubt. I think it also helped foster a culture of other questions during my presentation because I made it known that I wanted the audience to speak up when a doubt crossed their mind.

I’ve rarely use this technique at Toastmasters because most presentations are shorter and questions aren’t welcome. And when I’m giving a workshop for adults, I feel like they will speak up as needed. It went well though and I’m thinking I might try the “prize” idea again with adults in the future.

Last week, I met the CEO of Communication for Geeks at the NY SPIN where we were both giving 10 minute talks. While none of the above is specific to geeks, it is a nice coincidence that I had an interesting “communication” experience shortly thereafter.

Another interesting thing that happened was that this is the first time I spoke with an ASL interpreter. I only noticed two differences:

  1. The interpreter wanted to see the deck in advance to prepare. (Luckily she only wanted to see it 10 minutes before and not days in advance!)
  2. For the first few minutes, I was worried about talking too fast. I often speak faster than I should when presenting and was worried if I was going to fast for her. The answer was that I wasn’t. I quickly forgot about it. When asking afterwards, she said the pace was fine. I’m impressed with her buffering because she was always a few words (or more) behind where I was! Luckily, I do pause when speaking so there was time to catch up.