Have you ever tried to give a programming lesson on stage in front of 300 people? What could go wrong, right?
I gave a talk at the HOW Interactive Design Conference in Chicago in October. The talk was titled “Data Visualization: From Data to Design to Deployment” (you can see the talk here) and was meant to give some background about why data visualization is so important to today’s communicator, a bit of instruction about how to think about designing with data and then a hands-on example.
If you’ve ever given any sort of technology demo in your life, you know the first rule is that whatever can go wrong will go wrong. Technology will always fail you. And you have to assume you will be dancing on hot coals at some point during your demo.
So I was a bit nervous because my plan was to actually do some programming on stage. I’m not very smart, I guess. And the scene was well set because right before I went out, the host reminded everyone that they had free drink tickets in their materials for that night’s happy hour event. This was nice because it gave me the perfect lead-in joke – I said I hoped that it was a coincidence that she announced the drinks…I was hoping my programming tutorial to a room full of mostly designers wouldn’t lead people to drink!
Anyway, long story short, it was a miracle in that when I did the programming exercise on stage, it worked! Every single time I had practiced the talk prior to this event, it had failed me. But on stage, at the key moment – that first browser refresh after doing a little coding – it worked perfectly.
But there was one dancing on coals moment when I was showing one feature in the code and was making a few changes and did manage to break things completely. Watching the video of the talk, you can’t tell how completely freaked out I was the moment it happened – but I was screaming inside, certain that I would be sweating and searching in vain for a fix for a painful minute or two while the audience squirmed (and maybe heckled.)
And this reminds me of a few important lessons I’ve learned over the years as a developer:
- The worse of a developer you are (I’m self-taught and would never be accused of being a “great” developer!), the better you probably are at debugging. I’ve had a LOT of practice debugging bad code (my own!), which serves me very well.
- Never panic. Code is finicky and one tiny mistake can break an entire program. But if you know your environment and the types of ways you can break things (which are legion!), you can usually quickly spot what you’ve done and fix it before you lose your mind.
- Sometimes you lose your mind. And you can bang your head on very thick walls for a very long time before fixing things. Just like you should save your files every X edits to avoid losing your work, I strongly recommend saving and testing your code frequently. The fewer changes you’ve made, the easier it is to see a problem each time one crops up. I save and refresh my browser constantly to make sure things haven’t broken. And because I had only changed a few lines of code on stage, I was able to quickly see my mistake and fix it without needing to curl up into a fetal position in shame in front of 300 people.
- Practice really makes perfect. Every time I practiced and broke my code led me to recognize failure points and I guess I eliminated them all just in time before going on stage.
- Never do live programming without a Plan B and C and… This applies to any technology demo, really. I had a second set of code ready to go in case I broke everything. I could have switched to another browser tab and shown that code and just explained it if everything had gone wrong. I also had a local version running on my machine in case the Internet went out. I even had a screenshot, in case I really F*#%’d everything up! (Can you tell I’ve done this type of thing before?)
Live demos are dangerous. But in that danger can be fun. I don’t think I led my audience to drink that night. Now I on the other hand…