The single most common problem I see in developer podcasts has nothing to do with the conversation, which is usually great, it is that somebody shares their screen, starts talking through a function, and the code is completely unreadable for anyone watching on a phone. The editor sitting on the other end of that recording then has a choice, right, either leave it as a blurry rectangle and hope people listen along, or do the actual work of making those twelve lines of code something a viewer can follow, and that choice is basically the whole difference between a developer show people learn from and one they keep in the background while doing something else.
I run Pixel Samy Podcast, a team of human editors in Dubai, and engineering teams and developer advocates have become a very particular kind of client for us, because their shows mix three things most podcasts never do at the same time, a normal conversation, code on screen, and sometimes a live session where someone actually builds something. This post is about how we handle that mix.
What makes a developer podcast different from any other tech show?
The difference is that the viewer often needs to read, not just watch, so the edit has to treat code as content that must be legible and accurate, and a broader tech show can usually get away with a screen share as decoration.
I covered the general side of tech shows, the jargon, the fast talkers and the product demos, in podcast editing for tech shows with screen shares, and I am not going to repeat that here. What changes for a developer audience is the level of scrutiny. Developers will pause the video to read a line, they will notice if a variable name changes between two cuts, and they will leave a comment if the code on screen does not match what the speaker just said. So the edit is closer to editing a tutorial than editing an interview, and our editors work with that in mind from the first pass.
How do you make code readable on screen in a podcast edit?
We crop and scale into the few lines being discussed, hold them long enough to read, and highlight the line the speaker is talking about, so the viewer looks at exactly what matters instead of an entire IDE shrunk to fit.
That sounds simple, and the editing part mostly is, right, but it depends heavily on what you record. A screen capture of a large monitor with a tiny editor font gives us nothing to zoom into, because cropping into small text just makes small blurry text larger, so the best thing a team can do before recording is bump the editor font up well past what feels normal and pick a high contrast theme. Record the screen at the highest resolution your setup allows, and we deliver the episode in 4K on the Studio plan so there is still room to crop without the code turning soft.
For vertical clips the problem is even sharper, because a 9:16 frame holds maybe five or six lines of code at a readable size, so the clip version of a code segment shows only the key lines, often with the speaker's face above it, while the full episode keeps the wider context. In most shows cutaways are footage of something else, and our thinking on choosing them is on the cutaways and B-roll page, but with engineers talking it is usually the code itself doing that job.
Live coding segments, and what to do with the waiting
Live coding is the most honest content a developer show can make, and also the hardest to edit, because so much of it is waiting, a build running, tests crawling through, a package installing, someone reading documentation in silence. Cutting all of that out is tempting, and it is a mistake if it makes the code jump from one state to another without explanation. A viewer who sees a function with three lines and then, after a cut, a function with twenty lines has lost the thread completely.
So our approach is to compress the waiting rather than delete it. Long builds become a few seconds with a small on-screen note that time was skipped, typing that does not teach anything gets sped up, and any moment where the code changes in a meaningful way stays in at normal speed with the explanation attached. Errors stay too, right, and I feel strongly about that, because watching someone read a stack trace and find the bug is often the most useful part of the whole session, and the polished version where everything works the first time teaches nobody anything.
Will the editor get our library names and version numbers wrong?
Not if you send them to us first, because we spell every library, framework, function and version on captions and lower thirds exactly as your team writes them, and we flag anything we were unsure we heard correctly.
Developer vocabulary is brutal for automatic transcription, right, product names that look like ordinary words, acronyms pronounced three different ways, and version numbers that mean very different things depending on one digit. Our editors are not your engineers, so we do not check whether the code is correct or whether a claim about performance holds up, and I would never want an editor quietly fixing something they think is a mistake. What we do is keep a short glossary per show, apply it to every episode, and leave the technical review to you. Our wider approach to subtitles is written up under captions that match what was actually said, and trust me on any level, a wrong library name in a caption costs more credibility with developers than any audio problem ever will.
What happens to API keys and internal URLs that show up on screen?
We blur them, and we treat anything that looks like a credential, a token, an internal hostname or customer data in a terminal as something to hide by default, then tell you exactly where we found it so your team can rotate anything that was exposed in the raw recording.
This happens more often than people expect, right, and usually in the most innocent way. A developer opens a config file to show a setting, and the environment variables are sitting right there, or a terminal history shows the name of an internal service. Engineers are usually careful, but recordings are long and attention drifts, so the second pair of eyes in the edit matters, and for shows that record anything sensitive I would point you to the post on editing recordings that contain confidential material. The honest limit is that we can only blur what is visible in the frame, so the raw files themselves should be stored and shared with the same care as any other internal document.
Developer advocates and the chapters problem
DevRel shows have a different job from internal engineering podcasts, right, even when the same engineers appear on both. An internal show, the kind I wrote about in editing a podcast only your employees will hear, can be long and loose, because the audience already cares. A developer advocate's show is competing for the attention of developers who have a specific question and very little patience, so the structure of the episode matters as much as the cut.
That is why chapters are one of the most useful things we add to these episodes. A developer who only wants the part about authentication or the migration story should be able to jump straight there, and YouTube supports that through video chapters in the description, which we write from the edit itself because the person who cut the episode knows exactly where each topic starts. Show notes with links to the repo, the docs and the tools mentioned do the same job on podcast platforms. If your show sits close to product, the post on editing product management podcasts covers the overlap with roadmap and feature talk.
How should an engineering team budget for a code heavy show?
A code heavy developer show of up to an hour usually belongs on our Studio plan at 299 dollars an episode, because that tier includes 4K delivery and custom graphics, which is what readable code and highlighted lines really need.
A simple conversation show with no screen content can sit on the cheaper Starter tier, and you can see both, plus the pack discounts, in the pricing section. The first cut of a normal episode is back with you two days after upload, and a live coding session that runs well past an hour, or one that needs heavy compression of long builds, may take an extra day, which we tell you before we start. I would quote anything unusual after seeing one raw recording, because a forty minute chat with two code snippets and a ninety minute pairing session are not the same job at all. There is no retainer, so a team can run a season of twelve episodes, pause for a release cycle and come back.
If a developer has to pause your video and squint at the code, the edit has already failed, no matter how good the conversation was.
When your team should not hire us
If your company already has a video person on the developer relations team with time to spare, keep the work in-house, because someone who sits next to the engineers can ask a question about the code in thirty seconds, and that closeness is worth a lot on technical content. If your show is pure audio with no screen content at all, a simpler audio editing service or an automatic tool may be enough, especially for a small internal show. And if you want a highly scripted course with animated diagrams, a dedicated course production team is a better fit than a podcast editor, because that is a different craft.
Where we fit is the regular show with real code on screen, where the engineers are busy shipping and nobody has the hours to crop, highlight, blur and caption every episode properly. If you have ever squinted at a recorded conference talk trying to read the presenter's terminal, you already see where I am going with all of this.
A first episode worth testing with
Pick your most screen heavy episode, the one with live coding or a long walkthrough, and send us the raw recordings with a short glossary of the names that keep coming up. That episode is the hardest test of whether an editor can handle developer content, and it tells you more in one cut than a sample reel ever could. You can book a short call with me or write to samy@pixelsamy.com, and if packaging matters, the episode thumbnail can come from ClickTheory inside the same company. A developer audience forgives a lot, but it does not forgive code it cannot read. So yeah. That's my way of saying it.