Who is afraid of Live Coding?
I was. Here are some tips that helped 👩💻
Yesterday, a friend asked for advice on Twitter:
This topic actually comes up a lot during conferences —fellow speakers and developers who I talk to ask questions like: Where do you get the courage from? What if it fails and you don’t know why? What if someone asks a question and you don’t know the answer? How do you decide what to show?
Answers ahead…
Why Live Coding?
Before we jump into the How, a few words about the Why. I will start with saying that the well-known PowerPoint’n’clicker format (with either bullets, funny GIFs or inspiring stock photograph) works well. You can definitely stick to it. Live coding can, if done right, spice up your talk. It can add excitement, that moment when you press the “Run” button and wait for something to happen. See how the audience reacts when a live-coded demo works:
Speaking about the audience, Live Coding also gives you an opportunity to keep the audience more engaged. You can ask them how to name certain functions, which data to input when testing the code, which font or color to use, and even turn it into a little conversation with the audience:
On top of all, Live Coding can provide the audience a different kind of experience, which can be very refreshing during a day full of tech-talks. Remember — learning is much more effective when done in an interactive, fun way!
Prepare, Minimize Risks
Practice your talk before going on-stage. Time each live-coding section, and cut out things that consume long time: waiting for npm install or for Webpack to start while staring at the screen together with the audience feels awkward. Either do these things before the talk, or if you have a good reason to do them on stage, make sure you have something to talk about while waiting for these lengthy operations to complete.
Similarly, don’t let the audience stare at you while you are typing long lines of code. If you have more than one line or two at a time, prepare code snippets. Actually, prepare snippets in any way — they will be useful if something doesn’t work, you have a typo and you can’t spot it.
Make sure you have the final, working version of the code available. This can be helpful if something doesn’t work (e.g. React just pushed a new release that broke your demo), and it is totally okay to use it — after all, the purpose of the talk is to teach the audience, and even if the demo doesn’t work at all, they can still learn from building it (and hopefully also from your mistakes).
Be Honest, Set Expectations
In a perfect world, we’d come up on stage totally prepared, write some code, and it will work perfectly without any mistakes. This is not how things usually work in the real world, and I always try to convey this message. I learned this from Shai Reznik — when on stage, talk about your fears. Are you afraid of making mistakes? do you have fear of the demo failing for an unknown reason? bring it up. Set the expectations — so even if everything fails, the audience will appreciate the fact that you tried, and that they still learnt something.
When I go on stage, I never know what is going to happen. I do know, however, I will do my best to enjoy it, to learn out of it, and provide the audience a unique experience. And sometimes, my demos fail miserably, as it happened to me multiple times in the NgAtlanta talk I linked above, or in the following one:
We are doing this together!
When on-stage, the level of stress is usually higher than usual, so you are more likely to forget things or do stupid mistakes. Luckily, you have one huge advantage over coding at home: you have an audience full of developers, some of them are probably smarter than you, and with 100’s of eyes looking at the code, is it very likely that someone from the audience will spot mistakes and help you troubleshoot.
This comes back to setting the expectations — if you want the audience to help you, just ask. I usually tell the audience: “We are doing this together. If you spot any mistake, do let me know”. And it works, every time:
Remember, the audience is here to learn. Not to judge you. They will learn from your mistakes. And it will make them feel a little better, knowing that even seasoned speakers make mistakes. And silly ones. 😉
How much live coding should I do?
As you might have guessed, the answer here is “It depends”. You can deliver a great presentation with no live-coding at all, and you can do only live coding. There is no formula. Instead, ask yourself — what is the key takeaway I want people to go home with? What is the best way to present it?
If this is your first time writing code on stage, I’d go with a short demo. In any case, the examples should be short and to the point, as you want the audience to be able to follow through. Ask yourself what are the two or three most important lines of code you want to focus on. Sure, you can present them in a screen shot — that’d work, but if you live code them, they are shown in their natural context, and the audience also gets to see how you approach solving problems, and perhaps (hopefully) even make some silly mistakes.
Most importantly: Have Fun!
It is easy to get overwhelmed by the stress and amount of things you have to remember in order to make a live-coding demo work perfectly. In fact, before my ngVikings “Hot or Not” talk, I was so stressed out that I started to feel dizzy and almost passed out. Thankfully, though, Tracy Lee | ladyleet was around, handed me a bottle of water, and helped me to relax. As I learned from friends who do public speaking, stressing out before (and sometimes during a talk) is very common, even among seasoned speakers.
I hope that some of the advice in this post will help you relieve the stress and approach this is a more easy-going way. For me, presenting on stage is all about having fun, and sharing the passion I have for technology with others. See you soon, live-coding on stage!
This is my second post in my personal Postober challenge, where I try to write a new blog post every day during October.
I will tweet whenever I publish a new post, promise! ✍
