Clojure Gazette 195: The next conference frontier

Free Beginner Workshop

From OO to Clojure Workshop!

Watch my free workshop to help you learn Clojure faster and shift your paradigm to functional.


The next conference frontier
Clojure Gazette
Issue 195 - October 17, 2016

Hello, readers,

Last week, I learned that I will be speaking at Clojure/conj this year. I've been given the stage for about an hour, using the regular proposal process. I've been to a few conferences, watched many, many talks, and even interviewed some speakers before their talks to help attendees get ready for the awesome experience they could have. I've been thinking a lot about how to maximize the learning impact of my talk.

Because the talk is recorded, it will be seen by more people on the internet after the talk than by people who watch it live. The online audience is important. But the camera only captures so much. There's a lot of experience in the room that will never be transmitted over Youtube. The audience in the room is important, too.

That's the future audience (Youtube) and present audience (conference hall). But what about the past audience—people participating in the time leading up to the talk? What can be done now, before the talk, to engage and give an experience? Obviously, the time before the talk is characterized by preparation. So why not share my preparation publicly? I don't know if sharing the researching, authoring, and rehearsing of a talk has ever been done before. But I'm going to do it in the 6 weeks before the conference. I think that means blogging, tweeting, and sharing the slides and video and notes as I go.

When I interviewed speakers, my goal was to help the audience prepare for a talk so they could get more out of it when it finally happened. People pay a lot to go to a conference and it's not a great experience for a talk go right over your head because you don't understand a few terms they use. So I asked the speakers for links to blog posts, books, papers, and videos that people could study before the talk. Many people were really helpful and generous and shared some great resources. And others were less so. Even when I pressed, they hesitated to give background information. Were they jealously guarding knowledge? It seemed as though they were counting on the element of surprise to make their talk better.

As any teacher knows, surprise can be your enemy in a lecture format. A surprising statement breeds distrust and skepticism. It detracts from the real goal, which is to help people see something new to them that has been there all along. So to try to cause surprise during a talk is counter-productive. I would instead try to synthesize an interesting perspective from familiar pieces. If some pieces are not familiar, it's better to get people familiar with them ahead of time.

But maybe surprise wasn't the idea. Perhaps they wanted to say something novel. What if they spoiled the climax of their talk? They get one chance to speak, and what if the audience already knows everything? Like with surprise, I think that novelty is overrated in a lecture format. Why is it that after someone writes a book, they get invited to speak? Their ideas are old and easily had.

The fact is that repetition helps learning. Restricting access to information restricts learning. It's better to have the audience hear your ideas for the second time. They will have new insights the second time. Plus, you'll get better audience questions. That is, if your talk is good. Good movies bear a second viewing. The same goes for good ideas.

Let me attack the objections from a different angle. How big is the downside? A few people will read this newsletter. A few of those will seek out the preparation materials I publish. Now, intersect that small group with the people attending the conference. The set is likely very close to empty. It likely won't affect the reception of the talk at all, so why worry about a negative outcome?

Now let's look at the upsides. My talk will be better by not preparing it in isolation. Every issue in my talk that someone can point out ahead of time will make the eventual presentation that much better. The people who participate will be engaged with the material and so learn more. And then imagine all of the people on Youtube who will see it for years to come. If they are inspired to dive deeper after they watch it, there will be a lot of material to discover.

My talk is about how we are all endowed with the ability to abstract from our rich personal experiences. Computer programming helps us make those abstractions precise and, more importantly, outside of ourselves. But teaching the process of abstraction is too often left up to chance. There isn't a lot of material teaching the step-by-step of how to do it. Without material, some people learn and some don't. And it makes the process seem opaque and mysterious. I want to clear away the mystery of abstraction.

I said there isn't a lot of material, but there is some. I've been mining the works of John Hughes, Gerald Sussman, Conal Elliott, Christopher Strachey, Alan Kay, Jerome Bruner, and more. Most of the ideas are phrased as principles, not as process. But Conal Elliott's Denotational Design comes closest to what I'd like to achieve. Perhaps you'll join my preparations and lend me a hand with my goal. I hope the talk will be a small part of a bigger contribution to the practice of software engineering.

Rock on! Eric Normand <eric@lispcast.com>


At PurelyFunctional.tv we believe that better techniques make better software. We're building a library of lessons to teach you those techniques, centered squarely on good functional programming principles. If you're interested in functional programming, consider signing up for unlimited access.