Skip to main content

The joy of long-form talks

In the last two weeks I've given two one-hour talks to my client, one about Spring Cloud components, the other about a vulnerability scanning tool they were using. They served as knowledge transfer talks as I left them after a three-year commitment. I have been listening to long-form talks throughout my Master's and am still listening today. They often demonstrate the extensive knowledge of the speaker and provide inspiration for my work. I consider long-form talks the most important thing that my Master's tutor got me into, as they still bring my joy long after I graduated.

When I talk about "long-form" talks, I usually think of one-hour long talks, although I've seen 45- or 50-minute-long ones where the last few minutes in the hour might be reserved for questions. Such talks are generally tedious to prepare and are sometimes considered deterring. But I believe there is joy for both speakers and listeners in them. I'm not even talking about the ability to focus. I'm talking about the joy just from preparing and listening to the talks themselves.

Joy for speakers and listeners alike

Commitment

Take a look at these two videos on YouTube covering a same subject - move semantics. The first is 13 minutes and 10 seconds long, while the second is 55 minutes and 17 seconds, with the title "Back to Basics: Move Semantics (part 1 of 2) - Klaus Iglberger - CppCon 2019".

The video you choose to watch depends on your situation. You might choose the short one because you just need to get out of a situation, for example, a problem that mentioned the subject, or an opinion towards the subject requested by your boss. You might choose the long one because of, in this particular case, the profile of the speaker and the conference. CppCon is a well-known C++ conference around the world, and the speaker is a senior consultant in C++ software development.

But whichever you choose, you will feel the need of consideration to choose the long one. Because it's long, you will need to plan your time to watch it. In some cases, you might need to consider the worth of spending this much time on this subject. That extra thought makes the choice of the long talk harder. This also means, by choosing to watch a long talk on a subject, the audience have made a tough decision, and are more likely to commit to it. To speakers, this is an encouragement, since you know if a person turns up, it will listen.

Quality of content

Preparing for a long talk presents additional challenges. In particular, speakers will need to keep the audience engaged during the one hour. Simply adding rumble on each slide is obviously not the best way to do this. Live streams tend to contain a lot of rumbling and thus, I prefer not to watch them unless I need some entertainment. Because of this challenge, the audience can assume that if a long talk has made its way to the conference, it will be engaging in some way.

Another challenge is in the content. If there isn't much to say about a subject, it will not be possible to write a one-hour talk on it. When that happens, two most obvious strategies are to add breadth and add depth. Both have things to consider. When adding breadth, the speaker must make sure the talk still focuses on one central idea. When adding depth, the speaker must consider the audience so that the talk doesn't go too deep to understand or to be relevant. Good speakers know how to balance these. The audience can assume that as well.

Comparing the two talks

While both talks I gave appeared to be well received, I consider the first much more successful than the second. In particular, the second went so much over time that I had to skip about a third of the content. Here are some lessons I learned from giving the two talks.

The successful talk was scripted

By scripting, I don't mean to write a script of what to say and present it as-is. Reading a script can easily make the talk sound robotic. However, a script helps with tracking time. In an English speech, a speaker is estimated to deliver 130 words per minute, or 100 words if the speed is lower. I consider my speed of speech below average, so I used 100 words/minute as my estimate when I wrote my script. I also padded 10 minutes in case I get a question or plan an interaction at some point. So my transcript should be about 5,000 words long. This estimation exercise is especially important for long talks, since delays can accumulate.

A script also helps with polishing the talk. I wouldn't be able to review what to say and adjust my choice of words without a script. It also helped removing duplicate content in the talk, early, as I wrote it. 

Live demos are good, but they have limitations

Live demos are a great way of engaging the audience. As soon as the demo is open, the audience become eager to watch your magic (and your mishaps). In particular, if you show a situation that the audience don't expect, they will try to recall the content covered just minutes ago and understand what has happened. This immediate feedback is known to strengthen learning, which is the whole point of the talk, so I try to include one of these in my presentations where possible.

However, this also brings a danger. Not only that live demos sometimes require extensive setup, but also the audience might be so excited that questions start to queue. This introduces significant delays. Also, unless there is recording setup, when the demo is gone, it's gone. If the audience are expected to reproduce the demo-ed procedure after the talk, which was the situation in my talk, related steps and expected outcome  must be included in the slides, regardless of whether it was demo-ed live. 

In a "shortened pre-release" version of my second talk, I demo-ed the tool and got so many questions that the shortened content itself (about 1/3 of the actual content) took almost the whole hour. 

Focusing and providing relevance always work

When preparing the talks I kept focus and relevance in mind. The two talks were given to my client as knowledge transfer talks before I left them, so the way they currently use the subject tools automatically becomes a relevant experience. This also helped when adding breadth and depth of content to fill the hour. 

In the first talk, I focused on the components my client used. For each component I included code snippets showing their usage. But before that, I included a summary of all configuration options available (adding depth) and where to find information about them. At the end of many  components' sections, I added a reference to a conference talk on how it is used at other places (adding breadth). 

In the second talk, I focused on the various aspects of a CVE and how they connected to the client's processes. Before that, I added a brief section on the parties that might appear in a CVE record (adding breadth). I also included a deep dive section on Maven's dependency mechanism (adding depth), since a lot of vulnerabiilty remediation was about version upgrade. 

I did a few things to provide a focus and relevance, but to actually make the audience feel them, there was one more things to do.

Repeat

Repetition is a common technique used in symphony composition. In a piece, a chord is repeated three times at the beginning to establish tonality, and a phrase is repeated at many places to establish itself as the theme. In my talks, I used repetition to establish the focus of the section, in very subtle ways. 

In the first talk, when I explained the setup steps of a component, I included the name of the "parent step" in the title of every slide of the "child step", and revisited the overall setup steps and showed progress at the end of each. Including complex nested steps like this is best avoided, but depending on the actual process this might not be possible. In the second talk, I had the word "dependency" every two or three slides in the dependency mechanism section, and the phrase "false positive" every few slides in the dispute resolution section. These subtle 

Next talk?

Many conferences have restrictions on who can speak there, usually around experience in the industry. Large conferences can require an extended abstract and peer review before a talk can be presented. These are all measures to ensure the content quality so that when a person watches the  talks, they can be confident they are not wasting their time. For years I have enjoyed watching talks from those large conferences, and I still don't consider myself a match with those speakers. They are industry leaders indeed, both in their work and in presenting.

Community talks, on the other hand, are less restrictive, though with less content quality guarantee. The problem, though, is that there is not a lot of such communities where I live. I don't speak Chinese very well, and English-speaking communities are scarce. For this, I especially appreciate the client for giving me an opportunity to give these talks. The manager from New Jersey and another colleague from India were especially supportive. I've always been dreaming about giving a one-hour talk on the stage. I don't consider myself ready yet. There's a lot to learn, and that also means a lot to enjoy.

Popular posts from this blog

Word Cloud with SvelteKit and D3

Word cloud of this post I mostly do Python and server-related work, so why suddenly a word cloud, in Svelte and JavaScript? I made a mistake in my last post. I didn't know Blogger would use the first image I inserted into my post as the thumbnail picture of my post. This thumbnail picture apprears in both my posts view and when I share my post elsewhere. The first picture in my last post was a screenshot of the Python extension in Visual Studio Code when I discussed how many children mistook that as the Python interpreter. So when I shared my post, it looked like this. This is obviously less than ideal, and it gives an impression that I made a same mistake as the kids. But I had no idea what my thumbnails should look like yet. Word clouds are visually pleasing, although not suitable for statistics. I think they will make good thumbnail pictures for my blog posts for a while, before I come up with a better idea. So I made a small web tool that makes word cloud from a Markdown doc...

Why is Python not as popular as Scratch at school?

People who know me would know that I volunteer at a coding club for young people. They program in Scratch and Python. School is back soon, so it should be a good time to consider what to do for the upcoming term. In particular, I want to think about why Python is not as popular as Scratch at school, and what we as developers volunteering at coding clubs can do about it. One obvious reason Python is disadvantaged is game engines do not provide assets. And we have to be honest, as software development professionals, design skills are not our expertise. It is not just the visual aspect either. In fact, you can see all the aspects of designing a web application in the side bar of Material Design page , but in a nutshell it's visual, audio, interaction, usability and many more. We often leave such design work to specialist UI/UX designers, if we consider such work at all. But what are other things that make Python less considered at school? Python requires installation One thing...