My First Time Recording Developer Videos (It Was Actually Fun)
TL;DR: Twenty years of engineering and zero videos to show for it. I finally sat down in front of a camera, expected to hate it, and by session three I was having a good time. Scroll down for eleven videos and the honest version of how I got there.
My career so far: two decades of code, a few dozen conference talks, blog posts when I feel like it. But video was this thing I always assumed other people did. Not me.
That changed recently when I started creating product demo videos for Flox. And here’s what surprised me most: it got easier way faster than I expected.
If you’re an engineer who’s thought about making videos but keeps putting it off—this is for you.
Why Did We Choose Video Over Documentation?
Flox makes reproducible development environments easy. Try saying “reproducible development environments” to someone outside our bubble though. Their eyes glaze over. Much easier to just show them.
We wanted product demos that actually show what Flox does—real terminal sessions, real workflows, real problems being solved. Marketing awareness, yes, but grounded in actual engineering work.
The goal wasn’t polished corporate video. It was authentic developer content.
What Makes Recording Developer Videos So Hard?
Let me be honest about what was difficult:
Scripting and flow. You’re staring at a teleprompter trying not to sound like a robot. I rewrote my first script maybe five times before it clicked. The trick that worked for me was imagining a specific colleague sitting across from me. Suddenly the language loosened up.
Multiple takes. Take two. Take five. Take nine. My brain kept screaming “one more, this time perfectly.” Never happened. You just pick the best one and move on.
Keeping energy consistent. Take 1, you’re fresh and excited. Take 7, you sound like you’re reading a grocery list. And then the editor has to cut between take 1 and take 7 without the audience noticing the energy shift.
First time in a real studio. We rented a day at Studio MIS in Warsaw. The room had these big softbox lights and a boom mic that kept catching my eye. My day job is packaging software with Nix. Standing under studio lights felt like showing up to the wrong meeting. My first thought was genuinely “I should not be here.” Joanna Kasprzak-Kajder runs their developer content projects and she could tell I was spiraling. “Just say it again, simpler.” She must have said that to me forty times that first day.
All of this hitting you at once is a lot. Between takes I’d watch the playback and cringe. “That’s my voice? That’s how I gesture?” I mentioned this to a few other engineers later. Every single one said the same thing happened to them.
How Fast Does the Learning Curve Flatten?
Here is what I did not see coming at all. Session two, I caught myself looking forward to going back. Session three, I practically ran into the studio.
That initial cringe factor? It goes away. Went away for me faster than it had any right to, considering what a mess session one was. When I came back for the second recording day, all the studio logistics were already in my head. Teleprompter goes there. Stand on this mark. Leave a gap after each section so Joanna has a clean splice point. Once all that became automatic, I could finally think about the actual content.
Software learning curves work the same way, come to think of it. First time with Nix? You’re googling the syntax for a flake.nix file every thirty seconds. By your third project you’ve forgotten the syntax was ever confusing. Recording video felt the same way, just compressed into days instead of weeks.
I also got faster. The first video took most of a morning. By videos eight, nine, ten, we were doing two or three per session. Not because we were rushing, but because I stopped second-guessing every sentence. Good enough became actually good enough. Perfectionism is the enemy of shipped content, same as it is with shipped code.
Engineers avoid video content because it feels too exposed, too different from our comfort zone of code. But the learning curve is shorter than you think. Way shorter than learning a new programming language. Probably shorter than setting up your first CI pipeline.
What Should Engineers Know Before Recording?
Lessons from my mistakes, mostly.
Write a script, then throw half of it away. Every first draft I wrote could have been a wiki page. Thorough. Comprehensive. Also completely unwatchable. A two-minute demo needs one idea, not a feature overview. If somebody has been watching for 90 seconds without a payoff, they’re gone. I learned to ask myself: can I split this into two shorter videos instead? Usually yes.
Your screen recordings need a story. Don’t just type commands and narrate. Set up a problem first. “Here’s what goes wrong when you don’t pin your dependencies.” Then show the fix. Conflict, resolution. Takes 30 extra seconds of setup and makes the video three times more watchable.
Invest in audio, not video. Grainy video is fine. Echoey audio with background noise? People close the tab before your second sentence. A $50 USB mic in a closet will outperform a fancy camera in an open office. The studio in Warsaw had great lighting but what I noticed most was the silence. Absolute dead air. No HVAC, no traffic, no one typing on the other side of a wall.
Embrace imperfect. Done beats perfect. Every time. Ship something. Learn from it. Make the next one better. This is the same iteration cycle we use in code. Apply it to content.
Get comfortable with your face and voice. Yes, it feels weird to be on camera. Yes, you’ll cringe at your own voice. Everyone does. I still do, a little. Push through it. The discomfort shrinks with practice. By video five I stopped noticing.
Keep it short. Two minutes is plenty for a demo. Our longest video is under four. Joanna had to physically wave me off more than once. I’d start going “oh and one more thing” and she’d shake her head from behind the camera. Annoying in the moment. Correct in the edit.
What Would I Do Differently Next Time?
I’d mix in more screen recordings. Some of the talking-head segments would have worked better as terminal demos where you can actually see what’s happening. I also wish I’d written shorter scripts from the start instead of drafting long ones and trimming.
Batching helped a lot. We stumbled into it because of the studio schedule, but recording three or four videos in one session turned out to be the move. Switching between “engineer brain” and “content brain” costs you something. Once you’re warmed up, stay warm.
And I’d start sooner. I put this off for years. Years. Told myself I wasn’t a “video person.” Told myself the content wouldn’t be good enough. All the usual excuses. Looking back, the only thing between me and eleven published videos was actually booking the studio.
Was It Worth Stepping Outside the Comfort Zone?
Absolutely.
For Flox, obviously, we got the content we needed. But personally? I broke through a wall I’d been staring at for years. Turns out “content creation” is not some special skill reserved for marketing people. Engineers can absolutely do this.
Here they are—all eleven of them:
They’re not perfect. But they exist. And that matters more than perfection.
If you’ve been telling yourself you’ll make developer content “someday,” just go do it. The gear is cheap and the skills come faster than you’d expect. I genuinely think most engineers would enjoy the process if they gave it an honest shot.
Building developer environment tools at Flox. Also the person who started NixCon. I can almost watch my own videos without wincing now. LinkedIn.