Every talk is a stage show

I was reading this post from Ivan Grishaev’s blog, Data Driven Development is a lie.

In it, he argues that the Clojure obsession with DDD is helpful and useful for a small set of cases. Those are the cases that are talked about most and presented as successes on the stages at Cloojure conferences. This increases the “cargo cult” but also makes people second guess their own abilities. When they aren’t able to apply this type thinking to their own problems then they feel like failures.

It was an interesting article but I don’t think I know enough Clojure to be able to weigh in on it meaningfully.

What jumped out at me was this quote from near the end of the article:

Every talk is a staged show where the best parts are exposed to the viewer, and the failures are held back. No one gets to the scene to tell us how they’ve messed up.

I’ve given a few talks at conferences and meetings, and hope to give more in the coming months and years. I think the temptation to come across as the guru and sage is strong. Ivan is right - most talks show the finished product, the solved problems, the excellent execution. If there is any discussion of the problem, the concern and worry these are skated over briefly so the speaker can impress with their genius.

But, some of the best talks I’ve seen are those that do exactly the opposite.

Instead, they pull back that curtain and show the issues and problems. They help us live in what my wife calls “the space between the question and the answer”. To see that there might not be a clear answer, that the possible solutions are all lacking, that you can solve this but there are tradeoffs.

I think the role of a conference talk is not just to teach or show off a new project or technology. It’s also an opportunity to validate the work of developers in the trenches. Of acknowledging and honouring that often pragmatism, a tough product schedule and growing technical debt make it hard to put into practice those things we learn from conferences.

Let’s make sure we don’t beat developers up. Inspire and enthuse, yes. But, when you get to the hard bit - don’t skip over it. Show them you know where they are and how they can solve their own problems.

Help your audience be badass!