What Nobody Tells You About Streaming Your Code Live

I've been streaming code live every week for six months. 26 sessions, roughly 70 hours of live content, somewhere around 400 individual viewers across Twitch and YouTube Live.

Most of what I've read about live coding streams focuses on the technical setup — the mic, the camera, the OBS configuration. That stuff matters, but it's not the hard part. Here's what nobody told me before I started.

Since people always ask: I use a Blue Yeti mic, a Logitech C920 webcam, and OBS Studio. My IDE is VS Code with a high-contrast theme that reads well on stream. I stream at 1080p/30fps, which is enough for code to be legible without destroying my upload bandwidth.

The one thing I'd change: I should have bought a proper key light earlier. For the first three months I was streaming with overhead room lighting that made me look like I was being interrogated. A $60 key light fixed this immediately.

That's the setup. Now the stuff that actually matters.

When you go live for the first time, something happens psychologically. You become aware that people are watching, and you start performing. You narrate everything. You explain decisions before you've made them. You avoid the long silences where you're actually thinking.

This is the wrong instinct. The people who watch live coding streams are not watching for a polished presentation. They're watching because they want to see real problem-solving, including the parts where you don't know what to do yet.

My best streams are the ones where I get genuinely stuck on something and work through it in real time. The chat engages more. The session feels more alive. The viewers who stick around for those moments are the ones who come back. I wrote about why this kind of transparency matters beyond just streaming in Why I Build in Public.

It took me about six sessions to stop performing and start just working. The transition is uncomfortable — it feels like you're being boring. You're not. You're being real, which is harder to find.

In 26 streams, I've had:

• OBS crash mid-stream: 3 times
• Audio desync (my voice out of sync with screen): 4 times
• Accidentally shared the wrong window (once showing my email inbox): 1 time
• Internet dropout: 2 times
• VS Code extension causing a freeze: too many to count

None of these killed a stream. The audience is remarkably forgiving of technical problems, especially if you acknowledge them and keep going. The worst thing you can do is stop the stream to fix something. Just keep going. Fix it between sessions.

The one exception: if your audio is broken, end the stream. Nobody will watch a silent stream for long, and the VOD will be useless.

This is the part nobody talks about.

Streaming code live means being watched while you're in a cognitively demanding state. Debugging requires focus. Designing architecture requires focus. Having 50 people watching you while you're trying to focus is genuinely hard.

I've had sessions where I couldn't solve a problem I would have solved in 20 minutes alone, because the awareness of being watched was fragmenting my concentration. I've also had sessions where the chat helped me solve something in 10 minutes that I'd been stuck on for days.

The difference, I've found, is whether I'm treating the audience as a distraction or as a resource. When I'm trying to solve a problem privately while also streaming, I'm doing two things badly. When I'm solving a problem with the audience — narrating my thinking, asking for input, treating the chat as a distributed debugging partner — I'm doing one thing well.

The reframe that helped me: the stream is not a window into my work. The stream is the work. The audience is part of the process.

The chat in a live coding stream is different from regular streaming chat. My viewers are mostly developers. They've shipped things. They have opinions.

The chat has:

• Caught bugs I was about to introduce
• Suggested libraries I didn't know existed
• Talked me out of bad architectural decisions
• Explained error messages I was misreading
• Told me when I was overcomplicating something

It's also:

• Confidently wrong sometimes
• Occasionally distracting at critical moments
• Full of people who want to debate tabs vs. spaces

The skill is learning to absorb the chat without being controlled by it. I read everything. I respond to maybe 20% of it. I act on maybe 5% of it. The rest is ambient signal — useful for mood and engagement, not for decision-making.

Here's the thing about live coding streams that took me a while to understand: the value isn't in the live audience. It's in the archive.

My live sessions average 40–60 concurrent viewers. But the VODs get watched for months afterward. Someone finds a stream from three months ago where I was debugging a specific React Native issue, and it's exactly the problem they're having. They watch the whole thing. They subscribe. They come to the next live session. This archive effect is also a big part of how the channel grew to 12K without paid ads — the live audience is small, but the cumulative VOD audience compounds.

The live stream is the event. The VOD is the asset. I treat every session as if I'm creating a document of how I solved a specific set of problems, because that's what it becomes.

If you're building something and you're considering streaming it: yes, do it. But go in with the right expectations.

You will not have a big audience immediately. You will have technical problems. You will have sessions where nobody shows up. You will feel like you're talking to yourself.

Do it anyway. The discipline of showing up weekly, the feedback loop from the chat, the archive of your decision-making — these compound over time in ways that are hard to see at the beginning.

Six months in, the stream is the best thing I've done for this project. Not because of the viewer numbers. Because of what it's forced me to do: show up, think out loud, and be honest about what I don't know. If you want the broader picture of what six months of this actually produced — the audience, the community, the waitlist — that post covers it. And if you're thinking about how streaming fits into a community-building strategy, How to Build a Community Before You Have a Product is the companion piece.

The next stream is Thursday. Subscribe on YouTube or follow on Twitch to get notified. Or check the streams page for the schedule.