Continuing education at work (talk)

October 10, 2015

This talk was presented in Portland at PyDX 2015, in Detroit at self.conference 2016, and in Cincinnati at RubyConf 2016. I previously mentioned these continuing education programs in this blog post.

Quick links to resources:

The list of things we want to learn is infinite. How many of us have marked talks to watch, or books to read, yet have never gone back to them (until our browser crashes and we lose everything that was in an open tab)? Left to my own devices, I often only learn what I directly need in my work, despite the best of intentions. It wasn’t until I started running a couple lightweight continuing education programs at work that I followed through on my goals around continuing to expand my technical knowledge base. This talk will discuss setting up programs to finally get yourself reading those technical books and watching technical talks. We’ll discuss strategies for making these programs low maintenance and long-lived, as well as flexible enough to help both more and less experienced folks. If you’ve been looking for a more structured approach to self-education, this talk is for you!


Response to my talk, on Storify: PyDX, self.conference, RubyConf

Appendix of painstakingly nitty gritty details I didn't include in the talk:

General items:
  • How do you gauge initial interest in these kinds of learning groups? 
    • Find ways to work it into conversation. When people ask you what's going on or what you're doing, say, "I'm considering starting a ___, what do you think? Would you be interested in participating?"

  • Picking a day and time:
    • Early in the week is good, not enough time to be pushed aside from pile of work to get done before the end of the week, have had the weekend to catch up on reading if needed. We have Technical Book Club on Mondays and LunchConf on Tuesdays.
    • Time of day: not in morning, to have lunch time to do reading for book club.
    • Weekly cadence is nice because you don’t have to question whether it’s an on or off week, but if every other week is needed, that’s ok too.
  • Calendaring:
    • Give everyone modifying rights to calendar event, to be able to add others (in general, have open editing permissions).
    • Set up calendar events for yourself for any logistics items that need reminders, then don’t have to remember, get prompted by calendar notifications.
  • Tracking: I started tracking attendance somewhat surreptitiously, just in case I need some data on participation to show management. But I haven't actually been asked for that yet.

More details on Technical Book Club:
  • Book recommendations:
    • We're keeping a running list of recommendations, trimmed regularly (like if the person who suggested the book isn't around anymore and none of us left have any interest in it)
    • Solicit recommendations from larger office/engineering teams (also a way to publicize the group!)
  • Voting on books:
    • About 2 weeks before current book is slated to end, announce in various channels that next book is being decided upon.
    • We review the choices, to remind people what each book is about and why we might want to read it.
    • Then do runoff voting, everyone gets 3 votes in the first round (and can double up on one selection if they want), 2 votes in the second.
  • Ordering books:
    • If the book is written by an indie author and you have ties to the community, doesn't hurt to ask for a group discount! Authors seem delighted when people read their books as a part of a book club.
    • Expensing: just because there isn't an official education budget doesn't mean there aren't funds to use, ask! Sometimes not an official budget because they don’t want to set a ceiling on what people think they can ask for, but on balance, books are very good value for the company when compared to sending people to classes and such.
  • Reading assignments:
    • Wrap up discussions with settling on next reading assignment.
    • Don’t want to be stuck on the same book forever and need to feel like making forward progress each week, but not be hugely time consuming. Aim to finish the book within 2-3 months.
    • ~30 pages or 1-2 chapters usually about right, depending on space taken up by sample code. It's about what people could get done in 1-2 hours.
    • Post the assignment in the chat room and put it in the header--want to make it really easy for people to look up what the assignment is without having to ask someone else.
    • Post a reminder the morning of book club on what the reading is.
  • Also announce who agreed to facilitate the next meeting, so everyone knows and it's recorded.

More details on LunchConf:
  • Have a form (example to make a copy of) for submitting talk nominations, from what people have seen themselves and thought was really good, or from blogs/Twitter.
    • Minimum required fields: title, link to video
    • Additional info: speaker name, talk abstract, length of talk (rounded to nearest minute, for easiest sorting), link to slides
    • Include a link in the form description for how to view previously submitted nominations, so you don't get duplicates
  • Calendaring:
    • I have a room that's booked for an hour and a half. We always start 20 min after the hour to have time for A/V setup and people to get lunch, then 30-35 min talks, then a bit of time after for people to use the room to stay and whiteboard or discuss if they want to, but can also leave in time for 1pm meetings.
    • Room booking and invite event are two separate calendar events, and attendees are only on the shorter event. That way, we don't get kicked out of the room, but it's not a scary looking 1.5 hour block on someone else's calendar, only mine.
  • Choosing talks to vote on:
    • Facilitator gets to pick 3 options.
    • Good to try to pick a spread of topics so there’s a diversity of topics and appeal.
    • If there are shorter talks, bundle a couple short ones together. 
  • Voting:
    • Initially counted votes manually (keep it simple), but then used the HipChat bot Polly. Now we do reaction voting in Slack, which is nice for allowing people to vote for multiple options rather than just one. The talks recommendation spreadsheet also has a copy of the generator I built for the Slack messages, making things easy by allowing you to just copy/paste to set up the voting.
    • Announce which talk won in the chat room at least 30 min before people leave to get lunch, so they can decide whether to attend or not.
  • Video playback tips:
    • I use the youtube-dl command line tool for downloading videos from YouTube, that way won’t have streaming or connection issues
    • Oftentimes there will be multiple videos you can play for a talk, try to pick the one that seems highest quality/most official. 
      • If possible, check any comments on the video in case video is corrupted in some way. Be suspicious of a video that's shorter in length without an explicit description that it's actually a shorter version of the talk, versus a corrupted video of the same talk. (I'll note that this is the ONE exception to ever reading YouTube comments!)
    • If you want to try playing the video at a faster speed, easiest way seems to be get Quicktime 7 and adjust the playback speed using the A/V controls panel (under the "Window" menu).
      • I find we can go as fast as 1.25-1.5x, depending on speaker pace and density of topic. If the original talk is 50+ min though, then it's usually better to just play it over 2 weeks instead.
  • After the talk is over, try to find the slides and share with the group, helps reinforce the topic. If possible, good to have slides handy even beforehand, in case the slides aren't easily visible on the video.
[Update] Great post from James Cheng about how he implemented LunchConf at his workplace as well! I especially like the tips on how to include remote teammates.