At this year’s eurucamp I gave a talk about how to create a game with Ruby. I wanted to prove that it’s easy to do so with Gosu, so I did a daring thing: I proposed a live coding talk. My first live coding talk ever(!).

It went smoothly, so now I feel almost qualified to give some advice to other people preparing theirs:

  1. Typos are okay. We all make them. If you asked ten Ruby devs to type initialize ten times in a row, I’d guess you’d see at least ten typos. Probably more. Nobody gets this word right. And it’s okay – while you quietly fix your typos, the audience will read your code and follow what you’re doing.
  2. No experiments with your setup. Your live coding talk is not the ideal opportunity to try out a new editor. Use what you know. Don’t try to impress anybody with a fancy new plugin that you haven’t used before.
  3. If there’s some mistakes you always make in rehearsals, don’t just ignore them and hope they won’t happen on stage. Because chances are they will. Instead, think about if you can do something about it.
  4. For example, since I use an American keyboard layout but my MacBook has a German one, whenever I work without an external keyboard I get confused by y and z. This is especially annoying when working with coordinates.So, in order to avoid these mistakes, I actually scotchtaped the “correct” characters on my keyboard. Which made my keyboard look stupid, but prevented me from looking stupid on stage.
  5. If there’s something in the code that you never get right when you do it live, don’t be afraid to copy & paste it. Or have it prepared and commented out. It’s okay.
  6. The nightmare of everybody livecoding on a stage of course is when there’s an error and you have no idea what’s wrong. You’re staring at the code and just don’t see what’s wrong. Don’t be afraid to ask the audience for help. Chances are somebody already spotted it. Actually, it adds some interaction with your audience to your talk and might make people look up from their smartphones.
  7. When preparing the live coding, keep in mind that you’re probably going to be a little nervous in the first three minutes. I made sure that I knew my first three minutes perfectly, and that I was going to start with really easy stuff. It makes it easier to move on to more complicated stuff with confidence.
  8. Set up your terminal and editor to be readable in advance. Usually this means switching to a light color scheme and hitting Cmd + several times. Fiddling with text size and stuff while on stage is tedious and it doesn’t add any value to your talk. Two technical details:

Keynote & Editor

  • To switch between your slides and your editor smoothly, open up the editor, then play your presentation. When you now hit H , Keynote will be hidden and the last app used – your editor – will be displayed. Another essential keyboard shortcut: Cmd+F1 switches between mirroring your display and using two screens.
  • Instead of switching to the terminal just to, for example, run the same ruby program over and over again, use your editor’s Build command – Cmd + B. (Somebody told me after my talk – thanks for the hint!) The TL;DR version in ALLCAPS:
  1. TYPOS ARE OKAY.
  2. KNOW YOUR SETUP.
  3. TRY TO FIND A WAY TO AVOID YOUR MOST COMMON MISTAKES.
  4. COPY & PASTE IS OKAY.
  5. ASK THE AUDIENCE FOR HELP.
  6. KEEP THE FIRST 3 MINUTES SIMPLE.
  7. SETUP YOUR ENVIRONMENT IN ADVANCE.

Oh, and then, of course, there’s the secret to being able to do almost anything: practice. Practice alone. Practice in front of an audience. Practice with people who give you helpful feedback.