Presenting Code

by Jens Weller

At CppCon 2015 I decided to give a small lightning talk on how to present code in the coming year. This was a reflection on visiting many C++ related conferences and seeing many talks live and online:

What first got me thinking on this, was Scott Meyers Keynote at Meeting C++ 2014, the 2nd part to be precise. It was Scotts last great public talk, and he decided to share some of his thoughts on how you should prepare your materials for the "modern age". He talked about much more then just doing slides for presentations, but I'd like to focus on this topic. A first reflection on this were the speaking guidelines I've put up for the Meeting C++ conference in 2015 (I'll update them, um, soon).

Audience

tl_files/mcpp/slides/Presenting Code - Jens Weller - CppCon 2016_page_0003.jpg

Lets start with a main difference for giving talks in a user group and at a conference: your talk is likely to be recorded in the conference setting, and shared on youtube/vimeo or other platforms later. Maybe you do your own recording too. Means when preparing a talk, one has to think about this situation. It means that a large part of your audience will not be with in the room, it will be world wide on the internet. So your slide deck should reflect this, this often also benefits the audience that is in the room. This is the audience you are giving your talk to.

The audience in the room has a few less options, then those watching the recording. They can't pause, speed up or jump to the end of the talk. They're likely to ask questions, and often made the decision, to see this specific talk. Thats why its normal that some people leave at the beginning, don't get nervous by people leaving the room.

Also important to know, is the room it self. CppCon likes to do double projections, as some rooms are only useable like that. While in the past 4:3 was the format for slides, the trend today goes towards 16:9, ask your conference organizer/speaker contact about this (I usually share this in advance, for this year its 16:9 in the A & E Track, and B-C are 4:3).

Slide design & Code

tl_files/mcpp/slides/Presenting Code - Jens Weller - CppCon 2016_page_0008.jpg

Make your slides easy to read, don't expect your audience to read a wall of text. Pick a certain theme and stay with it, have clear colors and good contrasts. But there is today lots of programs and formats to prepare a presentation in, often they already offer different slide designs. These can be a great start. Slide numbers will help a lot if you are expecting the questions at the end of the talk.

Code isn't really made to be presentable, often its not really well supported to get it into a slide deck can be quite hard. Power Point or Open Office (which I usually use), are not made with the goal to present code. There is js/html based presentation systems, which allow you add sections for highlighting. So this depends very much on which tool you use to create your slides, and how well you know your options within this tool. As I use Open Office, I have opted to choose no highlighting and and simply mark the important parts I'm going to talk about:

But, here lies an evil trap. Its not enough to copy paste your code into the slide, highlight the sections you want to talk about. Also nobody compiles slides, so its ok to remove visual noise, it will make it easier to focus on the important parts. Do you really need highlighting for your code? Traditional highlighting focuses on keywords and "lexer tokens" like strings. This can be great when giving an introduction into a programming language, but might distract when speaking about language features. I often prefer to have only highlighted the part I actually want to talk about, and even then I often choose normal/fat font as the highlighting instead of IDE like syntax coloring.

tl_files/mcpp/slides/Presenting Code - Jens Weller - CppCon 2016_page_0006.jpg

Another great method for highlighting parts of your code can be "speech bubbles", which is a good method to comment your code on a slide:

tl_files/mcpp/slides/Presenting Code - Jens Weller - CppCon 2016_page_0009.jpg

This picture also highlights something, that is often out of your control: the lights in the room it self. Maybe its even the sun it self, that makes your slides harder to read. Yet digital cameras are much more affected by this then the human eye, the slides in this talk were readable. But I have seen this being an issue every now and then, especially when the lights are turned on for the recording, as otherwise the speaker wouldn't be picked up by the cameras.

Also code can be easily a wall of text, which is great to show as an overview or the bigger picture. But when going over the details it might be a good idea to focus on them. An overview slide followed by one or more slides only showing details is a good way to help your audience to focus on your presentation. Especially if they watch the recording.

There is also the option of doing a live demo or just presenting code in an editor, which can work out very well. You will need to adjust some things like font size, and maybe highlighting.

Last, let me cover what to do, when you need to react on a live event on your slides. The classic "laser pointer situation", where some one asks a random question about a slide, be it code or not. The best way to handle this for the live and recorded audiences, is to be able to draw on your slide. This is a little known feature, and at least Open Office/Power Point can do it, and there is also programs which offer this outside of your presentation tool. For Open Office you will find it under Presentation -> Presentation options -> "use mouse as pen".

Laserpointers

Please don't use them, while they are great to give presentations to a smaller group, they fail in larger rooms, and don't expect to have always perfect lighting in your room. I do have trouble to see the dot every now and then, also its not recorded. So choosing to highlight what you are talking about with a laser pointer is failing for the part of the audience that is not in the room. Also it makes you turn towards your slides, and in case you don't wear a (headset) microphone, the audience might not hear as good what you are saying.

tl_files/mcpp/slides/Presenting Code - Jens Weller - CppCon 2016_page_0013.jpg

And also, what do you do in a room with double projection? Do you bring two laser pointers? Do you first explain to the one side of the room, and then to the other? Also how do you handle this when you have 3 projections? Or more?

Slide++

C++ and other programming languages are complex and often its a good habit to do this or that. But often, on a specific slide you want to make a point, focus on a certain detail. As said earlier, nobody compiles slides. So its useful to limit code on a slide on what your are trying to say. As long as the audience can understand the context.

I've seen the term "Slide++" used in this context quite often, and it explains perfectly, why a certain piece of code lacks usual things. Like the std:: other namespace qualifiers, or any feature not needed to present what you are talking about. This can be visual again in an overview slide. When details matter, it can be good only to show the part of the code that is important to this detail. Longer code lines mean smaller fonts and less readability to your audience. Yet it is a good idea to mention this a the beginning of your talk.

What should you talk about?

Um, this is actually outside the scope of this blog post, but...

When submitting a talk... There is of course the experts, which present the expert presentations. If you maintain a certain library or part of a standard library, thats low hanging fruit for you, while its probably for others not the first thing they'd pick. But you don't have to be an expert to start presenting on some topics. A great way to start is to give a presentation as an overview of a certain field. When you had to do research on which library to pick for your project, and you reviewed 3-4 libraries, you got your topic. Talk about your use case, present the different libraries, and help others to choose for their tasks the right library. Also, a great way to start speaking is preparing a lightning talk.

I am now for a few years in the program committees of C++Now, CppCon and Meeting C++. In the first two committees I'm just a normal member, at Meeting C++ I also have the role of doing the final selection. So, I am very well informed on what kind of talks get submitted to these conferences. I think there is a lack of talks giving an overview or introduction, and often a large set of talks on popular topics (Functional Programming, Concurrency/Parallelism, new Language Features,...). Also my impression is, it would be great to have more talks on cooking instead of talking about ingredients. Submitting more then one talk also means a higher chance of making it as a speaker to a conference, same goes for submitting your talk to more then one. Especially when you submit for a popular topic, it might be already covered by other speakers. And, conference organizers can only select on what gets submitted, there are areas which aren't or not very well covered by conferences in your domain. So, when you think "why is there no talk on topic x?", you might also already found a good topic and reason to give this talk!

I might write a follow up on general things in speaking later, but for now I'd like to stay focused on presenting code, so thats it for now :)

 

Go back

Follow Meeting C++

tl_files/mcpp/yt.pngtl_files/mcpp/gplus-50.pngtl_files/mcpp/twitter.pngtl_files/mcpp/facebook.png