How to Give an OK Talk at a Technical Conference (Like, Oh, Say, PyCon)


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.

Visual Stimulation

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.

Inferential Distances

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.

Feeling Smart

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.

Feeling Respected

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.


5 Responses to How to Give an OK Talk at a Technical Conference (Like, Oh, Say, PyCon)

  1. halley says:

    Great points Moshe! Unforunately not all of us get to include the “bad accent” feature 🙂

  2. Jonathan D says:

    However, I would add three more points: practice, practice, practice.

    You can read all you want about violins, and you can listen to lots of masters of the art in concerts, but that won’t make you a good violinist. Probably not even a mediocre violinist. You have to practice. For speachmaking, I highly recommend ToastMasters.

    • moshez says:

      That’s the same point, three times…

      …a point that I did make: “also practice in how to apply all of that advice to the situations one encounters in real life”.

      Everybody knows they should practice. However, practicing giving bad talks is not actually useful. Nobody gets to be good just by practice — unless they practice applying the right principles, they’ll get bad and set in their ways. You can easily see this — there’s lots of “experienced speakers” who suck because they have not practiced actually applying the right techniques.

      Why ToastMasters? Why not just give lightning talks in every opportunity one gets? We have one of those at work, and I can honestly say I never felt like going there even a little bit… Their resources seem to be stuff like — giving a list of fairly basic advice, without any of the theory behind it.

      Honestly, if I didn’t know you, I would assume this comment came from a spambot 🙂

      • Jonathan D says:

        The reason I like ToastMasters, and the same goes for seminar/journal courses in grad school, is that you are evaluated by your pears and get immediate anonymous (and non-anonymous) feedback.

        So I guess what I should have said was that you need lots of practice+feedback. Just giving a speech to a mirror does not help you much.
        And indeed I’ve found that flash talks are pretty similar to a mirror in terms of getting honest feedback, and therefore are not really a useful learning experience, except for lowering your fear of public speaking.

        And yes, you’re right, many of the TM resources are not that helpful. That’s not where they put the investment.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: