Ask HN: What are the things keep in mind while giving/preparing for a tech talk? - scarecrowx
======
akdas
Know you're talking about. That alone will make the talk more natural, as
you'll be able to adapt to your audience due to having knowledge outside of
just your research.

This was the biggest change between the presentations I had to give in high
school and the ones in college and above. In high school, the topic was
usually given to us, whereas in college and later, I got to choose the topic I
was most knowledgeable about. The latter meant I was more passionate, more
able to answer audience questions and more able to tailor the delivery to the
audience.

One piece of advice I heard was that if you absolutely have to talk about a
topic you're not familiar with, talk about being a beginner in that topic.
Talk about your perspective as an outsider learning that topic in the first
place.

~~~
kjeetgill
To expand on that with "obvious" advice: Know your audience. Present
accordingly.

Are you an expert or a beginner _relative to your audience_? If I'm explaining
something technical, I might take a more assertive tone when glossing over
details with a novice but speak with more deference to an expert. (e.g. Throw
in a few "I think ..." or "My understanding was that ...")

Getting a quick grasp of where the speaker is coming from helps the listener
really engage at the right level. Should I double check what the speaker is
saying or are they the authority on the matter? Nothing get's eyes rolling
faster than someone making blatantly wrong factual errors overconfidently.

~~~
ryrobes
This x10. Being aware of "who" / "what" is in the room - and then (the tricky
part) self-aware of how they may see you.

Use this ance-data to shape your tone and phrasing.

------
framebit
A little bit of stage fright is generally healthy. It shows that you care
enough to be concerned and you're not getting too cocky. That's an old lesson
I learned doing (of all things) middle school acting class and it's proven
itself to be true over and over again.

Think about your slide and presentation style. For example, I have enormous
decks for most of my talks (think like 55 slides for 30 minutes) but I burn
through them very quickly, usually less than 20 seconds per slide. I came from
film editing before moving to software so I approach my Powerpoints like a
movie, it's just my nature. Others have really short decks that are
information dense so the emphasis is on the talking part of the talk and the
slides just provide a reference in the background. Others forego slides in
favor of straight-up demos, which is certainly slick if you can pull it off
(high risk, high reward) and need little pictorial illustration.

Use the old 5 paragraph essay rules from high school as a starting point for
structuring your talk: tell you're audience what you're about to tell them
(thesis, topic, core argument) and how you're going to tell them (outline),
then tell them (supporting paragraphs), then tell them at the end again what
you told them and how you told them (conclusion, restating your intro).

Humor helps, generally. This isn't supposed to be a standup set so definitely
don't go overboard, but it can really help. Particularly if you can tie it in
with some empathy for your audience. ("We're gonna do this in Perl. I love
writing Perl, you just hold shift and smash the number row for awhile.")

And for heaven's sake don't read your slides.

~~~
daphneokeefe
When the slides contain a lot of text, it is not possible for me to
simultaneously read and comprehend the slide and understand what the speaker
is saying. The slide appears, I start reading. You start talking, so I have to
decide where my attention goes. Often it is neither the slides nor the
speaker, just a jumble of words coming at me. Then the next slide comes up...

~~~
miketuritzin
I feel like the solution to this is to have slides without a lot of text on
them, but then include what you say in the "speaker notes" section when you
distribute them so that people who didn't attend the talk understand them.

------
gnur
Always do at least 1 full rehearsal with a timer, preferably two full
rehearsals where the first one you do keep a timer but also have a notebook
(physical) present to quickly write down adjustments you want to make.

Do a live demo, people love live demo's, but be prepared for when disaster
strikes (it will), if possible run your live demo on a physical device with
you during the presentation.

Most places allow you to have 2 devices connected, or quickly switch the HDMI
cable to the demo machine.

Do not use a linux machine, I know this sounds harsh, but with all the types
of beamers/screens out there, a windows or mac machine will just have a much
higher success rate. (I learnt this the hard way, in the end I could choose
between mirrored 640*480 or full hd on the beamer only, which makes live demos
much harder).

Create short slides, the slides are there to guide you and the audience. Try
to prevent reading the slides out loud.

Use images and videos, they can tell more then a thousand words.

I often use the STAR approach to tell my story, this helps structure your
talk. You don't need to follow star exactly, but if trying to explain
something, it often helps to first give a bit of background why you did what
you did.

Make sure you let the audience know if and when you will be answering
questions, some talks really benefit from interactivity, but if you are short
on time, let people know they can ask their questions later (perhaps add a
slide at the end with sources and your contact information).

Also, relax, the audience has already decided they want to listen to your
presentation.

~~~
avian
> Do a live demo, people love live demo's

It really depends on the topic of the talk. If it's something that can be
demonstrated in a quick and straightforward way, do a demo by all means. But
I've seen talks where people were forcing a demo into a talk about complicated
concepts. There's little value in seeing someone type in a page of code,
compile and run. Or seeing something run without understanding what is
happening on screen. I would much rather have the speaker spend those minutes
discussing the topic.

> Do not use a linux machine

Better advice: make sure you know how to setup an external screen on your
laptop and how your presentation software works with it. Try it before hand
with an old VGA monitor.

> Create short slides, the slides are there to guide you and the audience. Try
> to prevent reading the slides out loud.

I would argue that the slides are there for the audience. Ideally, you need to
be able to present your talk without seeing your slides. They are not cue
cards for the speaker.

Very short slides light on content (e.g. memes, one word or sentence per
slide) make for a terrible tech talk in my opinion. Do make your slides
informative. They should complement what you are talking about. Show a
relevant graph, code snippet, etc. related to what you are talking about. If
you can't do that, fall back to a summary of your spoken content in a 3-4
bullet points per slide.

~~~
sideshowb
Edit: added headings!

STYLE

> [slides] are not cue cards for the speaker

Personally I disagree with this point and have developed a presentation style
I'm happy with based on the slides being my cue cards (average 5-10
presentations / year for the last 15 years).

I do NOT read the talk from my slides and can't stand it when speakers do
that! But, each slide should jog my memory of everything I need to say at that
point. Maybe I'm talking about some stats as background, fine, the slide
should be a bar chart of those stats, or a map, or an illustrative photo.
Rarely a list of bullet points, though I don't prohibit them altogether and
will tend to conclude with a list of bullets to leave in the background as a
summary while I take questions. Overall the slides should complement the talk,
not be a duplicate. But they serve a second function of reminding me of all
the things I need to say.

As a programmer you will appreciate the reason for this: I have cut the number
of entities I have to process in my head from three (slides, audience, notes)
to two (slides, audience). Keeping track of and having rapport with the
audience is essential to me, even if that just means looking at people to see
how engaged they are. With notes/memory in the equation I used to get a lot
more nervous and not pay enough attention to the audience. Cutting out the
notes allows me to focus on communicating better. It's a shared context, the
audience can see exactly[1] what I can see.

If you're in sales then I see another tactic used instead, which is to
memorize the talk so thoroughly that you don't need notes or presenter view.
Fair enough. I'm an academic researcher; while they say all our presentations
are a sales pitch on some level or other they clearly aren't expected to be as
slick as "sales" sales. My constraints are having limited time to prepare, and
wanting to stay natural. I do rehearse but I don't over-rehearse as I find
that kills my own interest in the talk as well as taking more time. Usually
the minimum for me is two full run throughs, probably stopping the clock
multiple times during each to apply edits as I see fit (hopefully only a few
edits second time).

HANDLING CONTEXT SWITCHES

The one exception to [1] is context switches. As others have said, finding the
perfect words for the _introduction_ to each new topic really helps get the
flow going. These can be remembered, written on notes, written on slides,
written on slide notes visible in presenter view, whatever.

I'm a big fan of presenter view, not for notes, but purely for the ability to
see the next slide and introduce it slightly before the change. It helps to
_leave_ each slide knowing what direction you're going in so you're not
surprised by the next one. I do worry slightly that I'm dependent on presenter
view and turn up early at each venue to make sure I can get it working (not
all of them can).

NERVES

Someone said don't drink too much alcohol. Based on my experience as a
performing musician this is true :) Same goes for caffeine for the opposite
reason, it really heightens the nerves. On the subject of nerves, just accept
that some talks seem to go better than others. If you find yourself having a
failure of confidence, take a deep breath and keep going. Easier said than
done I know, but it always feels worse on the inside than it really looks; I
have had people come up to me after talks where I thought I did awfully and
tell me how engaging they found it.

AUDIENCE ENGAGEMENT

If you can find a way to further engage the audience without forcing it - quiz
questions, polls etc - go for it. Quiz questions can help set context for a
new topic. Despite my love of the material I've never really been a lover of
talks and can get pretty bored in the audience, so I really appreciate this
sort of thing.

Example: on a few of my talks lately I've showed a picture of some protestors
up trees by a road, asking who can name the incident. (Protests vs Newbury
bypass construction). Followed by more protestors and an airstrip (former US
nuclear base Greenham Common). Most of my UK audiences will get these right.
Finally I asked what links these two things. They may or may not get the
latter: the success of commercial development on Greenham Common, when it
ceased to operate as an airbase, was blamed for the failure of transport
models to correctly predict the effect of Newbury bypass. Doesn't matter
whether anyone guessed the final answer, which is obviously a bit specialist.
The point is I've now got people thinking about the many interconnected
elements of simulating transport which is a great intro to the topic.

~~~
avian
> If you're in sales then I see another tactic used instead, which is to
> memorize the talk

Majority of my talks in the last years have been in academic settings, but I'm
definitely on the side of "over-rehearsing" on your scale. I've never done a
sales talk in my life.

I guess it depends on how well you can improvise on stage. I never managed to
master that. For myself, I can only "stay natural" and not be nervous when I'm
well prepared.

> quiz questions, polls

I personally don't like this when listening and rarely do it as a speaker. It
can be a double-edged sword. I've often seen speakers fall into the trap of
asking "how many of you are familiar with X", and then proceed to spend next
10 minutes explaining X even though it's obvious that the audience already
knows X very well. If you're asking questions, you should be prepared to act
on the answers.

~~~
sideshowb
Fair enough, there is diversity of preferences in both speakers and listeners
:)

I agree on familiarity polls that you should adapt content based on audience
familiarity with the topic.

Whether or not audience engagement is appropriate also depends a bit on the
length of the talk. It can be great for a context switch in a 45 minute talk,
like a mental reset button for the audience. If you only have 5 minutes it
will detract from things unless you want it to be the main focus.

------
joshfraser
People decide in the first 10 seconds whether they're going to listen to you
or use your session to catch up on email. So make your intro good. Catch their
attention. Surprise and intrigue them. Memorize and practise your intro over
and over again so when you walk on stage you can get comfortable without
having to worry about the specific words you're saying. Memorize your
conclusion too so you can bring it home with a strong call to action (bonus
points if you tie it back to your intro!). People remember the first and last
things you say the most, so make those words count.

~~~
mrweasel
Somewhat off topic: I always wondered why people would bother showing up for a
talk or conference if they're going to be on their phone or laptop during the
entire thing.

Last time I went to a conference I was actually a little surprised by the
number of people at the talks who where clearly working during the entire
thing. Why bother, you most likely pay for the plane ticket, the hotel and the
conference it self, and then not pay attention? If you're only interested in
one talk, then just go to that one and then leave.

Given that people mostly show up to technical talks of their own free will, I
don't think you need to trick them into paying attention. It's fair to assume
that they are generally interested and focused on what you have to say.

~~~
Kagerjay
Some people get paid to go to the conference and also for some its in their
best interest to half pay attention while doing work.

On another level, sometimes I go to meetups in my area which are technically
the same conference presentation as well. There are times when I regret going
to the meetup (There's 10-20 people) because of how boring the speaker is or
how overly technical it becomes, but I don't want to be rude and leave the
area cause it'd reflect poorly. Its not like a convention where leaving is
okay, everyone in the area knows each other.

------
TeMPOraL
Lots of good advice here. I'd add:

\- Ask yourself what is your _real_ goal of the talk. Are you trying to teach
people something? Or are you making a live-action advertisement for a
product/service (or for yourself)? Optimize your talk ruthlessly for that
goal.

\- If you're doing a talk in front of a small audience (say, 30 or less
people), and you're going to discuss details of code or charts presented on
slides, then put all those code snippets and charts you want to discuss in a
single document and give everyone a printout. A printed document has much
higher resolution and quality than a slide (especially for the people sitting
in the back), and will allow them to look back (or forward) at an important
figure if you're currently showing another slide. Paper is cheap and quite
ecological, so don't worry about that.

------
ced
From Richard Hamming:

 _When I first started, I got practically physically ill while giving a
speech, and I was very, very nervous. I realized I either had to learn to give
speeches smoothly or I would essentially partially cripple my whole career.
The first time IBM asked me to give a speech in New York one evening, I
decided I was going to give a really good speech, a speech that was wanted,
not a technical one but a broad one, and at the end if they liked it, I 'd
quietly say, ``Any time you want one I'll come in and give you one.'' As a
result, I got a great deal of practice giving speeches to a limited audience
and I got over being afraid. Furthermore, I could also then study what methods
were effective and what were ineffective.

While going to meetings I had already been studying why some papers are
remembered and most are not. The technical person wants to give a highly
limited technical talk. Most of the time the audience wants a broad general
talk and wants much more survey and background than the speaker is willing to
give. As a result, many talks are ineffective. The speaker names a topic and
suddenly plunges into the details he's solved. Few people in the audience may
follow. You should paint a general picture to say why it's important, and then
slowly give a sketch of what was done. Then a larger number of people will
say, ``Yes, Joe has done that,'' or ``Mary has done that; I really see where
it is; yes, Mary really gave a good talk; I understand what Mary has done.''
The tendency is to give a highly restricted, safe talk; this is usually
ineffective. Furthermore, many talks are filled with far too much information.
So I say this idea of selling is obvious. _

[http://www.cs.virginia.edu/~robins/YouAndYourResearch.html](http://www.cs.virginia.edu/~robins/YouAndYourResearch.html)

------
boyter
You don't have to help people get from A-Z. Quite often they don't even know
where to start so going from A-D is enough. Know your audience in advance
though.

Remember to pause and speak slower. It gives the impression you are really
considering what you are about to say next and allows you a break.

Don't drink alcohol before the talk (unless you need a shot to calm your
nerves) and do have a bottle of water available as your mouth will most likely
become dry.

Lastly relax. The audience is unlikely to call you out unless you make a total
hash of it and they usually want you to succeed.

~~~
jschulenklopper
> Lastly relax. The audience [...] usually want you to succeed.

Great insight, and I've found that to be true. Most of the time, they selected
your talk based on their interest in the contents (and less so on your
delivery), and so they want to learn a thing or two. They will be graceful
towards your presentation (style, delivery, slides) if at the end they got
what they came for: you sharing data, knowledge, insights or wisdom. You don't
want that too difficult for them, so you should work hard on improving your
presentation delivery, but sharing knowledge is appreciated over sharing jokes
or just well-designed slides.

------
mhandley
Remember you're telling a story. Think hard, before you start with slides,
what that story actually is. Continuity and flow really matter.

Usually the first part of the story of a tech talk explains what the problem
is. Many tech talks fail because the audience either doesn't understand the
problem, or doesn't believe your problem needs solving. Think carefully who
your audience are, and ensure you explain the problem in enough detail that
you connect with your audience.

The middle part of a tech talk then is usually spent on explaining your
solution to the problem. If you've explained the problem well, that the
outline of the solution will basically work should be reasonably self-evident.
Many tech talks fail here, because they dive too deep into the details too
fast. Again, know your audience, so you know how deep to dive. You can never
fit all the details you have in your head into a talk, so think carefully
about what the most important features of your solution are, and focus on
those. Keep less important details for backup slides you can turn to if asked.

The third part is usually evidence that your solution works. Often this
involves graphs. Again, focus on only the most important results - more than
about three graphs and your audience will switch off. Explain the experiment,
and explain what the axes represent. Way too many people don't spend enough
time on this, so no matter how good the data, no-one understood.

Finally, your conclusions. What did you learn? How complete is it? What are
its limitations? You're not entirely doing a sales job, and your audience are
wise enough to know that your system will have limitations. You should be the
one to explain them, rather than have them come out in questions (when they'll
start to doubt eveything else you told them). Finally, what future directions
do you think should be taken?

Of course, different talks have different shapes. Find what works for you.
Sometimes you need to iterate between problem - solution - new problem -
revised solution, etc.

When you present, know your first few sentences by heart, because you'll be
nervous. After that, it matters less, you'll have settled into the talk, and
you'll appear less stilted if you're not reciting a script. Most importantly,
turn your excitement dial to 11. If the audience feel you're not excited by
the work, why would they be?

------
khazhou
If you're projecting from your own laptop, shut down any apps that might give
bouncing notifications. Really, just shut down all apps. And don't have your
browser open with bookmarks tab and window tabs showing.

Don't spent 10 minutes on the introduction. A _very_ common mistake is people
step too slowly through the setup material. Just lay out the problem and GO.
In fact, even throughout the talk, assume the audience is smart and can fill
in the obvious blanks.

~~~
protomyth
I took to the habit of logging in with a "Presentation" user, so no weird
things would pop up.

------
zwischenzug
Best advice I had about giving talks (from a non-techie) was 'tell a story'.
People like stories more than information. If they want information they can
mine you for it afterwards.

~~~
groby_b
Don't just tell a story. Use the tools of story telling. Have a three act
structure (Setup, confrontation, resolution). Have a plot. Use foreshadowing.
Use one of the common generic stories as a framework (Hero's journey, coming
of age, etc). Make it personal - bring in either parts of the audiences life,
or of yours. And close with a positive message

You know when you were a kid, and you had that one funny relative who'd always
tell great stories? Be that relative.

~~~
avian
Is it strictly a tech talk? As someone else said here, skip the cruft and get
to the point. I came to your talk to learn about the technology, not your life
story.

Some people are good at wrapping tech talks into interesting stories. But they
are very rare in my experience. If you don't have a story to tell, don't force
it. Don't try to present everything as this grand idea that's related to
everything you've done since childhood. It gets old really fast.

I've seen students take a course in speaking where they hammer into them this
"three act structure". Invariably, the talks they give would be much better if
they would just stick to the technology.

------
dmlorenzetti
Try framing your material in the assertion-evidence [0] style. Not only does
this lead to more informative presentations, I find it helps me organize my
story better.

Briefly, rather than using topic titles ("Experimental Setup", "Results"), use
assertions ("Sampling occurred over 5 days", "Sunlight causes significant
degradation") as titles. Then the bulk of the slide is some information,
preferably graphical, that supports the assertion. Reading the titles in order
should give you a strong sense of the presentation content.

I strongly recommend "The Craft of Scientific Presentations" by Michael Alley,
which covers the assertion-evidence approach, and a host of other practical
topics.

[0] [https://www.assertion-evidence.com](https://www.assertion-evidence.com)

~~~
mhandley
I'm also a fan of the assertion-evidence style, though I've found over the
years that it works better for some talks than others. Animating in an
explanation over a series of slides, for example, sometimes doesn't fit that
style very well.

Even if you don't go all the way to using the assertion-evidence style, titles
are a great place to summarize the main point of the slide. So rather than
"Results (3)", use the space for something more descriptive like "Velocity vs
time during reentry".

------
TamDenholm
If you're being recorded for it to go on youtube, and you're doing a Q&A at
the end, please repeat any questions that are asked for the benefit of the mic
and those watching on youtube. Thanks

~~~
sleepychu
Just do this anyway, often the audience can't hear it.

------
antirez
Say at least something useful and new that most people in the audience do not
know already. If this is not the case, better to rethink the talk from
scratch. Audience should go aways thinking "I learned a few new things".

~~~
fergie
Whilst I personally agree that talks are better when you learn something new,
there seem to be whole conferences dedicated to intentionally restating the
same things over and over again. Its almost as if some people go to these
events to have their ideas _confirmed_. Project management conferences I am
looking at you!

~~~
antirez
I agree but I'm not sure this is intentional... I've the feeling that
commercial conferences are just simpler to run that way: professional talk-
giving persons always saying the same things over and over, with little
efforts and without being part of any actual "research" in the field.

------
madethemcry
There are quite some people who are writing full scripts. That's also what I
prefer. It goes like this:

Before creating a single slide, write down sentence by sentence, word by word,
what story you want to tell. You can use tools to get a very rough metric of
how long your written text will translate being spoken. Stop when you reach
your talk length.

Once you are done, you can start creating slides. Choose what you like the
best and what fits your story. Few slides, many slides (e.g. Pecha Kucha), no
slides.

I would never do live coding but show small videos instead. I have seen live
coding fail more often than being a great success. But if you want to do so,
have a fallback video at hands.

Now your rehearsal: Not 1 full, not 2 full rehearsals, do as much as you can!
For my last and very first talk for a conference I did like 20 full
rehearsals, 5 of them in front of people, some in the living room, some in
front of the mirror. I bet this can be less in the future but it got me super
confident. Rehearsal matters! Don't be lazy and you will be amazed how
confident you can go into your talk.

When you black out during your talk, don't panic because you have a full
script which you could theoretically read word for word. That always calms me
down.

Good luck and have fun.

~~~
Joeri
+1 for live coding being really hard. I’ve done many talks and by far the
hardest was a live coding talk I did recently.

It has all the same difficulties as a regular talk, but with some added
handicaps:

\- no ability to make eye contact with your audience and feel the room

\- no way to talk over small errors, if you get stuck on a bug it can take you
10 minutes to find your way back out

\- very difficult to keep the audience’s attention since all they see is a
wall of text

\- talking and typing at the same time is really hard, you get to enjoy
stammering your way through fumble fingers

In short: only try a live coding talk after you have a lot of presentation
experience.

------
JD557
Make sure that your talk fits the timeslot.

I find it helpful to go train the whole talk with a metronome (at a slowish
tempo) to have an upper bound on how much time the talk will take.

~~~
pmiller2
Just as a guideline, I’ve found that about 1 slide per minute (with not a ton
of text per slide) is pretty good. This has worked for me for topics ranging
from graduate level math to programming topics.

~~~
Cthulhu_
But as an addendum, your talk should not depend on the slides - the slides
should illustrate or add information, trigger people's visual memory for what
you said during that slide.

If you write slides with bulletpoints and read them, then er, just, don't.

------
suls
I came across [https://speaking.io](https://speaking.io) _after_ I presented
for the first time at a larger conference [1]. In hindsight it's so obvious --
Zach Holman really talks about the things that matter. So if you still have
time, please do your future-self a favour and have a look at it.

Another point I found out _after_ I presented is to better avoid any
caffeinated drinks -- apparently it makes your mouth dryer. Adding a bit of
nervousness makes matters worse and you end up having to drink a sip of water
every few minutes.

[1] [https://youtu.be/wNrTDEaDVwU](https://youtu.be/wNrTDEaDVwU)

~~~
jschulenklopper
Came here to say the same - [https://speaking.io/](https://speaking.io/) is
very valuable in preparing, creating and delivering a (tech) conference
presentation. Recommended resource!

------
jedberg
Tell a good story. Humans love stories. Even the most deeply technical talk
should have a narrative with a beginning, middle, and end.

Start with a bang. Have a controversial opinion? Lead with it. The slide with
your name probably shouldn't be the first one, unless the conference makes you
start that way. This goes back to point one -- telling a good story. You know
how most movies start with something really exciting in the first few minutes?
This is called the "inciting event" and is what drives the narrative. Your
talk should have that too.

------
joelhooks
The audience wants you to succeed and are generally very forgiving.

~~~
divan
This! It's one of the most important thing to remember – people paid money and
came to listen here, and you've been invited as a speaker, so that means that
you have something important to tell, and people really want you to succeed.

I also recommend a fantastic book on the topic by head of TED conferences,
Chris Anderson - "The Official TED Guide to Public Speaking". It helped me
immensely when I was preparing to my first big public speaking event.

~~~
jschulenklopper
Agreed! As I wrote to a comment elsewhere on this page: "Most of the time,
they selected your talk based on their interest in the contents (and less so
on your delivery), and so they want to learn a thing or two. They will be
graceful towards your presentation (style, delivery, slides) if at the end
they got what they came for: you sharing data, knowledge, insights or wisdom.
You don't want [to make] that too difficult for them, so you should work hard
on improving your presentation delivery, but sharing knowledge is appreciated
over sharing jokes or just well-designed slides."

------
krzrak
When rehearsing record yourself (i.e. with your phone mounted on the tripod or
just against something). I realized, that before that I didn't do full
rehearsal, just was repeating the talk in my mind or even if speaking aloud -
I was sitting instead of standing, had lots of interruptions, etc. Then watch
the recording. It's painful, but worth it. Observe your body language. Try to
face the audience, not sit or stand with your back towards them to read the
slides. Move a little bit, don't just stand there.

~~~
maaaats
This. When rehearsing in your head, it's easy to gloss over parts that really
need some working. When treating it as a proper presentation, those spots are
painfully obvious. Better to find them alone, even if watching yourself is a
bit awkward.

I also like to record myself because sometimes I find a good way to explain
something, which I want to remember and explain the same way during my talk.
It also helps with pacing. Am I too slow or too fast?

------
Scarblac
Plan to give the same talk several times. You can give it to your team, then
to some local dev meeting, then on a larger conference. You can improve it
over time.

Talk clearly, look at your audience, if it's hard to hear what you're saying
at all then there is no point.

Make it clear what the problem you're solving is, why solving it would be
nice, why obvious solutions aren't good enough, then work towards a big payoff
at the end. Show that your tech solves the problem, and does it very neatly!

When explaining stuff, use _examples_.

------
jppope
1) Do not attempt to live code. change your code via version control, build
small videos, copy and paste... whatever you do... do not try and live code

2) Read "The presentation secrets of Steve Jobs" ... its not really about
Steve Jobs so much as its about how to be a great presenter.

3) building or writing a talk is significantly less important than the
delivery... which means that more of your time should be spent on how to
deliver the speech (recording I find is the best way to practice)

4) Pick a single thing and do it well, do not attempt to put too much into a
talk or tackle something massively complex.

5) Make sure that everyone is walking away with something they can actually
use. This doesn't require it be a hard skill... "Soft" or philosophical
utilities are just as good

6) Have Fun and be funny... Speakers have a tendency to want to show off the
size of their intellect, and the level their competency- having a speech be
entertaining is way way more important.

7) DO NOT READ FROM YOUR SLIDES. know your shit. slides are supplementary

Extra Credit. Here's a collection of some fantastic technical speeches:

* [https://vimeo.com/9270320](https://vimeo.com/9270320) * [https://www.destroyallsoftware.com/talks/wat](https://www.destroyallsoftware.com/talks/wat) * [https://youtu.be/o_TH-Y78tt4](https://youtu.be/o_TH-Y78tt4) * [https://www.youtube.com/watch?v=csyL9EC0S0c](https://www.youtube.com/watch?v=csyL9EC0S0c) * [https://youtu.be/a-BOSpxYJ9M](https://youtu.be/a-BOSpxYJ9M) * [https://youtu.be/kb-m2fasdDY](https://youtu.be/kb-m2fasdDY)

------
eksemplar
As I moved into management I started to give more and more
talks/presentations. A few very tech talks at summits and conventions with our
peers, most were briefings directed at upper management, and while the content
are different they function the same really.

I start by figuring out what I want my audience to take a way from the talk.
Then I break it up in keywords and then I build my presentation.

Once that is done I practice once or twice, by my self, talking to the
computer while I rearrange, add or delete from the presentation to make it
what I want it to be.

Once this is done I practice, going through the entire presentation until I’m
able to give it on the fly if I was woken up at 4am. I don’t practice it word
for word though, but when you’ve talked about a subject enough times, you can
do it again.

The practice but is really, really important. Especially if you’re not used to
giving speeches. At first I thought that if I just practiced in my head, I’d
be fine, because I knew what I wanted to say. Hah, not so. The first time I
gave a presentation I was a stuttering incoherent mess, because I hadn’t
practiced by saying the words out loud. I knew exactly what I wanted to say, I
just couldn’t.

Now, many years later, I don’t have to practice as much because I’ve gotten
better verbally. So yo can definitely be the type of person who doesn’t need
to practice out loud. But I had to do more than a thousand presentations to
get to a point where I could comfortably skip practicing on short
presentations and only doing it once or twice on long ones.

As for questions afterwards, take your time to think about your answer, and if
you don’t know the answer, then be honest and always, always be polite and
affirmative. If you make people feel like they asked a good question, even
when you think it wasn’t, then they and everyone around them will like you
better. This too gets better with practice, but it’s obviously not something
you can practice on your own.

Humor is typically a good thing, it relies a lot in timing and it sometimes
falls flat. Just never do it at someone’s expense.

------
tchaffee
If your slide has writting on it, people will read your slide instead of
listening to you. Keep the writing to a bare minimum and fill in the missing
parts. Even better, use a picture that helps tell your story for that slide.

For each slide, think about what the audience take-away is. They should learn
something from what you say for each slide.

Mingle and introduce yourself to a few people before your talk but don't tell
them you are a speaker. Before you get on stage see if you can find them in
the audience and pretend you are talking to them and not a huge audience. If
you can't find some known faces, pick one from the first few rows. Helps with
the nerves.

Until you get good at speaking, you need a lot of rehearsal for each talk.
Present once in front of a willing friend and then after making corrections,
get a few volunteers at work to be an audience. As many rehearsals as
possible.

Slow down. Pause. People need a little time to digest each idea. Your material
is new to them.

Like everything in life, the only way to become good is to make mistakes. With
speaking you do that in front of a lot of people. It helps if you can laugh at
yourself and be forgiving. The audience will often treat you the way you treat
yourself.

~~~
rmattes
The 'assertion-evidence' approach to creating slides focuses on for keeping
text to a minimum and using pictures and other visual aids to support your
message. They emphasized it in my engineering school, and I've been using it
in workplace presentations for years.

[https://www.assertion-evidence.com/](https://www.assertion-evidence.com/)

------
mindcrime
My biggest suggestion is this:

1\. Don't read the slides to your audience. Generally speaking, the audience
can read.

So what are slides for then? Well, if it's a text only slide, I treat them as
being there to be _reminders of what I 'm supposed to talk about now_. And
that's it. The content is what I say, not what's on the slide. So there
doesn't actually need to be much on the slide at all. Just a couple of bullets
to reflect the high points of the conversation. Now graphics are a different
story.

There are exceptions, of course. I've been known to do a slide with a massive
list of "things" in 10 point font, with like 30 items on it... but when I do
that, it's to _make a point_ \- a point like "there are a fuck-ton of options
for X" or whatever.

The other thing I try to do, is put links and pointers to other resources
somewhere in the deck, so that sharing it with the audience actually provides
some value. If you adopt the "very information sparse" slide format, then the
slides don't really provide much value to the audience after the fact. Whether
that's an issue or not is kinda up to you.

------
koolba
Finish your slides _at least_ a few weeks before the talk and dedicate a time
slot equivalent to the talk (ex: 1-hour => 1-hour, 30-min => 30-min) per week
doing a dry run. This is particularly important to get the timing correct. If
you're repeatedly short or long then adjust accordingly.

Version control your slides. This is particularly useful if you end up giving
the same talk more than once as you can tweak things and improve it.

It's a tech talk, not a stand-up comedy routine. Light jokes and colorful
anecdotes help with connecting to the content but the substance should stand
on it's own.

Depending on your alcohol tolerance 1-2 drinks can be remarkably effective at
smoothing out your delivery.

I find a small intro on the format of the presentation to be helpful at
setting expectations. The talk descriptions are often very short and it's hard
to gauge what's actually going to be covered with a lot of " _Deep dive into
XYZ_ " barely getting your ankles wet with real code. It's appreciated (as an
audience member) to know in advance what you'll be getting.

~~~
chengiz
I could not disagree more with your first line. For one it's utter fantasy.
For tech talks where you need to present results, sometimes results dont
arrive until the morning of. Secondly, there should be a measure of proaction
- gauge the audience and adjust the talk accordingly. In fact, I'd go the
complete opposite, keep adjusting your slides until you're comfortable. But
yes, do time yourself. Generally IMO a minute per slide is a good ballpark.
This means your slide is not too empty or too full, and you can talk about the
material in the slide without reading the slide out.

~~~
koolba
> I could not disagree more with your first line. For one it's utter fantasy.

The lead up from call for papers to actual conferences is usually 4-6+ months.
Assuming you submit a talk without any content prepared yet and spend the
first two months procrastinating, that leads 2-3 months for put together your
outline and slides.

> For tech talks where you need to present results, sometimes results dont
> arrive until the morning of.

That's a specific case and hardly the norm. Plus you likely know the direction
of the results without know the final 7 decimal points. The latter you fill in
as it comes.

> Secondly, there should be a measure of proaction - gauge the audience and
> adjust the talk accordingly. In fact, I'd go the complete opposite, keep
> adjusting your slides until you're comfortable. But yes, do time yourself.

Definitely play the audience but if you haven't practiced your content you
have to spend more time coming up with phrasing rather than shifting over, or
dedicating more time to, a section.

> Generally IMO a minute per slide is a good ballpark. This means your slide
> is not too empty or too full, and you can talk about the material in the
> slide without reading the slide out.

I vary widely from 20 seconds per slide for a quick succession of minor points
to 3-4 minutes when there's a code sample to talk through.

This is also why practice is so important as you get a feeling for where you
can spend more time if you have it and where you can cut out if you don't.

------
3stadt
In my experience, one of the most important things is to keep your audience in
mind. I recently gave a talk about how docker works internally. I knew that a
good chunk of the audience was aware of the difference between docker and a
VM, so in the beginning, I explained these differences via a more or less fun
story. People who already knew the content were not annoyed, the rest got the
information they needed.

Another thing is, tech talks tend to be as dry as the Sahara desert. So try to
make your talk interesting. Do not just focus on getting the information
across, but make it fun to listen.

Practice your talk without slides. This has two benefits: You concentrate on
the content, so your stuff by heart at the end. And you don't depend on the
slides, in case something goes wrong.

Lastly, prepare for 4:3 - even if they say you get a 16:9 beamer, chances are
it's not. And prepare for offline, your Laptop being broken and in case you
are doing a live demo: Have a video of it as a backup.

These tips are all just from my experience and may not apply to you, but maybe
it's helpful. :)

~~~
Cyphase
What was the fun story?

------
erichurkman
Do not assume everyone knows acronyms or initialisms that you use,
particularly if the audience is unknown. Saying "test driven development" is
more accessible to a wider audience than "TDD".

~~~
afarrell
Also, if someone is hearing impaired, they might not know what TDT is.

------
nicostouch
If there is a Q&A section and it's being recorded... please please please
repeat the question so your mic pics it up because the person asking it is
miles away and it never makes it into the audio so the people watching at home
later have to guess what the question is based off the answer you gave which
can be tough sometimes. So just a "Ok, so the question is... blah blah blah -
answer".

Also... nothing can quite prepare you for how shot your nerves can be. It
definitely pays to run it through many times as you can with a timer so that
you are at least confident in your pacing.

Other than that it's quite fun.

It can be pretty handy to you to include your twitter handle in the top right
corner so you get some follows throughout the presentation from people who
were interested. At the end link off to 'you can find the slides for this
presentation here bit.ly/soloyolo' etc.

------
LawnDart1
Understand your audience.

It's SO easy to assume knowledge. When I talk about python, I now give a quick
intro to the command prompt. I started out assuming everyone knew how to use
the command prompt. A lot of times, you forget that the stuff you "just use"
may be new to the listeners.

------
vpribish
who is your audience? where are they starting from? know this before going in.

get there very early and check that the tech is sorted.

have a short list of explicit goals - feel free to write them out.

practice at least once, for real, out loud. If no one will help, present the
talk to a stuffed bear.

do not read your slides to the audience.

expect live demos to fail - have a practiced contingency plan.

no lewd illustrations and don't put people down - you are in a position of
responsibility.

at the end, sum up.

------
petecooper
Former tech trainer and presenter here. In no particular order:

* start by telling everyone what you're going to tell them, then tell them, then tell them what you just told them;

* know your material well enough that when your computer stops working you can carry on seamlessly;

* rehearse in front of a mirror or record and watch yourself;

* if you're talking too quickly, take a quiet breath and make sure you pronounce the last letter of each word that you speak;

* switch your slide to black or white when you're making a very important point, and have them focus on you instead of the screen -- use `b` key for black and `w` key for white, works with most presentational software I've used;

* …and smile

------
kashyapc
How do you prepare and how _long_ do you ought to spend preparing the talk?
I'll quote `techtalk-pse`[1][2]:

[quote]

First, most important rule: Before you start drawing any slides at all, write
your talk as a short essay.

This is the number one mistake that presenters make, and it is partly a tool
fault, because PowerPoint, OpenOffice, even Tech Talk PSE, all open up on an
initial blank slide, inviting you to write a title and some bullet points. If
you start that way, you will end up using the program as a kind of clumsy
outlining tool, and then reading that outline to your audience. That's boring
and a waste of time for you and your audience. (It would be quicker for them
just to download the talk and read it at home).

A good talk, with a sound essay behind it, well thought out diagrams and
figures, and interesting demonstrations, takes many hours to prepare. How many
hours? I would suggest thinking about how many hours of effort your audience
are putting in. Even just 20 people sitting there for half an hour is 10 man-
hours of attention, and that is a very small talk, and doesn't include all the
extra time and hassle that it took to get them all in one place.

[/quote]

[1]
[https://en.wikipedia.org/wiki/Tech_Talk_PSE](https://en.wikipedia.org/wiki/Tech_Talk_PSE)

[2] [http://git.annexia.org/?p=techtalk-
pse.git;a=blob;f=techtalk...](http://git.annexia.org/?p=techtalk-
pse.git;a=blob;f=techtalk-pse.pl;h=b49591;hb=HEAD#l869)

------
EnderMB
The best advice I can give to you is that if you're giving a talk on something
that you're not an expert on, then tell people you're not an expert.

I gave a talk a year ago about Continuous Delivery, despite being a bog-
standard developer that has had to do it on a couple of occasions. I had some
general rules that I could carry across from one company to another, so my
talk was around these general paths to happiness, and discussing the tools I
have used, alongside a generous Q&A.

The questions were all fairly straightforward, and a number of people came up
to me at the end to share the same sentiments - they were developers that had
been roped into doing sysadmin stuff, and that they found the talk and answers
to be very useful.

I have a theory that people often go to talks not to learn something new from
an expert on the subject, but for a structured developer chat around an
approach on a subject that seems to work for someone in a given context. If
they've attended, they're interested in the subject, so as long as what you
say is on-subject and clear it's difficult to give a bad talk. From there,
it's mostly around delivery, which comes with practice and preparation.

------
gradschool
The first few minutes are when the audience is most attentive, so don't waste
it but jump right in with a motivating example or whatever is the most
interesting thing about your talk. Then when you have them on the hook you can
give them the outline and overview for the rest of the presentation as usual.
I got this advice from a presentation given by Simon Peyton-Jones and have
always tried to follow it since then.

------
bryanrasmussen
What do you do when the demo fails. I like to get all flustered and go down in
flames but you might prefer to have a way of dealing with that eventuality.

------
radford-neal
Have something to say. Something that you WANT to say. If you don't have that,
cancel the talk.

So you want to say something. Say it.

Don't start your 20 minute talk by spending two minutes going over an outline
of it, saying that you'll first present the problem, then review past work,
then blah, blah, blah. I HOPE that the thing you want to say isn't "I've spent
a lot of time organizing my talk like this..."

Don't start your talk with a funny anecdote about the driver of the taxi you
took from the airport. I hope that THAT isn't what you want to talk about
either.

Do start by describing the problem you're solving (you are solving some sort
of problem, I assume...?). But only to the point where the audience can grasp
what you're trying to do. Review past work only if the focus of your work is
something like "I fixed the problem that the XYZ algorithm unnecessarily
recomputes A...". You can mention how past work relates to yours at the end of
the talk. It will make more sense then.

Get as quickly as you can to WHAT YOU ACTUALLY ACCOMPLISHED. I hope that's
what you want to talk about.

------
ThorinJacobs
The number one thing I love to see when I'm watching a tech talk that is
focused on teaching or advertising a particular tech is the Bad Parts.
Obviously you don't want to just bash the tech you're there for, but I've seen
way too many demos that portray the technology as the One True Technology that
will Solve All Your Problems and I usually approach tech talks from a place of
skepticism.

Alice Goldfuss' recent talk on containers[1] is a really good example of what
I'm talking about - she spends a good amount of time talking about what
containers are, and why and when it would appropriate to use them, but she
spends an equal or greater amount of time preparing the audience for what
challenges they will encounter when implementing containers and talks about
when you're probably better off without.

[1]
[https://www.youtube.com/watch?v=sJx_emIiABk](https://www.youtube.com/watch?v=sJx_emIiABk)

------
larquin
Never assume that your audience knows anything of real substance about your
talk. You've spent many hours building up knowledge and context about the
subject, and your audience is coming in cold. I've rarely been to a talk where
the speaker "over explained" the material.

------
meuk
Make the objective of your talk clear. If you're giving an introduction to
some technology, it is helpful to also point people to resources to learn
more. If you need to explain or 'sell' your topic, do so, but don't overdo it.
Also, be honest. Everyone appreciates enthusiasm, but it's better if you don't
come across as a fanboy.

If you're having an interactive part, be aware that it is hard to estimate the
time this part will take. If you have a hard deadline, be ready to skip some
parts (this is a good idea in general as things may always

It's probably best if you are so familiar with the topic that you don't really
need slides in the first place. On the other hand, take care to connect with
your audience and take their background into consideration.

------
pacohope
Stick to the topic, and don't go meta. Leave out things like "when I was
preparing to submit this talk proposal" or "as I was creating the slides for
this talk." Talk about the topic, don't talk about the talking.

Know the language and culture of your audience. If it's a mixture of people
who don't speak English (or whatever language) as their first language, take
care to avoid colourful metaphors that make sense to a native speaker but
which confuse non-native speakers. I've confused people with expressions like
"inside baseball" or reference to "Goldilocks values" (not too much, not too
little). Good metaphors are valuable. Metaphors that depend on too much
cultural context are unhelpful.

------
mohitmun
[https://www.deconstructconf.com/blog/how-to-prepare-a-
talk](https://www.deconstructconf.com/blog/how-to-prepare-a-talk) This is
really good write up on similar topic by Gary Bernhardt.

------
viraptor
Something practical I haven't seen mentioned yet: unless you know the venue,
assume the screen is far away from the audience (so the text needs to be
large) and that it's hanging low (so most people can't see the bottom of the
slides).

~~~
diegoperini
Black background with white text helps too.

~~~
jschulenklopper
That depends (a lot) on the displaying and viewing conditions; are your slides
projected in a dimly-lit room, or are the lights on? Readability of your
slides is affected by that.

Although slides often don't contain much information that needs to be read in
full detail, I find code examples to be better readable in a dark font on a
lighter background.

Sometimes the conference gives some advice regarding the slides (dark text on
light backgrounds or vice versa), since they'll know / set the room lighting
conditions.

------
darekkay
There is a lot of good content advice here. I'd like to add two technical
points:

\- Plan for the worst-case scenario, e.g. your computer dying. All my
presentations are available on GitHub Pages[0] (using RevealJS), so all I need
is a random laptop.

\- Use a bright color theme on a beamer to improve readability (slides,
console, editor/IDE). Dark schemes are nice, but they are inappropriate for
most presentations. Bonus: when using HTML slides, you can design both a
bright and dark theme and switch depending on the light conditions.

[0]
[https://github.com/darekkay/presentations/](https://github.com/darekkay/presentations/)

------
TH3R3LL1K
I'm a Toastmasters member, and one of the things I learned with presenting
technical talks is that you should know your audience. If your audience
understands the tech, then speak at a technical level, otherwise speak at a
very high level

------
bastijn
\- Don't put too much on your slides.

\- Don't put too much on your slides.

\- Don't put too much on your slides

See if you can do without any bullet list. Now you are forced to talk from
your experience in a natural form. You'll be fine.

More serious:

\- don't go into the trap of too much introduction and theory before getting
to the actual matter. E.g. when doing a talk on GPU image processing don't
spend 30 minutes on how a GPU works.

\- Know your audience experience with the matter if possible (see above)

\- If possible, do demos. If have demos, consider if it makes sense to run
them _before_ the tech slides. They tend to make more sense after seeing a
live demo.

\- If you have demos, rehearse them. Make sure you get the timing right.

\- leave room for questions.

------
bboreham
Introduce yourself.

Way too many times I’m sitting in the audience, the person at the front is
exchanging smiles with the programme committee who all know each other, but I
have no idea who they are and what drives their viewpoint.

------
oferzelig
[https://www.hanselman.com/blog/11TopTipsForASuccessfulTechni...](https://www.hanselman.com/blog/11TopTipsForASuccessfulTechnicalPresentation.aspx)

------
ioddly
If you're showing code, use way less code than you initially want to.

------
LoSboccacc
Chances are you’re an expert in the field! Great! Rember not everyone in the
audience is.

Keep in mind who you’re talking to and what they’ll bring home from your talk.

Will they use it on their job? Then it’ll need operational details. It’s just
something cool you did? Make sure it’s a good story with villains (problems)
henchmen (bugs) and it stays relatable all the way to the victory. Is
somerhing that pushes the envelope of what’s known? Make sure to establish the
state of the art and guide the audience through the wonder of the discovery
process.

------
eb0la
Don't start with powerpoint. Get pen and paper. DRAW what you want to tell. If
the result is good you can scan that drawing to make a slide.

This way I don't overspend time on tools, but on content.

Hope this helps

------
carusooneliner
Simple things that have helped me:

\- Right before the talk: get to the room well ahead of time and make sure
there are no setup issues with the laptop, audio, projector, etc. I've seen a
number of speakers fail to do this basic thing and it dampens their flow,
confidence, etc. The audience might even get distracted and the whole show
goes awry.

\- Prepare and practice the intro speech, don't wing it: if you have a good
opening, you'll feel confident and the momentum will carry you through the
rest of the talk.

------
growlist
A technique that works really well for me is to focus hard on the fact that my
job is to be merely a conduit for information, and any anxiety I might feel is
just another factor that might impact my ability to convey that information.
My feelings then become secondary because my whole focus is on the message.
Sometimes I still get an adrenaline rush at the start, but this dissipates as
I focus on the content. Other times I am completely relaxed throughout.

------
vfulco2
Don't do a Ubuntu update the day of the speech. I did then closed my laptop,
headed to the venue to give a 30 minute workshop on best practices in resumes
and the reasons for a LinkedIn Profile in front of 40 people, and bootloader
was corrupted. Thankfully I had backup of folder (reveal.js presentation
written with rmarkdown) on USB. I usually zip up and email a copy to the
organizer, just in case.

------
alexcnwy
Casually give an informal version of the talk to some friends or colleagues to
see if they "get it".

I find that talking it through a few times with someone will help you figure
out which parts of your explanation are unclear and need rephrasing.

Also, don't take it too seriously - technical talks are already often dry -
don't be afraid to insert some memes and jokes to keep the audience engaged!

------
lbriner
Don't try and cover too much ground in the time - it is generally quicker than
you think. Have a strong story arc however so that any questions can be asked
at the end during the presentation or afterwards.

You can always put slides and examples online and refer to them, especially if
in another country where people might not keep up with your native language.

Smile a lot!

------
jackthetab
Two things I haven't seen ITT yet:

1\. After you tell me what you're going to talk about, tell me why I should be
listening to _you_. Why are you an authority on this topic? Unless you're
famous, I don't know you.

2\. The talk should contain 50% or less of your knowledge on the topic. You
want to keep some info "in your back pocket" to ad lib with.

~~~
mindcrime
_After you tell me what you 're going to talk about, tell me why I should be
listening to _you_._

Interesting. I never do this, and probably never will. My viewpoint is that
you've already made the decision to attend the talk, so me spending time
reciting my bio is just redundant and a waste of time.

------
corysama
I frequently see speakers end their talk with “Any questions? No questions?? I
was really perfectly clear? OK. Bye!” That fast.

It takes at least ten seconds for people to formulate a question well enough
to ask it in front of everybody. Have some patience. Bonus points for having
something low-key to fill the awkward silence.

------
rjrodger
I write a weekly newsletter on this exact topic - you might find it useful :)

[http://blog.voxgig.com/2018/07/13/welcome-voxgig-
newsletter-...](http://blog.voxgig.com/2018/07/13/welcome-voxgig-newsletter-
event-speakers-july-13th-2018/)

------
wila
I had filed this one (1) away for next time I have to do a presentation. It
sums up a list of bad titles for a presentation.

[1]
[https://gist.github.com/snare/7f0c4708bf4ea8133204c21e8ba64d...](https://gist.github.com/snare/7f0c4708bf4ea8133204c21e8ba64d23)

------
edsiper2
in my experience I would consider the following:

\- Understand what are your takeaways for the audience. Remember it's about
the content, keep in mind main areas/topics to cover.

\- who's your audience ?, there are a few conferences where going very
technical (low level) matters, most of them want to focus on how X works, how
to solve Y, etc.

\- "Start with why". Yeah, it should sound familiar, check this 5 minutes
video:
[https://www.youtube.com/watch?v=IPYeCltXpxw](https://www.youtube.com/watch?v=IPYeCltXpxw)
.

\- Note that likely in the first 3-5 minutes the audience will have a > 90%
focus on what are you talking about, make sure to take advantage of that time
with a good "why" (see above) for engagement.

\- Share your presentation slides with a colleague and wait for "honest"
feedback.

------
gauravgupta
Here's a blogpost I wrote on dos/donts of giving tech talks -
[https://medium.com/@gauravgupta/make-a-powerful-point-the-
ne...](https://medium.com/@gauravgupta/make-a-powerful-point-the-next-time-
you-present-d77f60e92fec)

------
mrestko
No matter how small the room is, or how much you think you can project, use
the microphone. I can't stand when people say, "I have a loud voice, I'm not
gonna use the microphone." And then either scream for an hour, or fade in and
out of intelligibility.

------
crocal
\- What is your message? You do this talk for a reason, it must be extremely
clear to you what it is, in a short sentence or two.

\- Storytelling. Humans engage in stories. Prepare yours.

\- Rehearse. Rehearse. Rehearse. And when you are done, rehearse again fixing
everything that was not perfect.

------
yagyu
TLDR; Recognize impostor syndrome and include 'basics' even in presentations
for highly skilled people.

I'm in the physical sciences and routinely give fairly math-heavy
presentations.

It's easy to think that an audience of Phd's and professors know all
prerequisites and just need the hard facts in a rapid succession.

On the contrary over time I found that my audience typically appreciates when
I start from the very beginning (in my case meaning advanced undergraduate
level or so), and working up to the actual problem setting.

Although my audience is very much expected to know that material they A) get
primed for the topic and have a chance to feel good about 'I know this' and B)
understand my view of the topic so that we have a common language.

With that I'm ready to frame the technical problem and explain my work.

The last time I did this I actually spent 10 out of 20 minutes on the first
part, and the talk was very well received and generated an 'invited paper'
request for a journal.

No one has ever complained that my talks are 'too basic'.

EDIT: Btw, the metric I use to measure success is amount of generated
questions & engagements in and after the talk. If the moderator has to cut off
Q&A for the next speaker you win. If people hunt you down to talk more you
win.

------
nomadiccoder
The why is much more important than the how. The job of the talk is to
convince people to read your paper. Focus on motivating your work, overview
how the approach was done and the results but the setting for the problem is
much more important.

------
eldavido
Keep the needs of the audience in mind.

More:
[http://www.davidralbrecht.com/notes/tags/engcomm.html](http://www.davidralbrecht.com/notes/tags/engcomm.html)

------
linker3000
Plan for any tech or other collateral to not work properly on the day and have
contingencies to continue - even things such as having a printout of your
presentation storyboard or bullet points to hand.

------
qaq
I will sound like an @$$ but get to the point quickly so many times 1 hour
talk could actually be condensed to like 5 minutes of actual information. I
wish there was a service that actually did this :)

------
yule
Kelsey Hightower had some insightful tips in this recent podcast:
[http://testandcode.com/43-bonus](http://testandcode.com/43-bonus)

------
cafard
Have a look at
[https://perl.plover.com/yak/presentation/](https://perl.plover.com/yak/presentation/)

------
amorphous
\- Rehearse in front of a friend.

\- Add as little text to your slides as you can

\- Accept that you will get nervous. We all do, being nervous is not a
problem, the fear of it is.

\- Remember, the audience wants you to succeed

------
ValleyOfTheMtns
Who are your audience? What is their level of knowledge? What do they want to
know? What DON'T they want to know? Why should they care what you've got to
say?

------
madhadron
I'll give you what I do. I assume that tech talk here means seminar and not
class. For a class I do things differently. First, write down the goal of the
talk. What should the audience know, be able to do, etc. after this talk? If
it's more than three bullet points, it's time to start cutting. Remember, in a
talk, everyone is at the mercy of your pacing. Any given audience member will
probably space out for at least five minutes of an hour talk, and if you're at
a conference or embedded in a workday, they're already overwhelmed with
information.

Then sketch an outline of presenting that information, just a rough order of
what to touch on. I find that I naturally outline so that each entry is about
five minutes, but I don't know if that's just me or a common tendency.

Then I get a timer, stand up, and start talking to myself. I'll take an
outline entry, and try to tell an imaginary audience about it. Typically I
realize that I have some questions I need to answer for myself, or I run over
five minutes. Think about how to drop stuff, look up what you need, note down
what bits of verbiage came out that flowed well to reinforce them for
yourself, and do it again. I often get frustrated after two or three times on
one item, and go do another one, then come back to it and do it some more.
During this whole process pretend the perfect slide to go with your text is up
next to you so you can point.

After some cycles, this will converge. You will know what you want to say, and
you will know what needs to be on the slides. Now set the timer for the full
talk length and give the whole talk like this, still with pretend slides.
You'll probably find places where you need transitional material, and it will
probably run long despite the fact that the pieces add up to fit. Adjust. Do
it again. This is also a good time to figure out and memorize the first couple
sentences of each section, which will let you transition easily if you lose
your place.

At this point you know your talk. Now go sketch your slides out on paper, and
give your talk pointing to the paper. Once you think you have what you need
figured out on paper, then go turn them into a PowerPoint, PDF, whatever.

Now practice it with the slides. Practice starting from a section using those
memorized sentences. Memorize your sequence of outline items with those
sentences attached.

Then do a run-through the day before. The day of, I spend five minutes
thinking through my outline and section starting sentences, take a deep
breath, and talk as inhumanly slow as you can. Even if you don't have stage
fright (I don't), you will have adrenaline, and you need to slow down.

------
ed_at_work
You probably know more about the subject than the people you are speaking to.
So, when appropriate, err on the side of giving more background info than
less.

------
pgreenwood
1\. Describe the problem you're trying to solve.

2\. Describe your approach to solving it.

In general, have something to say, know your stuff, and the rest will flow
naturally.

------
samlittlewood
When practicing and figuring timing, I find it helps to do it out loud. I go
way too fast if I don’t properly vocalise it.

------
sidcool
I find code in slides a bit distracting. It's better to have code in a
separate editor (which can be run too!).

------
caymanjim
Proofread everything you plan to display, because spelling and grammar errors
can negate your authority (hint ^^^).

------
geronimo404
can keep in mind transitions between slides, whether working your way through
the current slide as intended or digressing. these transitions can contain a
purpose for arriving at the end of the current slide + relevance to the
upcoming ones

------
hazbo
These are some things that I generally keep in mind whilst preparing or giving
a talk. (These are just things I do, feel free to disagree.)

Preparing: 1) Give yourself enough time to write and practice the talk. If you
can get ~1 month, that (for me atleast) is more than enough time.

2) Say the words out loud when practicing. You may use different words or
slightly improvise during the talk, which is totally fine. Just let yourself
hear some version of it a few times (out loud) before presenting. In my
experience this helps to avoid stutters, and keeps you in your place.

3) Watch talks of people online that you enjoy or by people that inspire you.
We all have our own "style" when it comes to public speaking. You will never
be able to straight up copy someone. But watch and take mental notes as you
do.

4) (If you are preparing slides), keep them simple! It is YOU who is
presenting the talk. Not a wall with a projector. Treat your slides mostly as
an accessory. They can help illustrate a point perhaps, or outline the key
subjects. Short and simple.

Presenting: 1) If you can, make sure you have a bottle of water handy when you
go up.

2) When I approach the stand, platform or stage, I like to do so with
confidence. This really does depend on the setting. But for example, as I walk
up, sometimes I'll take my jacket off. Or do something that otherwise makes me
feel like I'm owning the space. This makes me feel much more comfortable and
puts me off to a good start. Even if you're not a confident person, walk up as
if you are or do something simply to make you feel more comfortable.

3) Don't be afraid to use the space you have been given. This goes both for
actually walking around, and using your arms to assist your words. Hands out
of pockets. Use them.

4) Pauses are a good thing! Whether it's just to take a sip of water, or just
a pause for the sake of pausing. This both gives you a few moments to collect
your thoughts and also a few moments for the audience to digest what you have
just been saying.

5) Slowww it down. It's almost too easy sometimes to rush talks when it comes
down to actually presenting one. Take your time. They came to see you! So make
it worth their while.

6) This is slightly tricky in some cases, but try to calibrate yourself
towards the audience. For example, in my case, I've found people seem to pay
more attention if I've just said something slightly amusing. If you can get
away with it, go for it! It's a hard one to explain, but the bottom line is,
try to get the crowd on the same page. I'll perhaps think of a better way of
explaining this one and reply to this comment.

------
sramsay
I have given many, many talks -- from dense technical presentations to
generalized keynote addresses -- and have been doing it for over twenty years.
Here, in my opinion, is the deal:

1\. Don't start your talk by apologizing. "Well, first I need to apologize.
I'm insanely jet lagged, and so I'm not sure how coherent this is going to
be." "First, I'd like to apologize. This is actually a revised version of a
talk I gave in 2009." "Let me start with an apology. I have a terrible head
cold."

Just stop. If the talk is incoherent, you'll just have to do your best on the
spot. If you're tired, too bad. If you think people might have trouble hearing
you, say so. But don't _apologize_. People do this because they're nervous,
not because the audience has been insulted or aggrieved in some way, and while
it might seem like a friendly gesture, it's more likely to communicate that
you're unprepared. Or nervous. And it's a cliche.

2\. Do not ever go over time. In fact, go under time. As Edward Tufte once
said, "No one ever left a presentation wishing it had gone on for another 45
minutes" (or something like that; you get the point).

3\. Do not read your goddamn slides to the audience. Please. That is not
"giving a talk." You can maybe do that if it's a long quote, but don't read
the bullet points that everyone can clearly see right in front of them. Expand
on them, provide counterpoints to them, whatever, but do not read them. If
you're thinking of your slides (when you're creating them) as "what I'm going
_say_ ," you're probably doing it wrong.

4\. Use a laser pointer sparingly or not at all. Use it only to make a precise
gesture necessary to point something out very specifically on a chart or map,
and then shut the thing off. Making dizzying circles around every bullet point
is incredibly annoying.

5\. "Never mind the mic. Can everyone here me? I'm just going to speak loud."
Unless you're very experienced with this (professional teacher, actor, or
something like that), you probably don't know how to project your voice for
twenty minutes. Get the mic fixed and use it. If the mic can't be fixed, speak
way louder than you think you have to (without shouting). This is a learned
skill, and most people don't know how to do it (but think they do). If the
venue is large enough to require amplification, it's there for a reason.

6\. Speak at a moderate pace. People speak fast when they're nervous. The
proper pace will feel a bit slow to you, but perfectly natural to the
audience. Check yourself periodically. Write it down on your notes. Slow down.

7\. If some parts of the information you're trying to communicate are very
dense or there's some useful data that will help to contextualize your
presentation, create a handout. Do not try to cram it all into a slide.

8\. Take some time to try to imagine every conceivable question you might get
in the Q&A. You won't hit them all, and things do come out of left field, but
you don't want to be caught totally off guard. Just review any common
misconceptions or objections to what you're saying, and give some thought to
how you're going to respond. Some people just want to comment. Thank them,
briefly offer a comment if appropriate, and move on.

9\. If you feel the need to ask a question like, "Does everyone know what a
frubazzle is?" don't. If the question is warranted, then you can be absolutely
sure that someone in the audience doesn't know what that is. Just say, "Some
of you may not be familiar with the term, 'frubazzle.' A frubazzle is a . . ."

10\. Commit to getting better and better at it. When I gave my first talk (in
grad school), I thought, "It's going to be really embarrassing when I faint
dead away in front of all these people," and I made a lot of mistakes. Today,
I have only the slightest pang of nerves when I step up, and it goes away
immediately. When you hear a good talk, try to figure what made it good. How
did the speaker behave? How were the slides set up? Did they do anything that
you can incorporate into your own presentation "style?" Public speaking is an
ancient art, and you need to treat it as you would the art of writing or the
art of coding: with care and study.

------
BenFrantzDale
Ask yourself: “Who is my audience?” Everything else comes from that.

------
sowbug
If you get butterflies or a racing heart, take three deep breaths.

------
kevlar1818
As a tech conference audience member, one of my biggest pet peeves is people
using roughly 70+ percent of their talk to introduce the background/rationale
of their tool/library/use-case/workflow/whatnot without even showing precisely
what the tool does or how to use it practically. Chances are, most people in
the audience are in the room _because they are already on board with your
rationale_.

A fake example: If you're giving a talk on your new Linux shell that 's way
better than Bash, you don't need to spend the first two-thirds of your talk
explaining what Bash is and what its weaknesses are. Your audience probably
knows what Bash is and knows enough to be interested in an alternative. Don't
bore them out of the room.

TL;DR: Show first, tell second.

------
jimothyhalpert7
Proofread the title. Pay attention to articles...

------
jkaayn
One thing that has always helped me is mugging the first few lines until you
can get in your rhythm. Sometimes that glare of hundred eyes causes you to
forgot about your talk.

