My Slightly Less Painful Time Zones talk was the first talk I’ve done that had code in it, so I learned some new things about making slides that have code on them.
Setting up the slides
According to trusted references, it’s best to go with a dark-on-light color scheme than a light-on-dark one you might work with normally. The reason for this is how projectors work, apparently? I didn’t test or question this too much but I’m happy to accept it as true.
When I first put together some draft slides, I just did quick screenshots of my code in the text editor. This become unwieldy pretty quickly; the inconsistent sizes of the images bothered me and it was annoying to have to take a new screenshot every time I noticed a small error or correction that I needed to make.
Then I learned about plugins that let you copy code with syntax highlighting in them! I found this SublimeHighlight plugin that lets you copy your code with its own specified color scheme independent of your actual Sublime theme. Pretty neat! The default color schemes available weren’t perfect when I tested them but I ran out of time to tweak the tool setup and did end up adjusting some of the colors directly in the slides. I decided I vastly preferred code as text on the slides, rather than images.
For console output, normally I use iTerm (to have numbered keyboard shortcuts to move between tabs), but it wouldn’t copy over output with RTF. The Terminal program does, though, so I just used that.
What to show on the slides
I had gone into the slide-making process thinking that I needed the code on the slides to prove I wasn’t making up the stuff I was talking about, so it was kind of a defensive attitude at first. After a practice run, my talk mentor Jason made this excellent point:
Code slides are generally primarily meant to convey information and are not meant to be code that can be immediately downloaded as is to be run.So a better approach is to figure out what’s actually important to highlight for the points of discussion in that section of the talk and only show those pieces of code on the slide.
Thinking back to my own experiences, there’s a fairly low limit to how much code on one slide that people can absorb, so removing some of the extraneous stuff needed for setup or breaking things down into smaller pieces by using helper methods (that you don’t actually have to show) is totally fine. Other tactics include showing the whole block of code at once, fade out, then highlight the code line by line again to review.
The main way I ended up doing it was judging based on each slide whether I wanted to build it line-by-line (often useful for console output) or if there were certain sections that I’d just build as a paragraph group together to go with an explanation like “these lines do __this one thing__.” If you peruse the slides, you should be able to get a rough sense of this since I exported the PDF to have the different slide builds all in there.
