Hello friends! As some of you may know, I've been livecoding at least once a week for several years now. (My Twitch is here if you want to tune in. Right now I'm working on a open source conversational assistant that will quiz you on your dialect & guess where you're from. 👀)
In the past couple weeks I've had a number of interested or new livecoders reach out to me for tips. Because I started to repeat myself I figured I'd follow the David Robinson school of advice giving and write a blog post. 😁
Livecoding is different from a lot of other types of content production, like blogging. Think of it like a radio show: people want to know what time to tune in and, if they're big fans, they may even sechdule things around it. (I'll sometimes move my lunch around a bit so I can watch streams I especially enjoy while I eat.)
With that in mind, try to find a frequency and duration that's sustainable for you and stick with it. If you do change your sechdule, make sure to communicate that to your viewers early and often.
You will make silly mistakes on stream. That's ok. No one writes bug-free code and that's especially true when your attention is divided by checking in with the chat and talking through what you're doing.
What's more important than avoiding mistakes is showing how to correct them and talking through your process as you do this. One of the most challenging parts of livecoding, I've found, is clearly communicating the different possibilities you're considering when you're trying to figure out what went wrong.
If it helps, think about it like a coding interview. People aren't necessarily tuning in to see you do things perfectly the first time. They want to see how your work and share in your struggles & successes. (I've also found that folks who tune in to my streams are very helpful with suggesting different approaches!)
It generally takes me 3 to 5 times longer to livecode something than to code it on my own. For a one hour stream I'll try to pick something I think I could do in 20 minutes or so on my own. Ideally, I want to start out with a concrete goal (like "I want to export a set label encoders") that I have a good chance of achieving in the given time. That way I'm more likely to end my stream with a satisfying conclusion.
On that same theme, I recommend having stream titles like "My Project: Updating Foo to version 16.0.2" instead of "My Project Part 150" to give folks a better idea of what you'll be doing.
Because it's live, you're likely to have people dropping in and out. You'll need to situate new viewers fairly often so I end up intentionally repeating what I'm doing and the problem I'm currently working much more often than I would otherwise.
A good rule of thumb is to include a quick summary every ten to fifteen minutes or whenever you're waiting for something to load, train, compile or install. Some folks instead prefer to have a card on the screen that summarizes the current project but I find I don't want to sacrifice any precious, precious screen real estate.
Streaming is rough on the voice and staying hydrated is very important for maintaining vocal health. Ideally you want to drink enough that you avoid ever feeling thirsty while streaming, since by the time you feel thirsty you're already dehydrated. In a one hour stream I usually go through a 12 oz glass of water with electrolytes & a 12 oz cup of coffee or tea--but I do try not to chug them right at the beginning of the hour. (Just in case: it's a good idea to have a "BRB" scene set up you can switch to if you need to take a quick break.)
This isn't an exhaustive list, but these are some of the tips I wish I'd known when I started live coding. Hopefully you find them equally helpful & I'll see you on stream! 😎
And for reading to the end, have a bonus tip: you could always zoom in a little more. More than a third of Twitch viewers are on mobile and I guarantee there's some text they're having a hard time seeing somewhere on your screen.