Whenever I return from PyCon, I return with a feeling of joy tinged by disappointment. The feeling of joy is easy to explain. The disappointment comes from the feeling that so much talks miss their audience for simple flaws — flaws that would be easy to fix. Giving great talks is hard. However, giving talks which are vastly better than the average in a technical conference (PyCon is not unique) is not hard — it requires applying some easy to follow guidelines.
Many talks have no content. Sadly, having good content is something you must start with when writing the talk — you should have something to say. However, in technical conferences, filtering based on the content, while not a perfect filter, is more accurate than filtering on the quality of the (non-existent at the time) talk. This makes a talk with good content but bad layout a more common failure mode.
Giving talks is a skill. Much like programming, it is a skill that can be improved with experience, no matter how much raw talent you start with. In fact, it is really a sort of programming — hacking the human brain. Hacking, here, is in the sense of a “good hacker” — one who understands the system in order to use it more efficiently. Understanding the human brain, and how it responds to stimuli, is important to giving a good talk. As well, there are many heuristics for how to use that understanding to run code that executes well. Learning all those heuristics, and the theory behind them, will not make you a great speaker, nor make your talks be amazingly good — just like reading a Python tutorial did not make you a great Python programmer the next day (it certainly didn’t work for me).
That, however, does not mean that reading a Python tutorial is a bad way to learn Python. It just means that reading a tutorial alone does not one a great hacker make. There is raw talent to consider, of course, but also practice in how to apply all of that advice to the situations one encounters in real life. However, consider someone who tries to write in Python without reading a tutorial at all — just guessing based on what they code they have seen around the internet.
Sadly, the human brain came without documentation, like most open source projects. Luckily, we have many people who worked on understanding the human brain. Writing code meant to execute on brains is easier, and more efficient, after reading what sparse documentation we do have.
Human beings are storytellers. There is a lot of research in psychology that shows human beings are attracted to a good story. What makes a good story is details, often visual ones. Instead of talking about the code you wrote, talk about the situation that led you to write it. Another thing that makes a good narrative, as any author knows, is conflict. Set up a protagonist, and a challenge for them to overcome. Make the challenge look impressive. It is OK, by the way, if the protagonist fails — literature has many great tragedies.
As I hope you noticed, this explanation is built along a narrative. There is a protagonist, who wants to give a talk. The protagonist must overcome the challenges the vagaries of the human brain in order to get to her goal — making the audience learn something.
Human beings are wired to care about human beings. They are not, sadly, wired to care about technical subjects. That does not mean that they do not care about such subjects at all, but that they are unlikely to quickly be made to care about the technical subject you introduce. Luckily, you are a human being, and they care about you. One quick hack to transfer the caring is to relate the technical subject to yourself, using personal anecdotes.
I was in a talk where the speaker started with a personal anecdote about his first day at work. Everyone, of course, cares about this topic — first day at work is an inherently scary experience, and he had everyone glued to their seats. Later, I happened to have a conversation about this talk with someone and he said he liked the talk “it’s great when the speaker launches straight in and starts giving you information.” The speaker, of course, did no such thing — he started by making the audience care about the topic, by transferring their caring about him.
The fact that this member of the audience did not even notice that this is what was going on shows why I refer to these techniques as “brain hacking” — send the right program, and the audience responds in good ways. It is up to you, of course, to use these techniques for good rather than evil.
Human beings are visual creatures. We understand the world with our eyes. For some people, this means that they need to put, in their presentation, the words that they are speaking. This is the worst thing you can do. Because we perceive things visually, if the words are on the screen, they will be read off the screen — but because the screen is not a human being, the audience will care less about them.
You need to hack the audience to listen to you speak. Fortunately, this is easy. Human beings, in addition to being visual creatures, are inherently puzzle solvers. If you present to them a puzzle in your visual aid, they will listen to you as you present the solution. Unfortunately, this means that good talks are rarely useful as the notes for the talk. Think of it as an optimization problem — if you optimize your talk to be good notes, it will be sub-optimal for the audience. If your main goal is to create good notes, and the talk is secondary, as is the case often in colleges, that is a valid trade-off to make. It is almost never a valid trade-off to make if you are giving at a talk in a technical conference!
What kind of puzzles can you use? Any kind of visual aid that hints, but does not say, what you are about to explain. Another useful trick here is to put pictures of things humans find “cute” — our brain is wired to enjoy those, and it is good to have people to enjoy the talk. There is an easy description of what humans find cute — roughly-humanoid shapes that are proportioned like human babies. Human babies have proportions which are different than adults, and these proportions are pretty much universal in the mammalian clade. Baby, kitten and puppy pictures, thus, are good defaults. A baby, kitten or puppy that does something vaguely related to the topic you converse on is easy to find. Put a few words on it, no more than 10, that can be easily read, and you have a great visual aid.
Other visual aids include diagrams, source code and a simple slogan or question — “Why should you care about generators?” or “Python is faster than C”. All of these serve as a useful puzzle, without giving away the “answer” — your explanation of the diagram’s importance, the logic of the source code, why should I care about generators or how come Python is faster than C. Since it’s a puzzle, you must observe a rule — “never have the solution on the slide.” This rule, which I sometimes approximate as “never have the words you say appear on the slide” is easy to apply and will make any talk better by itself.
Human beings evolved in an ancestral environment with tribes of 50-100 people at most, and without writing. In such an environment, any discovery made by anyone in the tribe can be easily communicated to anyone else — they share almost all of the basic assumptions, so that just relating the new stuff is enough. Our brain is wired to assume that the people in front of us share most of our understanding, and assumptions, on how the world works. That works both ways — the speaker tends to assume a level of understanding that the audience is not likely to share, and the audience is likely to assume that a speaker who makes too many unbased assertions is just trying to fool them — because that would have been a valid assumption in the ancestral environment.
One trick to force yourself to reduce inferential distances is to deliberately assume incorrect things about the audience. Instead of assuming they are all somewhat experienced Python programmers, try assuming they are highschool students who know just a little bit of Python.
Even more than caring about other human beings, human beings are wired to care about themselves. An almost universal tendency among humans is to both find being smart important, and to over-estimate how smart they are. By explaining things well, ideally to a level that’s slightly below the audiences, they will get to experience that feeling of smartness — “wow, I really get the trick here, I must be so smart!” That experience will enhance their enjoyment of the talk. When solving a puzzle, as explained earlier, you must make the solution look hard but feel easy. That tension will resolve as “huh, I could have solved the puzzle myself” and therefore, “I am smart”. One easy way to do it is by giving progressively stronger hints on the solution to a puzzle, until by the time you blurt out the solution, the audience have (mostly) gotten it.
I have seen this used to a wonderful effect by a talk on writing adventure games in Python — the speaker led the audience down a garden-path of getting to the solution of “overloading __repr__ to have side effects” by giving progressively stronger hints. By the time he was showing the code, the audience expected to see this, and people felt good about themselves. Predictably, this was deemed to be the best lightning talk in its immediate surroundings.
A speaker who fumbles can be endearing, so the occasional fumbling by the speaker is ok. Especially “inherent” flaws, such as a bad accent, are easily accepted by the audience. However, not respecting your audience by fumbling things which should not have been fumbled is a good way to get them annoyed. Code examples should work. You should know where the talk is going. The talk should be accurate. A technical audience will notice, and will tune out when it is clear that the speaker took short-cuts.
The worst way to give a talk is to prepare a bunch of power-point slides with what you want to say, and read them out loud. Sadly, the default way to prepare a talk is to launch into power point, and start writing up notes of what you want to say. This horrible situation has caused the default quality of technical talks to be abysmal. This is made worse by the fact that programmers are not used to writing code that runs on human brains, and worse — human brains’ architecture being much different to the architecture of the typical programming environment. Since programmers are still human beings, talks written with understanding for how human beings process stimuli can be much better than the default, delivering a satisfying experience for both speaker and audience.