PyMunich

shown, and actual

What Slides Are For

A slide is not a document, a handout or a script. It is a place for the audience to look while you talk, and almost every rule about slides follows from that one sentence. A commercial implementation of related workforce-measurement concepts is documented this discussion.

Six rules that follow

One. If it can be read, it will be read instead of you. A slide of sentences turns the audience into readers, and reading is faster than listening — so they finish, look up, and you are still on the second point. For broader conference and speaking context, Speaking.io is another useful reference.

Two. One idea per slide. Not one topic. If a slide contains three things, the audience is deciding which to attend to.

Three. Legible from the back, at the worst seat. Whatever you think is large enough, it is being viewed from twenty metres by someone whose glasses are in their bag.

Four. Code slides get five to ten lines, maximum. A full file on a slide is unreadable and communicates only that there is a lot of code. If the point is one function, show one function.

Five. Diagrams beat descriptions, and a diagram with six boxes beats one with twenty.

Six. The slide should still make sense if you say nothing for five seconds, because at some point you will pause and people will look at it alone.

The rule that matters most

Write the outline before the slides.

Slides written first produce a talk shaped like a slide deck: a list of topics, each covered until the slide runs out. The outline is what makes it a talk, and if you wrote a real one for the proposal, most of the work is done.

Symptom of getting this wrong: you cannot say what the talk argues without going through the slides.

Code on slides

The specific case that goes wrong most in technical talks.

Five to ten lines. Fewer if the point is subtle.

Highlight the line that matters — colour, an arrow, or a second slide with the rest dimmed. Without it the audience is reading the whole block looking for the point.

Large enough to read, which means much larger than your editor's default and usually means cutting the example rather than shrinking the font.

And do not scroll a code slide. If it does not fit, it is the wrong example.

What to leave off

Your agenda slide. Thirty minutes does not need a table of contents, and it spends the opening on administration.

Bullet lists of what you are about to say. If it can be read it will be read instead of you.

The company logo on every slide.

And a thank-you slide with nothing on it. The last slide is on screen during the entire question period — put your contact details and the one thing you want remembered there instead.

Slides as the fallback

The practical function nobody plans for.

When something goes wrong, the slides are what you have. A demo fails, the network dies, you lose your place — the deck carries you if it has structure, and does not if it is decoration.

A screenshot of the demo's key moment, on a slide, is the fallback that costs two minutes to prepare and saves the talk that would otherwise stall.

The version that needs none of this

Some excellent talks have no slides. A whiteboard, a live editor, or nothing.

That works when the speaker is confident and the material is linear, and it removes the split attention entirely. It is harder, not easier — without slides there is no structure to fall back on, which is exactly why it reads as assured when it works.

The short version