Sasha Laundy

How I Prep in the 24 Hours Before Giving a Conference Talk

Last week, I gave a talk at Strata, O’Reilly’s data science conference. Every time I give a talk I get a little bit better at it. I’ve seen a lot about how to propose talks and prepare slides, but less written about preparing right before your talk. Here’s what I’ve figured out works best for me. I’d also really love to hear from you about how you prepare!

Part of my motivation for a behind-the-scenes post like this is that beginners compare polished final products to their own messy work and then they are sad. It is important to know that behind every polished talk there is no magic, just messy work! Lots and lots of messy work.

So here is my messy work—some things I did this time that worked well.

First of all, I signed up to give the talk beforehand at a different conference in my hometown. This forced me to prepare months ahead of time and I was able to gather some helpful feedback. This is a GREAT idea and I plan to do it as much as possible.

By the time I was getting on the plane, I had already created 80% of the slides I needed. So in the 24 hours before the talk, here’s how I prepared:

  • I paged through my old slides and decided what sections to cut out. I needed to cut the talk from 30 minutes to 16 minutes, and some pieces of it were ‘nice to have’ but not critical to my main points. I left placeholders where I thought I needed to add slides. It’s really tempting at this point to fuss with the slides forever. Resist!

  • I immediately did a live runthrough! I just stood up and started talking over my slides as if I were presenting for real. This was so awkward at first but a few minutes in I was sailing! There were some rough spots but never as many as I expect, which made me feel really good! A large part of being prepared is managing your own emotions so this is actually really important!

  • I used Keynote to record this runthrough, which is very easy to do (I love Keynote). I then listened to it and noted rough spots: places where I rambled, tough transitions, and slides that need to be adjusted or removed.

A picture of my laptop and notes on a hotel dresser.

Preparing in my hotel room. Gotta keep up the potassium.

A picture of notes I took on my talk.

Notes on what to change for next time.

  • At this point, I paid closest attention to the transitions. At this point the slides were pretty set, but what went between them was a little rough. I like each slide to be set up by my words before it comes on, and transitions are absolutely key to continuity. I sometimes left extremely brief notes to myself in all caps in the presenter notes just in case I brainfarted on stage.

  • When I did this rough runthrough, I did it standing up and with my clicker. I tried to picture the conference room in front of me. That way, wouldn’t be as surprising to walk up on stage and I could be nice and calm during the real thing.

  • I made sure I knew how to get presenter tools to appear when I plugged my computer into the big screen. Hint: you need to know the menu-bar-dragging trick in Display Preferences.

  • I wrote a little stickie that said ‘TALK SLOWLY :)’ and put it next to the keyboard on my laptop

  • I made PDF copies and put backups in Dropbox, just in case my laptop met a watery end at lunch.

  • I made a quick little landing page for the talk. I pointed to it from the top of my website and a pinned tweet so people could find it easily during the talk, and I added useful stuff to it right away. The bulk of your audience may not even be in the room so this is a great way to get the most value out of your talk. For example, there were about 30 people heard me deliver my PyData NYC talk and over 1,000 have watched the video on Youtube.

  • And of course, I power posed :)

This is what I’ve found to work for me for prepping in the 24 hours before the talk. What works for you?

My Talk at Strata San Jose

Looking for the links and book recommendations from today’s talk at Strata? Here you go.

Make sure to bookmark the page as I’ll be adding more later today.

The Best Lesson From Hacker School Is Hiding in Plain Sight

Last spring I attended Hacker School, which is a 12-week retreat for programmers in NYC. It is a truly fantastic program and many other Hacker Schoolers have written lots of nice things about the program and advice to new folks that you can find elsewhere on the internet.

The reviews mention the friendly environment, curious peers with a breathtakingly wide variety of skills and interests, the fanatical focus on projects that push deeper understanding, and the profound intellectual transformation of the experience.

The advice to new admits, including mine, generally also addresses the structureless nature of the program: there is no curriculum, no set goals, no staff of ‘teachers’ to tell you what to learn each morning. Many people find this daunting, and in many ‘end of batch’ recap blog posts I see people regretting that they didn’t ‘figure out’ how to navigate this until late in the batch and lament the ‘wasted time.’

But the discomfort and the time spent floundering are precisely the point. They are what makes Hacker School so valuable for you, long after you walk out the door on your last day.

In the space between the step-by-step beginner tutorial and your little project that ends up on the top of Hacker News is where you have to find the path for yourself. In the outside world, in your job, in your side project time, in the hours left in your life, who is going to tell you what path to follow and put a curriculum in front of you each day? To make a real difference and push the human race forward, you have to learn to blaze trails into the unknown, pick up new skills quickly, and decide for yourself what to learn next.

Hacker School does this by getting out of your way. They create a hyperbaric chamber for learning by fanatical obsession with the perfect environment. They pick curious and generous peers, hire thoughtful and energetic facilitators, remove extrinsic motivators like interview preparation as much as they can and then they get the hell out of your way.

They let you chart your own course, even if that means a little floundering as the floundering is an essential part of this learning. You are figuring out what excites you. How to balance the lure of the new and shiny with the need to buckle down and polish core skills. How to explore when you have no idea what lies ahead. How to use source code and fellow programmers for help when you don’t understand. And how to tell when you have wrung the last bit of learning and enjoyment out of a project.

Figuring out how to chart this path for yourself is much harder back out in the world where you are faced with distractions and uncurious peers, unhelpful or non-existent mentors, pressure to ship uninteresting code for other people, and bills to pay. A 3-month gap where you can pursue anything that interests you is a breath of fresh air, and in that ideal environment have a very real shot at learning how to learn.

Our Talk at Strata

Last week I attended O’Reilly’s data conference, Strata. I had a great time, including co-presenting with my colleague Max Shron on the topic of Solving the Right Problem.

Based off the material in his book, we argued that it is easy to crunch some numbers and feel like you’re doing data science, but in the end to come up empty-handed since you didn’t pick the right problem in the first place. This is a particular danger since data scientists love data and programming and the latest tools, so it can be very tempting to just dive into the data set without first considering where you’ll end up.

We looked to the design world as a case study for how other disciplines have handled this very same problem, and propose that it’s not enough to be technically and mathematically competent. Effective data scientists must also be skilled at drawing out the actual need from underneath the stated need.

The second half of the talk, where we lay out a framework for structuring scope conversations, was drawn from previous talks Max has given. This iteration of the talk saw two new things. First, I added more justification and urgency around why you should care about doing this well. I imagine that everyone who chose to be in our session already believes this, but chances are extremely good that there are other people in their organization that are skeptical. Hopefully our arguments are portable enough that attendees can persuade their coworkers and managers.

The second thing I added were symptoms of scoping poorly. Just as it’s difficult to see that you’re in the Matrix when you’re in it, it’s difficult to know that you’re bad at scoping when you’re bad at it. The presentation has four red flags so you can spot weak scoping and have the language to address it. The nice thing about these is that once you give them a name, everyone on your team is more likely to spot them and call them out.

O’Reilly is working on the video and we are working on the annotated slides. I’ll update this post when they’re out. In the meantime, please enjoy this totally unrelated visualization of the most popular American names over time:

I spent most of the rest of the conference on the “hallway track” meeting new folks and catching up with colleagues from around the world. The sessions look awesome and I bookmarked a bunch of them to watch later. Literally too many to list right now. Will pare them down the list for the next post.

I’m Switching to Vim

I should really have switched to vim ten years ago when I first started using the command line. But vim has a hell of a hill to get over, and I never made it high enough to keep going. I’m revisiting it because I love keyboard shortcuts! Once they’re in your brain, you hardly have to think to move the whole program around at a blazing speed. Then you get to feel like a wizard.

Starting August 1, I deleted my symlink to subl and went cold turkey. It’s slowed me down pretty significantly, but that’s been a great incentive to set aside time every day to learn new vim stuff, and investing in the tools you use all day every day is always a great investment. I still feel pretty clumsy, but I now find myself editing non-code things in vim! Which is a good sign!

Resources I’m Using

  • I’ve been working my way through Practical Vim, which is great at getting you thinking in the vim way. I suspect this will make me effective much faster than just googling for things as they come up.

  • When I want to look something up on the fly, Google usually points me to the Vim tips wiki, which is encyclopedic for one-off solutions and quick fixes, even if they’re not well contextualized.

  • I’ve been pestering my colleagues, developer friends, and other Hacker School folks for their favorite config and tips and tricks, which has been very fruitful.

ALSO, I bought the domain thedailyvim.com, and am considering setting up a daily tips feed there. Send me a tweet if that’s something you’d be interested in!

HOWTO Force All Django Users to Log Out With the Django ORM

I recently hit a bug with Blaggregator, a Django app I’m running in production on Heroku, and the fix needed each user to log out and then log back in for it to take effect.

So how to log out all users at once? A bunch of threads around the internet suggested deleting the Session table, as that stores all session information for users (that they are logged in, shopping cart info, etc). That’s easy enough with the dbshell, but I’m hitting a weird psql bug on Heroku that I don’t have time to diagnose, and plus, working directly in the dbshell makes me feel icky. So here’s how to force all Django users to log out on your Heroku-backed app using the ORM, which is one layer of abstraction farther from shooting yourself in the foot.

Be careful since this can have adverse effects for your customers (remove items in a shopping cart, etc). It will also confuse and annoy visitors who are currently on your site. There are more graceful ways to accomplish this, but in my case it was quick and effective. I’m not storing anything important in the Session for Blaggregator, and the site has < 1,000 users as it’s constrained by the total size of the Hacker School alumni population. That’s a small enough number that none of them were on the site yesterday early morning when I was deploying. So this was a quick and dirty way to deploy the fix and make sure it was applied.

To get started, fire up the Heroku Django shell:

1
$ heroku run python manage.py shell

When you get the Django shell prompt (>>>), then you can import the Session model. (If you want to go read the code, the module name tells you where to look: django.contrib.sessions.models looks in your virtualenv’s lib/python2.7/site-packages/django/contrib/sessions/ for models.py)

1
>>> from django.contrib.sessions.models import Session

Now, you can iterate through all the Session objects and delete them. (caution!)

1
2
>>> for s in Session.objects.all():
...   s.delete()

Or, as Jacob Kaplan-Moss pointed out, if you delete them straight from that queryset, you not only win at code golf, but the query will be faster due to how Querysets work under the hood:

1
>>> Session.objects.all().delete()

See our Twitter conversation or the Django docs if you want more info on Querysets.

Congradulations! Your site is now very lonely.

The Slacker Developer’s Guide to the Mavericks Upgrade

I am not an early adopter.

Until last week, I was running 10.7. Yes, it’s true. Don’t judge. I had code to ship. No time for yak shaving!

But finally I bit the bullet. After dual redundant spatially-distributed backups, I ran the upgrade. And everything went great at the GUI level! And the Messages app is awesome! But Ruby, virtualenv, and Java were all borked. I don’t even Ruby, but I use Octopress and Heroku, so I couldn’t even blog or restart Hubot. Sadness!

Some tips in your upgrade:

  1. Homebrew links will probably be messed up. brew unlink foo and then brew link foo fixed most of these. Consider scripting it to save time and heartache! E.G. for i in $( brew list ); do brew unlink $i; brew link $i; done

  2. Ruby has a new version, and RVM is now using .ruby_version instead of .rvmrc to keep track of Ruby versions. It automatically moved these files around without telling me, which is half of what broke my blog.

  3. Ruby 2.whatever will complain about Readlines or Yaml or OpenSSL depending on its mood. Try uninstalling Ruby with RVM, installing whatever it demands, and then reinstalling Ruby and seeing if it works. At this point, I’m basically thinking of Ruby as a demanding newborn that is astonishingly articulate about its needs.

  4. Java is gone because reasons. Here’s how to reinstall it.

  5. I’m still not sure what’s going on with my virtualenv but I think it has to do with my questionable decision to use a third-party Python distro. Passing in a path to the system Python with -p seems to be a decent workaround.

  6. A bunch of packages wouldn’t install through pip, and it turns out that the new default when flags are not recognized by gcc is to CATASTROPHICALLY CRASH rather than keep calm and carry on. Don’t have time for this drama? Add the following to your environment:

1
2
export CFLAGS=-Qunused-arguments
export CPPFLAGS=-Qunused-arguments

Back to work!