This week I attended the SF Developer Relations meetup where the topic was Streaming/Live Coding for Developer Relations. This blog post is a short recap, notes and pictures from the event. Thank you to Courier for proving space, food, drinks and Nicolas Grenié for organizing the event.
The meetup started with Nicki Stone, Technical Evangelist from AWS and Matt Auerbach, Developer Advocate from Twitch sharing their experiences and best practices on streaming and live coding using Twitch. In the second talk, Potch, Developer Evangelist from Glide shared his experience with live coding.
Live coding is relatively new on Twitch new but there is a very vibrant community of live coders. Some folks are big fans of live coding and watch live coding events all the time.
Here are the main benefits of live coding on Twitch:
- Education for everyone. Mutual learning for hosts and viewers
- Pair Programming
- Junior developers can learn fast from more experienced developers
- Interactive, the instructor and viewers can ask questions live
Next Nicki and Matt shared tips and best practices on live coding on Twitch.
Pick two topics
If you never done something live, try to do it once before you go live. In other words, practice. People don’t want to see someone who is completely new to a technology. At the same time, no one wants to see someone who looks and sounds robotic. Middle ground is best.
Make sure you explain what you are doing to your viewers and sync up regularly. Being an online event (vs. in-person), you don’t see the people and it is sometimes difficult to gauge if people are understanding or falling behind. This is definitely a great advice. We use a similar approach with our online meetups. We like to go slow, show easy to follow steps, one step at a time.
Use tools people love
Use VS Code, people love it and there are extensions for integrating with Twitch chat.
Hide sensitive information
Make sure you don’t show credentials such as passwords, tokens or API keys. Make sure you invalidate or delete any such information if shown.
Use your audience
Use your audience, get them to help you find bugs and ask interesting questions.
Have no hear, jump in. You don’t have to be perfect, we are all human. It’s important to have fun.
They also shared their favorite software, hardware and stream kits for streaming:
The key is to stay true to who you are:
Mistakes will happen but they are a great learning experience.
They also shared some that one of the most popular times to stream is Saturday 10pm. And the least popular time to stream is Sunday 8am.
When you start, just use the equipment that you have such as your computer built-in camera. Audience will grow slowly and that’s OK. Potch has been streaming for six months, he has a small but growing audience.
What Potch likes about live coding is that it’s very interactive, other people can review the code which is very helpful.
Potch shared that it’s important to have a plan and know what you are going to stream. It’s also important to promote the live coding event. The planning and promotion go together. If you don’t plan an event ahead of time, it will be difficult to promote it. Planning ahead also allows to get interesting guests on the show.
One challenge is justifying a live coding event to the company. Let’s say you stream for two hours plus all the preparation. Is that a good use of your time? This was discussed during the Q&A. Another way to justify is that you can reach a lot more people with an online event than with an in-person event. People can join from anywhere in the world and also watch a recording later. I shared two blog posts on this topic before: Using online meetups to scale your Developer Relations program and Scaling Developer Relations with an online conference for developers.
Potch is about to start season 3. He is planning to make his live coding events even more interactive and come up with even better Glitch/Twitch integration. He will publish a schedule and start promoting. He is also looking to acquire better hardware for streaming. You can catch him live coding at http://twitch.tv/potch.
At the end of the talks there was a short Q&A.
One challenge they all shared is how to measure success. For example, collecting analytics is not easy as most folks who join are anonymous. They said it’s as hard as measuring success of a conference talk. One option is to do a swag give away at the end of the show (this way you can collect some information). Or, asking the audience to rate the stream (such as from 1 to 5).
The January SF Developer Relations meetup was on how to measure success. You can read my recap: How to measure Developer Relations – DevRel meetup recap. I also published Measuring success in Developer Relations – a 3-part framework.
I enjoyed the meetup. Thank you to Nicki, Matt and Potch for sharing their experiences. I’m looking forward to the next event.