Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Technical Presentation Delivery Notes

DZone 's Guide to

Technical Presentation Delivery Notes

Whether you are a veteran in giving presentations or are awaiting your first one, here are some helpful tips to make it better.

· Agile Zone ·
Free Resource

I’m writing this post as I’m sitting in the airport, leaving the CodeMash conference. This has been my first “true” conference for a while, because I was able to not just speak and stand in a sponsor booth but actually participate in a lot of sessions and talk to a lot of people. I had a blast, and both the IRS and my wife consider this a work trip.

I have been presenting in international conferences for over a decade now and I wanted to put in a few words for people who are speaking at a technical conference. None of this is new, mind you. If you have been reading any recommendations about how to present in conferences, I’m probably going to bore you. I’m writing this because I saw several sessions that had technical issues in how they were delivered. That is, the content was great, but the way it was delivered could be improved.

Probably the most important factor that I need to mention is: make your content readable.

When you are presenting, use big fonts everywhere. That means that (ahead of time) you should make sure that your PowerPoint's content is readable from the end of the room; if you are presenting code in an IDE, make sure that you know how to increase the zoom so the code is readable. For that matter, syntax highlighting is not an optional feature when showing code. And use the default syntax highlighting for the language you are working with. And no dark themes.

I’m assuming that what you care about is the code, so you want to show that in a way that the people in your talk are familiar with, so no new themes, aqua-on-pink color schemes, etc. Go with the default.

But code is just one factor of it. If you are showing output, make sure that this is readable. That means that if you are writing to the console, make sure that the console font is big enough, use colors for emphasis, etc.

If you are showing XML/JSON/data formats, make sure that they are pretty when printed. If you dump something like this:

image

The audience is going to be too busy parsing the text to actually pay attention to what you are saying.

And if at all possible, use a console application and have no architecture.

If you are actually talking about a React app, you can’t do that, and if your talk is about architecture, you are going to need to show that. But for most cases, if you are showing off some new language feature, or talk about a particular service or API, you want to use a console app to demo it. This is because it allows you (and your audience) to focus solely on the problem at hand rather than looking at the control –> service –> repository magic via DI that hides a lot of the backend details. In general, you want to strip away as much as possible that isn’t directly core to your topic.

Another thing that I noticed is when you want to show additional data (files, artifacts, etc.), make sure that you have them already opened before you start. If you are doing a demo, have screenshots available for when/if the demo mess up.

Everything I just mentioned might seem obvious, but you need to go over that before you go and present. It was surprising to see several speakers make some of these mistakes.

Now, to be fair, that might sound like I’m piling on people, but that isn’t my intention. I’m aggregating a lot of different small mistakes to point them out. They can detract from the presentation, but at least in the sessions that I was at, they didn’t kill the presentation for me.

Topics:
conferences ,speaking ,public speaking ,tips and tricks ,agile

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}