Speaking at conferences and meetups can be one of the best things you can do for your career. But for many developers, public speaking is outside of their comfort zone. On top of standing up and talking in front of a group of strangers (or even friends), technical talks are fraught with potential disasters. From broken slides and shitty projectors to dropped internet and bug-riddled code examples, there’s a lot that can go wrong.
Giving a technical talk doesn’t have to be a nightmare, though. It can be a rewarding and even enjoyable experience.
While there are a lot of articles online that go into the actual speaking part of public speaking, few talk about the preparation that goes into creating slides and demos for a tech talk. The last thing you want to be worrying about onstage are your slides. You want to focus on getting your ideas across and educating your audience.
Fortunately, there are a few guidelines you can follow to make sure your slides and demos work well, both from a technical standpoint and an educational one.
Do you even need slides?
This is the first question you should ask yourself.
Some formats — like lightning talks and informal meetups — might not require slides. For shorter talks, slides could serve as a distraction from the point you’re trying to make. And some events, like meetups, are ill-equipped to handle slides. Instead of spending time trying to troubleshoot an old, janky projector, it might be worth it to fly solo and get your points across verbally.
There’s also a cultural component at play when deciding whether or not you should use slides. Some developers have a strong reaction when asked to create slides. Other folks — like Edward Tufte — openly proclaim that “PowerPoint is evil.” While that’s technically true (I’m a Keynote fan, myself), slides can still be an effective way to communicate information.
It’s up to you to decide whether or not you need slides for your talk. But when you do need them, here are some key things to keep in mind…
Design
When it comes to slide design, my best advice is to keep things as simple and minimal as possible. When in doubt, use black text on a white background. In fact, the default “White” template in Apple Keynote is an excellent base from which to work.
It might not be the fanciest theme in existence, but it does its job well.
Your slides’ sole job is to get information across quickly and clearly, without distracting anyone in the audience.
That means that the less information and ornamentation you have on a slide, the better.
As an added bonus, the default Keynote template is very high-contrast, which comes in handy when contending with event projectors. Projectors are notoriously bad. Not as bad as printers, but still one of the worst bits of tech around. They routinely pixelate slides and wash out colors. So my second tip is to keep your content high-contrast. That goes for your code examples, too, which we’ll get into in a minute.
If you want your slides to be a little less stark, play around with adjusting the color of the fonts a bit, or add in a few simple background shapes at a low opacity to create a little bit of texture on your slides. The key here is to keep things subtle so as not to distract the audience.
Two things you should try to include on every slide is your name or online handle (usually a Twitter handle) and the hashtag for the event. Even if you’re not an avid Twitter user, there’s a good chance that attendees will be tweeting about the event and you want to make sure you get the attribution you deserve.
My recommendation is to include both near the bottom of the slide, out of the main content’s way. Reducing the contrast of both elements can be helpful, too.
As far as content goes, make sure there’s breathing room on each slide. Don’t try to cram too much information into any one slide. A good rule of thumb is one idea per slide , use as many slides as necessary to encapsulate all of those ideas.
Most of the terrible PowerPoints and decks that people point to are ones that try to shove a ton of content onto a slide. Ever see a slide like this?
That’s a classic example of trying to make slides work too hard. Pare down those ideas into single slides and talk about the progression between those ideas instead of trying to show it all visually.
So, my three guidelines when designing your slides are:
- Keep things simple and minimal
- Keep content high-contrast
- One idea per slide
If you keep those tips in mind, you can’t possibly stray too far from the path of good slide design.
Including code
Technical talks live and die by their code examples. The audience is there to learn something new, and they want code they can take away from the talk and use once they get back to the office. Your job is to make those code examples easy to understand so that no one’s left scratching their head.
There are typically three ways to do this:
- Live coding
- Include images of the code
- Include actual code as text
Although some people can pull it off, I’m not a fan of live coding during tech talks. There are simply too many things that can go wrong. Simply switching between apps is a nightmare, not to mention things like bugs, frozen apps, typos, and more.
Some people solve the problems of live coding by using pre-built snippets that are triggered via keywords or keyboard shortcuts (think Emmet), but I believe that introduces other problems: Mainly that snippets expand quickly and attendees are constantly trying to figure out what just happened.
Therefore, I highly recommend either including an image of the code and explaining what’s in it, or including code examples as actual text in your presentation.
Including code as actual text has the added benefit of it being copyable (yes, that’s a word) by attendees if your slides are shared after your talk. You can also style the code any way you want. The drawback of using actual text is usually syntax highlighting. Copying and pasting code from you text editor into Keynote, PowerPoint, or Google Slides can have some unwanted side effects, so you may spend an unreasonable amount of time manually formatting your examples and fixing syntax highlighting. There are tools out there to help ease the pain, but your mileage may vary.
The easiest way to include code examples is by using images. Taking a screenshot of your code editor is a quick way to add code to your slides. Another popular choice is to use a tool like Carbon, which gives you beautiful screenshots with a bunch of options for formatting.
Regardless of which method you use, you need to keep a few things in mind to make sure your audience can get what they need from your code examples.
- Use high-contrast themes so that everyone can clearly see your code. The typical dark theme favored by developers does not translate well when projected, and I’ve fielded many complaints from attendees when using dark themes. If you’re using something like Carbon, the One Light theme is a good way to go.
- Use line numbers so that you can easily refer to specific lines of code. It’ll reduce the mental overhead on the audience and give attendees waypoints to right down and refer to later.
- Show what changes between code examples. When adding code to an example, highlight that code (or dim the rest of it) so that attendees know exactly what changed.
Finally, you should try to include a link to all of the code examples if possible. Set up a collection on CodePen, throw up a landing page on your own site, or link out to a gist on GitHub. Then link to it using an easy to read and easy to remember URL. Bitly can be your friend here. Sharing your code on CodePen or via GitHub has the added benefit of expanding your network and elevating your profile as a developer. You never know what code will get a ton of stars and open up doors in your career.
Avoiding pitfalls
My last bit of advice is around preventing some of the more common problems when dealing with slides. Most of these problems can be avoided by communicating early and often with event organizers. See if they have any requirements for slides and make sure you account for them. Some of the more common things to ask about are:
- What machine will be running the slides. Mac, PC, yours, theirs, etc.
- What aspect ratio is used by the projector e.g. is it standard 4:3 or wide 16:9
- Whether or not there will be a hard-wired internet connection on stage, which can effect live coding or linked resources
- Whether or not you can use custom fonts
- Whether or not you can include video and audio
Knowing the limitations of the venue will help you create a successful talk. They may be frustrating at the time, but constraints are almost always a good thing and can help you refine your ideas and how you present them.
Oh, and always carry power cords, dongles, and a clicker with you. The event may have their own, but they are usually the first things to go missing or break.
Share Your Ideas
Again, public speaking isn’t for everyone. But it is an amazing way to share your ideas, lessons you’ve learned, and connect with other people in the industry. It can be stressful to prepare a talk and hop up on stage, but by following these guidelines you can reduce a lot of that stress and ensure that things run smoothly once you’re in front of your audience.
Plug: LogRocket, a DVR for web apps
LogRocket is a frontend logging tool that lets you replay problems as if they happened in your own browser. Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket lets you replay the session to quickly understand what went wrong. It works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store.
In addition to logging Redux actions and state, LogRocket records console logs, JavaScript errors, stacktraces, network requests/responses with headers + bodies, browser metadata, and custom logs. It also instruments the DOM to record the HTML and CSS on the page, recreating pixel-perfect videos of even the most complex single page apps.
Top comments (0)