Posted 2019 October 20
Whenever I give a presentation, whether it’s for a few colleagues in a Board room or for a few dozen at a conference, I always learn something. Most of the time, it’s in doing the research. Even if I proposed the talk because of recent work I had done on a particular topic, there are still details that I discover when I prepare the slides because I am striving to be precise in my words and to have a level of completeness. But I can also learn when I give the presentation. Here are some of my takeaways from my visit to the 2019 MacTech Conference in Los Angeles (Redondo Beach) this week in that regard.
Your Audience is Broader Than You Think
I generally poll the audience for each talk in some way to get a better feel for the crowd. The talk I gave at MacTech was unusual for me in that it had assumed a prerequisite: that audience members knew enough about AutoPkg that they would have come across the need to write their own recipe or at least want to explore the recipe format. And yet, when I polled the crowd off the top, there were attendees who weren’t using AutoPkg at all (yet). In a conference where the attendees can choose an alternate session, a visit to the trade fair, or even to enjoy extra sleep or the California sunshine, it was not obvious to me that beginners would attend my session. On the other end of the spectrum, I had two people in the room who had written custom processors for AutoPkg recipes, something I haven’t done. The fact that all these people who weren’t in the “sweet spot” for my talk still attended made for a bigger audience but made it harder for me to reach them all. But maybe that’s not my job. My job is to present what I’ve learned as clearly as I know how, taking care not to lapse into jargon without defining it.[1] The audience members will get out of it what they get out of it — the reason they chose to attend is their business. In retrospect, I think there were ways I could have done my “job” better in this talk, but that was also related to the fact that my session was really better as a 75-minute talk with Q&A, so I had to do some hand-waiving and glossing over details to fit into the 50 minute block. I’ll take that learning forward.
Confine Your Topic
Along those lines, the best talks I saw at the conference were those who had a clearly delineated topic that was not too broad (“simple” is the wrong adjective here). I always love Greg Neagle’s talks because he always seems to find that sweet spot — they never feel rushed, I never feel overwhelmed by the amount of information coming my way, and I always have some takeaways. Both of his talks this month (on Python 2/3 at MacTech and AutoPkg at MacSysAdmin) were exemplary in this regard. For me, I have a tendency to want to share everything I know on a topic, which has caused problems with respect to length in my last two major presentations. Being time-constrained has certainly taught me how to be more vicious with my editing (cutting that slide or anecdote that is not really necessary, no matter how much I love it), but seeing how that benefits the audience is something I need to remember. Better yet, I should do that editing at the proposal stage, as no one will complain if I give them more content than I promised in the session description.
Patterns Emerge
A number of years ago, I did a personal inventory of sorts. I looked at things in my life (particularly the ones that weren’t working for me any longer) in as objective fashion as I could. What surprised me was not the individual things I uncovered — I knew most of them, just not in that detail — but the patterns that emerged that I wasn’t conscious of. A similar thing happened in the rehearsal and giving of this talk. When I was working on the deck, I had to do it in chunks, so I dug in deep to each section with only a passing thought of how it fit into the overall structure (which I had created when I proposed the talk in the first place). When I started rehearsing it, I noticed a thread or two that weren’t explicitly part of the structure I had built. Admittedly, there are a number of ways I could have approached teaching how to author an AutoPkg recipe, so the fact that a cross-thread might emerge should not have surprised me. But it did. In fact, there will likely be a future blog post or an addition to the AutoPkg wiki because one such thread — the standard components of a download recipe — makes sense as a separate resource.
The other major idea I learned this way was that I could have described how people write recipes more correctly. I’ve said in two consecutive presentations that people write recipes by copying other recipes, using Recipe Robot, or — somewhat laughingly — starting from scratch. While that last one might have been true in 2010 when Per Olofsson developed the recipe format, it really hasn’t been true since. Everyone at this point writes their AutoPkg recipes from a template. That template can be an existing recipe, something that Recipe Robot generates (a customized template, if you will), or something that the new-recipe verb generates. That’s a much better way of describing it, pedagogically, and it is what I will use moving forward.
MacTech Slides and Resources
The resources for that MacTech Conference presentation, Writing and Understanding AutoPkg Recipes — including the slides and a link to the video recording of the session — are now available on GitHub in a repo in my account (jazzace) named mactech-2019-autopkg.
Updated 2021-04-26 to clarify that the video recording of my 2019 MacTech session is linked from the same repo as my slides and resources.
[1] In this regard, I’d like to give a shout out to Canadian speakers Tami Miguens and Alex Narvey for applying this principle in recent talks of theirs I have attended. They took the time to state what the acronyms JSON and REST (respectively) stood for (JavaScript Object Notation and Representational State Transfer, if like me you didn’t know). [Return to main text]