Hacker News Reader

13. Have a message you're actually enthusiastic to tell people.

The audience can quickly tell if someone is there because they want to talk about the topic they're presenting, and having a receptive audience makes it much easier to get on stage to talk about it. If the audience knows you're there because you want another line on your resume or because you're trying to sell them something the atmosphere can turn quite cold and that is a world of pain for a speaker.

it's physically painful for me to stop talking about my topic

LOL. I get writers' cramp every time I write a check.

That’s funny because I get dementia every time I have to use my debit card. No matter how many times I think I know where it is, it isn’t there.

it's physically painful for everyone else to listen to you talking about your topic.. if you talk for too long that is. :)

Indeed! It's said that no talk should be longer than a microcentury.

https://www.ams.org/notices/199701/comm-rota.pdf

https://susam.net/microcentury.html

Nice one! I would've said half a microcentury would be the perfect limit for most school lectures, but for an engaging talk a full microcentury would be acceptable :-)

The (in)famous astronomer Tycho Brahe died from a bladder infection after politeness prevented him leaving the audience on such an occasion.

https://en.wikipedia.org/wiki/Tycho_Brahe#Illness,_death,_an...

> if you talk for too long that is

I've made that mistake. Talking for longer than 50 minutes is a bad idea.

> 11. the anxiety goes away

It is genuinely shocking how true this is. Also, it's not a gradual thing. I used to be very nervous about public speaking. I did it a lot and one day it just stops. Very sudden, very unexpected.

I still have it, but it goes away as soon as I start the presentation. Then it just becomes fun!

A shot or two of liquid courage doesn’t hurt either. Though beyond that you risk exceeding the Balmer peak.

Don't drink coffee before going on stage. At least when you're old like me.

That's not what liquid courage means ;)

(Though that is otherwise good advice!)

I don't think I'm alone in finding it quite suspect if people walk around smelling of "liquid courage" in professional settings.

Yeah, I still get a bit of stage fright especially in a large room but, as you say, it pretty much goes away once I start "performing."

#8 - If someone absolutely insists on a demonstration and otherwise has to "do it live" this makes you look like a god on stage - https://github.com/sloria/doitlive

Basically just schedules whatever code you want to run so when you invoke the script it will step through whatever you want to run no matter the keystroke you make. No mistakes!

Yup!

> 8. avoid typing in code as part of the presentation, most of the time it won't work and it's boring watching somebody type

This can absolutely be made to work very well. When Josh Long did this at Goto, it was an absolute masterclass. He used timed zooms to almost turn it into comedy. The rehearsal involved must have been considerable.

Might want to link the talk, he's a rather prolific speaker.

> 9. render the presentation as a pdf file, so any device can display it

That's good as a backup, or for simpler presentations (in a good way!) but Powerpoint allows you all kinds of benefits like animations or transitions. Presnting PDFs is not guaranteed to be pain free as well, as I expereince on my corporate controlled laptop with stange versions of Adobe software.

> 11. the anxiety goes away

It does! also remember that the audience doesn't know what you are going to present, so they wouldn't care if you make mistakes.

I will add

13. Practice and learn speaking, a good start could be Vinh Giang's Youtube channel

> Powerpoint allows you all kinds of benefits like animations or transitions

I know. I just go for very basic stuff - large fonts, black text on white background, no border, no colors. I ruthlessly eliminate everything but the point I'm trying to make.

Generally, I'm fully on board with the "eliminate everything but the point" philosophy, but transitions can be really useful for displaying that the same element is present in multiple slides. I've had a few cases where I've shown a "before" diagram/code sample/whatever, then on the next slide shown the same diagram again, alongside an "after" version. But the layout I use to put two diagrams on the screen is going to look different to the layout I use for just one, which means the original diagram is going to jump around suddenly.

A ~100ms transition where the first diagram moves from its place on the first slide to its place on the second slide ensures that a person looking at the slide understands very intuitively which of the two diagrams is the original, and which one has been added. It's not perfect (e.g. you'll miss it if you're not looking at the slides at the time), but for diagrams or code samples you generally want the audience to be focussing on the slides, so it typically works well. And in 90% of cases, even if you do miss it, it'll be obvious after a couple of moments' thought what's going on, but the transition saves you those couple of moments.

I could just show both items on the first slide, but I find it's often pedagogically useful to explore the initial state by itself, rather than jumping straight in with the comparison. That way you can motivate the comparison more clearly by identifying the issues with the initial state (be that a code sample, a diagram, whatever), before moving on to the comparison with a potential solution.

If it weren't for this one use-case, I'd probably also switch to PDFs, because I've been bitten by presentational issues before that would have been a lot easier to solve if the presentation had just been available as a PDF.

> Powerpoint allows you all kinds of [things] like animations or transitions

Those are not benefits. Do not do those things. Anything more complicated than embedding a video is a distraction and will not help your presentation. (And the video can be done by alt-tab to VLC or linking YouTube or ... .)

Seriously, trust me on this one.

I have seen a lot of presentations in my day, from sales engineers trying to sell me on things to literally hundreds of guest speakers from all over the world back when I was in grad school. That last one was especially valuable, because I got exposed to a huge variety of speakers and styles, not just a monoculture from one place or company.

And the best of them either never used that crap, or it passed through my brain leaving so little evidence of its existence that it may well never have been there to begin with. I only remember the bad associated with that stuff: a speaker once had to answer a question, went back a couple of slides (fine so far), then had to wait fifteen seconds or so for his dumb, contentless transitions to play out, each slide he advanced, trying to get back to the slide he wanted to be on. Stuff like that is all that's in my head when I think of transitions and animations. The best speakers really do just never bother with it in the first place.

>Those are not benefits. Do not do those things.

>The best speakers really do just never bother with it in the first place.

This person has a preference which is not universal despite them stating it like a universal truth. I have also watched hundreds of presentations (and presented dozens), so I'm at least as equally qualified to say:

A fade between slides, fading-in bullet points or a picture on a slide as they become relevant, underlining/bolding/changing the color of a word to draw emphasis to it after the fact, etc. All of these can be perfectly fine. In fact, I think these small details can turn an okay slide deck into a well polished one.

>[...] had to wait fifteen seconds or so for his dumb, contentless transitions to play out, each slide he advanced, [...]

But yes, don't make your transitions 15 seconds. And if you're going backwards or skipping ahead, you can skip animations. You don't need to let it play out.

Also important to keep in mind that a good (or bad) slide deck alone does not make a good (or bad) presentation. The speaker and their knowledge + passion for the topic is what is important. A good slide deck is just a bonus.

I agree with that. I do experiment with different slide styles and may use a quick fade-out/in but I don't use Powerpoint any longer and keep things pretty simple. Sometimes slides are more graphically heavy than other times. But rarely use much of the Powerpointish slide chrome. And I'm not really a designer and will mostly mess things up if I try to get too cute.

Instead of making animations to do bolding/underlining, simply copy the slide and then bold/underline it. It will look like an animation, but it isn't, it's just the next slide.

> Those are not benefits. Do not do those things. Anything more complicated than embedding a video is a distraction and will not help your presentation.

> Seriously, trust me on this one.

No, that's your opinion. The best presentations I've seen use animations. Just not on every slide, and not huge distracting animations. Animations can be amazing to emphasize what you're explaining.

DO use animations, just make sure they bring something on the table.

We may be talking about different things.

If your talk is about, say, heat engines, and you want to have an animated Carnot cycle or something, great! Do that! That sounds useful! (These days it would probably be implemented as a video, which is why my brain binned it as such, but it really could be done with PowerPoint alone.)

If you want to have your slide chug in from the right "like a locomotive" then have each item on the screen individually fade in "like puffs of steam" then once you're done the whole thing drifts to the top "like smoke" because "steam engines are heat engines", that is the crap I am telling people to get rid of.

> 8. avoid typing in code as part of the presentation, most of the time it won't work and it's boring watching somebody type

As usual, thumb rules exist to protect you until you can confidently break them. One of the coolest presentations I've seen was several years ago at a React conference where the speaker live coded an electronic music and light show using React. They were demonstrating how "components" could really render anything.

Another one I've seen was someone live coding (well, doing some small code changes to an existing codebase, compiling, uploading) a program that controls a drone and made it perform a couple of tricks on stage.

Live demos do work, it's all about pace, preparation, and fallback plans.

> As usual, thumb rules exist to protect you until you can confidently break them.

1. novice follows the rules because he's told to

2. master follows the rules because he understands them

3. guru transcends the rules because he knows their limitations

What is the best way to show code?

I really want to show some code. Like 4-5 lines to give a gist.

Just do it. There's nothing wrong with it, if that's the kind of talk you want to give.

Look at stuff by david beazley, matt godbolt or casey muratori. They all have talks which focus on small pieces of code and i'm sure it's a tremendous effort to frame that well enough and pace it appropriately, but it sure works for them (and me watching their talks).

I ruthlessly make the code examples as simple as possible. Eliminate everything but the point you're trying to make. I'll adjust the font to fill the slide.

And it doesn't have to even be code that compiles, unless it's about the language design and it really really matters for that presentation. You can yadda yadda whatever you want. Syntax doesn't exist anymore, just use greyed out "..." for the uninteresting parts.

The advice is:

> 1. do not show a slide full of code.

Not "do not show code". Focused snippets are fine, you just need to distill the code to make sure it's just the essence of what you want to show and that it's easy to read (naming is important).

4-5 lines can be really effective. After all, if you're at a software conference, you're probably speaking to a bunch of programmers about programming, and code is your universal language.

But already 7-10 lines is stretching it, and any more than that, and it's a lot harder to get your point across because people spend so much time trying to parse the code sample.

The problem is that cutting down the code and coming up with an example that explains everything you want in just 4-5 lines is really hard — "if I had more time, I'd have written a shorter letter" and all that.

When I need more than a couple lines of code, I'll highlight in red the parts the audience should focus on.

I agree with these, but David Beazley breaks most of them and his talks are way better than mine ;)

e.g. https://m.youtube.com/watch?v=r-A78RgMhZU

Above all else, make it interesting and entertaining!

Which should go without saying…

In this line;

Tell a story. It might be "unrelated" to thd topic at hand (I based one on Shackleton's expedition, and another on a Robert Frost poem (two roads diverged.) Or it might be related, a "my journey" type, or it might be about the experience seen through the eyes of a customer. But a story helps the audience relate, and keeps a thread through it all.

If you can, be funny. Frankly this is hard if you're not a 'funny' person. Delivering a good joke, or line, well can be learned but if it's not your thing steer clear. Bad funny is worse than not funny.

If you're not funny naturally then get a funny person to help you script in "dry" humor lines. You can deliver them dry, in fact often the dryer the better.

"We founded our business in Jan 2020. Nothing could possibly go wrong".

But good funny is great. Learning while laughing really keeps the audience engaged.

Reacting to the audience engagement is also a skill worth developing. When they're bored, move on. When they hiss or boo or laugh or leave, these are all valuable feedback.

Enjoy yourself. If you're having fun, they will too.

Oh, one more thing. Keep on hand some of your previous presentations. Often, a speaker won't show up and the conference organizer is panicking and needs a replacement. Be first to volunteer your services! I've done that several times, and the results were always worthwhile.

One time, I didn't have an extra talk with me, but I volunteered anyway and asked for a whiteboard and markers. Frankly, it was the best talk I ever gave. Unfortunately, it wasn't recorded. But it sure was fun! (I simply asked the audience what they wanted me to talk about.)

I once got a panicked email from a conference organizer in Japan at about 3AM because a speaker was at another event and completely forgotten about this one. (Hey! Happens.) I was able to be like, no problem. Here's a presentation that works.

And, if need be, I could have just done something on the fly instead.

8. depends on the nature of the presentation. if it is a coding workshop then live coding is actually quite a good idea.

A workshop is a different sort of animal.

1. All tech discussion is irrelevant unless it’s leetcode. Don’t fill my brain with any other useless, unproductive information.

2. How much time (points) will this presentation take to get to prod. Then how many points (time) will it take to deploy to prod. Do we need a spike for this presentation. I’m going to put it in the backlog and close it out since we’ll never get to it.