Lessons learned from my Northeastern talk:

1. If your talk is about something abstract, make it concrete with an extended analogy that you thread through. I opened with some talk about Mars and Earth and how they want to interact but the Martians are afraid of Earth germs, and threaded that through the entire discussion. I thought it might seem to cutesy and the audience of staid and serious computer scientists wouldn't go for it, but I found that even staidest and seriousest people there were completely happy to think in terms of forcefield-encapsulated Martians travelling to Earth and so on. If anything I think it actually really helped the audience understand what was going on, based on the evidence that audience questions seemed to be phrased in "Earthlings versus Martians" terms much more often than "Scheme versus ML" terms even when my slides weren't talking about that analogy at all.


2. If you follow point 1, make sure you understand that extended analogy perfectly! Like I said, I added in all my discussion of Earthlings and Martians last week; I've been working on this line of thinking for a year or so at least and so the Earth/Mars/forcefield way of looking at the problem is something I translate my thoughts into rather than a tool I use to think about the problem in the first place. For my audience, though, it was the other way around, and as a result I think they actually saw the analogy more clearly than I did myself. I got a question about whether you had to wrap Martians-in-forcefields in Earth forcefields to send them back to Mars (this being an analogy for sending a foreign value back to the language it comes from). I heard "When you're sending a value back to its host language, don't you need to make it completely opaque to that host language?" and answered "no"; but the analogy doesn't actually quite work that way and the answer really ought to have been "Yes, and forcefields cancel each other out." People really really didn't like that answer, and for a while I thought the audience was going to revolt and refuse to buy a central premise of my talk. Turns out they actually understood what I was saying better than I did and were correcting me.


3. Practice practice practice, and find someone to listen to you do it. The more you practice the wording and delivery of your talk before you give it, the better it will be, and having someone listen to your talk can be invaluable to telling you where you're being confusing, where you're belaboring things, and where you're doing well (also how funny your jokes are). Don't decide exact phrasing you're going to use on the spot. Of course this advice is obvious and something I already knew, but every time I give a talk it amazes me how much just going through it a few times with a couple people makes it go from awful to good.


4. Don't suddenly discover a few hours before your talk that you've got a non-negotiable deadline an hour after your talk finishes. I can't stress this one enough.


5. It's much more fun to give a talk to a bunch of smart researchers whose interests are closely aligned with your own than it is to give a talk to a more general audience.

By the way, people have requested my slides, so I've put up a little companion page that has both the slides themselves and the reduction systems I talked about encoded as PLT Redex programs.