A few things I’ve learned about livestreaming

In that order, especially when looking at where to compromise

- Don’t livestream everything like I did. You’ll burn out. But do pick a regular schedule like once a week and stick to it. You’ll eventually get regulars and that’s fun.

- Use a service like Placeit and create video bumps. I had bumps for the intro/exit and for new commits. It adds a lot of fun and energy.

- Stream on Twitch and then publish the recording on YouTube, if you can. Even better if you can publish focused or editing clips on YT. I streamed entirely on YT, which works fine, but the vast majority of viewers were after-the-fact.

- Get used to coding out loud.

- Zoom everything, especially your code, terminal, and dev tools. It’s a rotten way to work but people won’t be able to see otherwise. (Most people aren’t watching full screen.)

- For that matter, most people aren’t watching the full time. They tune in and out. I liked to start the stream with Excalidraw where I would map out the days work.

- Turn on Do Not Disturb and move any sensitive windows to another monitor. I had someone try to send a Twitter reset code with the goal of getting me to show the code on the video.

I had similar problem with delay will in logic which gets fixed by changing the sampling rate, but the real fix is by increasing the buffers in pref.

- Read the chat, at least on and off. It also helps if you have friends who will ping you via an (out of band!) notification if someone says something important. I use both IRC and YouTube chat, and the IRC folks know that if they tag my name there I'll actually get a beep in my headphones and notice.

- Get used to people correcting all your dumb typos and mistakes before you do.

- If you're streaming your work, streaming shouldn't take time off of your work. Make the process as friction-free as possible. I have a script that I launch that sets most of the environment up. Then when I feel like working I just click a couple buttons and send out a tweet and IRC message.

- You'll probably want to have one virtual desktop or two you use for streaming, but make sure there's nothing sensitive on the topmost window of any others in case you switch by accident. I accidentally showed my email inbox once; it was all Asahi stuff anyway on the first page, but it could've not been.

- If you do end up having to trim something out of a recording on YouTube, you can do that with the built in editor tools without changing the video URL. However, you will lose the chat replay.

- Announce ad-hoc streams a few minutes before you actually start anyway. That way you'll get at least a few people listening in from the get go.

- If streaming on YouTube and you suspect your internet or software might act up, use a scheduled stream even if you create it just in time. That allows you to reconnect even after some downtime. Ad hoc streams end automatically a few seconds after you disconnect, and then all your viewers get kicked out and will have to navigate to a new video page.

- If you do use a scheduled stream, don't forget to click "go live". That was a duh moment, I was speaking to nobody for a solid 10 minutes.

- Even if you don't stick to a consistent schedule, schedule some streams when you're planning to do something "interesting". E.g. I scheduled my M1 Pro bring-up and that got a lot more viewers than my usual streams.

- Audio quality matters. A lot. It makes the difference between a coding stream people will leave running even if they aren't watching the screen, and one where they'll get tired quickly. You don't need expensive hardware. Just a decent (vibration isolated!) mic mount and a cheap dynamic mic will do (I paid $3 for mine at a junk shop) - and processing. EQ, gate, compressor, maybe some multiband gating or compression (I use that as a trick to hide fan noise).

- Monitor your own audio, at least initially until you're confident in your set-up. If your latency is low enough, it shouldn't be distracting. I don't bother these days since I know my set-up works, but I do use semi-open headphones so I can still hear myself talking, and do a test at the start of the session.

- It helps if you stream from one PC and code from another. I use an HDMI scaled mirror output into a capture card on the streaming PC. I've had cases where I literally had to reboot, while the stream kept going (though my audio stopped because I run it on the main PC, but that's a practicality of my setup - you probably shouldn't do it like that)

And as I've found out twice already,

- Apparently YouTube's Content ID likes to false positive match keyboard typing noises against other keyboard typing noises (in "songs" that aren't). Dispute them when that happens, and complain loudly on Twitter/HN :-)

> Stream on Twitch and then publish the recording on YouTube, if you can.

I think this is mostly about where you have your audience. I do YT only (because I'm too lazy to separately upload recordings) and I regularly get 30+ live viewers, up to 100 sometimes, which is honestly pretty good for a coding livestream. I have a bunch of regulars and then there's always a bunch of random people.

[1] https://youtube.com/marcan42