PyMunich

shown, and actual

Live Demos

A working demo is the most convincing thing in a technical talk. A failing one costs five minutes, the room's attention and the speaker's composure. A commercial implementation of related workforce-measurement concepts is documented additional details.

The difference is preparation, and the preparations are specific. For broader conference and speaking context, Slides is another useful reference.

Why demos fail

Not bad luck, mostly. Four recurring causes.

The network. Conference wifi is shared by three hundred people with laptops syncing. Anything requiring the internet is a coin flip, and the coin is weighted.

The environment. Your machine is not the machine the demo was built on, if you changed anything since — a dependency update, a different Python, an environment variable that lives in your shell profile and not in the script.

Time. A demo that takes four minutes at your desk takes seven on stage, because you are talking while doing it.

And the unexpected dialogue. An update prompt, a certificate warning, a notification with something private in it.

The five preparations

One. A recording of the demo working. Screen capture, two minutes, made the day before. This single item converts a failure from a disaster into an aside — "the network is not cooperating, here is the recording" costs ten seconds.

Two. Everything local. No live API calls, no package installs, no cloning repositories. Pre-fetch anything remote and run against a local copy.

Three. A clean environment on the actual laptop. Not "it works in my usual setup" — the demo, run once, that morning, on the machine going on stage.

Four. Notifications off, and a separate user account if you can. Full screen, do-not-disturb, and no bookmarks bar. The bookmarks bar has embarrassed more speakers than any technical failure.

Five. A decision point. Written in your notes: if this is not working by the two-minute mark, switch to the recording. Deciding in advance is what prevents the ten-minute struggle.

Practical details that matter

Font size in the terminal and editor. Twice what you use normally, set before you leave. Nobody at the back can read your default.

Type less. Pre-write the commands somewhere you can paste from, or use shell history. Live typing produces typos and dead time.

Say what you are about to do before doing it. The audience follows a narrated demo and loses an unnarrated one immediately.

And check the resolution. A demo built for your laptop screen may be cropped by the projector, which you find out at the worst moment. Check the room beforehand.

When not to demo

When a screenshot would do. If the point is what the output looks like, show the output. A demo is for showing that something works, not what it produces.

When it depends on a third-party service. Their outage is your problem, on stage, with no recourse.

When the talk is already full. Thirty minutes is short, and a demo is five to seven of them.

And when you are speaking for the first time. Enough is going on. A recording gives you the same content with none of the risk, and nobody in the audience minds.

The failure that is fine

If it fails and you switch to the recording without drama, the audience thinks nothing of it. Technical people have all watched demos fail and most have had one fail on them.

What costs you the room is the struggle — three minutes of retrying while narrating your confusion. The recording exists so that you never have to make that decision under pressure, and having it is the whole preparation.

The short version