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.
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.
> 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.
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.