Press "Enter" to skip to content

Month: August 2017

How to Record a Programming Screencast

MicrophoneA friend asked me how to create programming screencasts, like the ones I make here. If you want to make your own screencasts, this is how I make them, and the tools I use.

I’m still working on improving the videos I make – both for my presentation skills and for the process of creating them. But, I think this is a good place for you to start figuring out how to make your own programming screencasts.


By the way, this is for recorded (and edited) videos, and not for live-streaming. I don’t think I’m ready to do live-streaming, yet.



Choosing a style for the video

I’ve tried two different styles for videos. First, a recorded “live-stream”, showing me type in the code. Second, me showing the already-written code and explaining it.

Now, I only do the second style.

With the “live-stream” format, it was difficult for me to:

  • Read the list of steps in my lesson plan
  • Type in the code for each step
  • Explain what I was typing, while I was typing
  • Fix my typos (there were many of them)
  • Re-explain (so the audio matched what I re-typed)
  • Edit out all the mistakes.

Eliminating the re-typing and extra editing saved a huge amount of time. But, try both ways and see which fits you best.



My screencast production process

These are the steps I currently use to make a video. I’ve included the amount of time each step normally takes. All these times are for a final video that will be around 15 minutes long.



Step 1: Plan the topic for the screencast

Time to complete: 15 – 30 minutes

Tools needed



For videos that are part of a series (like my C# RPG lessons), this is easy. I already have an outline of the complete series, so I only need to select the next video in the list.

For other types of videos, this usually takes longer.

I select the topic to explain in the video, and try to find the smallest (and simplest) sample code that can demonstrate the topic, while still being somewhat realistic. You want the code to be complete, and cover the topic you’re trying to explain, but you don’t want to spend an extra 30 minutes explaining what the rest of the program is doing.

The video should be long enough to explain the topic, but no longer.



Step 2: Write the source code

Time to complete: 1 – 4 hours

Tools needed

Visual Studio (or, your favorite editor)

Subversion (or, your favorite source control)


Many of my videos are part of a series – the C# RPG series or the Design Patterns series. After each video, I save the latest version of the source code to my repository. That way, just like with any other project, I can always go back to the last working codebase.

When I demonstrate a programming technique, I try to show how the code looks with using the technique, and without using the technique. So, this requires writing the demonstration code twice.

After the code is written, I check it with ReSharper – so I can see if there are any good places for refactoring, and that the source code fits my standards. If you’re going to do multiple videos, it’s good to use the same coding standards.


Tip: If the topic does not require a front-end, it might be faster to write some unit tests, and show how the code works with them.



Step 3: Test that the code works

Time to complete: 15 to 30 minutes

Tools needed

Visual Studio (or, your favorite compiler and test runner)


The first time you forget to do this, and need to completely remake the video (because of something you forgot at the very beginning), will probably be the last time.

I speak from personal experience on this subject. Make sure the demonstration code works, before you press the “record” button.

This is a big reason why I prefer making videos that show pre-written code, instead of writing the code during the video. It’s easy to make a typo, or leave something out, at the beginning of the video. Then, you might need to re-record the whole thing. With the pre-written code, I can do my testing before I start recording.



Step 4: Write the text post for the lesson

Time to complete: 1 to 3 hours

Tools needed

Microsoft Word (or, your favorite word processor)


Before recording the video, I always write the text post that is going to go along with it.

Many people have told me they prefer videos with a related text post. The text version gives them a chance to go over the lesson at their own speed. Plus, they like to copy-paste the source code that was shown in the video.

I don’t use this as a script to read from. That usually makes for a bad video. However, I do use it as an outline, to make sure I cover everything while recording the screencast. There’s more details on this in the next step.

I tried recording the video first, and hiring a transcriptionist to write the text version afterwards. However, that did not save me time (and did cost me money).

It’s also easier for me to rearrange sections in the word processor, instead of the video editor.



Step 5: Record the video

Time to complete: 30 to 45 minutes

Tools needed

Camtasia (or, your favorite screen-recording program, such as OBS)



Before recording

Before I start recording, I go through a checklist. You’ll probably develop your own, with steps that are specific to your environment. But, these are the items on mine:

  1. Turn off air conditioning (to eliminate background noise)
  2. Turn off phone ringer
  3. Turn off alerts on your computer. I solved this by having a separate computer, and only installing the programs I need to write programs and create screencasts. If you have one computer, you might want to use a “virtual machine”, and creating a VM to use for your screencasts.
    1. If you need to turn off any programs, you can go through this list when you are done recording, and turn them all back on.
  4. Open my editor, and ensure the font size is large – to make it easier to read on smaller screens.
  5. Start the screen-recording program, and test the microphone – to ensure it is recording clearly.


During recording

You might want to create a standard beginning and end for your screencasts – an “intro” and an “outro”.

I don’t pre-record these. But, I do have a [mostly] standard outro. At the end of the video, I mention that the video’s description will have a link to a “support page” on my website, with the source code and a good place to leave questions.

Something that has helped me massively is the “pause” key. I’ve even put a piece of green tape above the key that pauses the recording program, so I can always find it quickly.

I used to record the complete video in one continuous recording. That led to many mistakes, and much longer editing times.

My new process is:

  1. Pause the recording program
  2. Read the next paragraph or two from the text post, to myself
  3. Think about what I want to say, and what code needs to be highlighted
  4. Un-pause the recording program
  5. Record the small section I just planned
  6. Go back to step 1, for the next paragraph or two

This is what works best for me – so far.

I don’t need to memorize everything I need to do for the complete video (which usually ends up with me forgetting something). If I make a mistake, or think I can do that section better, it also means that I only need to re-record a small section.

And, by making less mistakes, the editing time is much shorter.


Other than that, just try to stay relaxed. If you make a big mistake, or really need to re-think a section, you can pause recording for as much time as you want.



Step 6: Edit the video

Time to complete: 45 to 60 minutes

Tools needed

Camtasia (or, your favorite screen-recording program)

Audacity (if you want to do more audio editing)


At the beginning of each video, I add an introduction image. It’s a standard one I created, and it displays the title of the video. I only display it for five seconds, and I don’t have any introduction music. That’s my preference, and you might want to do it differently. But, you probably want to keep the introduction short. If it’s too long, people start to complain.


After adding the intro, I start to clean up the video.

1. Apply audio cleanup

With Camtasia, I select the recorded track, choose “Audio Effects” from the menu, and apply “Noise Removal” and “Volume Leveling”.

The Volume Leveling tries to make the audio the same volume, through the complete video. However, when Camtasia does this, it normally sets the volume to a very low level.

So, I set the Volume Leveling to Custom, and adjust the level so the volume is higher. See the images below, to see what a “low” level and a “high” level look like.


Default "low" volume level
Default “low” volume level
Custom Volume Leveling settings
Custom Volume Leveling settings
"High" audio level, with custom settings
“High” audio level, with custom settings



2. Focus on the relevant parts of the screen

I usually don’t need to display the complete screen. Only part of it is relevant to the screencast.

For most of the videos I make, that’s the file editor section of Visual Studio. So, I use the “Animations” menu in Camtasia to Zoom-n-Pan, to zoom in on that part of the screen. It makes the text larger, and easier to read.

Try not to zoom-n-pan to many times. You don’t want your viewers to get dizzy.

I also highlight the lines of code by either selecting it in Visual Studio (which changes the background color of the selected region), or using the “Sketch Motion” feature to draw a red box around the part of the screen to highlight.


3. Delete mistakes and empty space

I usually need to remove a lot of mistakes, and reduce long pauses to shorter pauses. The better you get at recoding the screencast, the less editing you’ll need to do.

You might also trim some of the “dead space” – sections of the video where you don’t talk for several seconds. When you’re editing, listen to the recording as if you were one of your viewers. If any of the pauses seem too long, remove part of them, to make a shorter pause.


4. Don’t be afraid to re-record a section

I’ve had some sections that I have needed to completely re-record. Plus, there have been a couple of times when I just needed to record some new audio over a section, because I forgot to explain something.

Camtasia has a “Voice Narration” feature you can use while editing. It lets you record new audio. Then, you can cut out the original audio from your video, and replace it with the new audio.



NOTE: It’s important to have clean audio. You’ll want to remove background noise and “level” the audio.

If you upload your videos to YouTube, be aware that they may edit the video – days or weeks after it’s been uploaded. I’ve had several videos where the volume was significantly decreased, long after I uploaded the video.

And, there is no way for you to increase the volume, after the video was uploaded. All you can do is re-upload it (as a new video) and delete the original one – losing all your comments/likes/dislikes/etc.

From what I’ve seen, YouTube will run a “loudness” filter on videos. I believe this is an attempt to keep the volume of the video relatively constant. By using the “Volume Leveling” feature in Camtasia, I can make the volume consistent, before I upload it.

Hopefully, this will prevent problems with having the volume changed by YouTube.

If you aren’t using Camtasia, your editing tool will probably have its own audio-leveling feature. Or, you can export the audio, clean it up in Audacity, and re-import it into your video-editing program.



Step 7: Upload the video and lesson

Time to complete: 30 minutes

Tools needed

Your favorite browser, and video hosting website


Now that the video is edited, it’s time to upload it.

I output the video from Camtasia as an MP4, and manually upload that file to YouTube. Camtasia can upload videos directly to your YouTube channel. However, I have two channels, and don’t want to switch between them every time I want to upload a video for the other channel. Plus, I like to save a copy of the MP4 on my backup drive.


For YouTube, I like to upload the video as a “private” video first. In fact, that is the default setting for my uploads. This way, I can wait to publicly publish it until I’ve finished all the steps below.


For a typical code demonstration screencast, I do these steps:

  1. Upload the source code to GitHub (for my open-source projects)
  2. Post the text version for the screencast on my website
  3. Embed the video in the text version. Once the video is uploaded to YouTube, you’ll have a link to it – even if it is not publicly-visible yet. Then, I embed the video using a small WordPress plugin I wrote (available here, for free use).
  4. Add tags to the video, for the topics it covers
  5. Add the video to my relevant YouTube playlist(s)


Then, I’m finally ready to make the video public.

When I publish the video, I usually tweet a link about it. If you’re more serious about social media than I am, you might want to make a checklist of the different places where you want to notify your viewers about the new video.


Video recording and editing summary

If you add all those times together, you’ll see that each 15-minute video takes me around 4.25 to 10.25 hours to make.

That is longer than I would like, but it’s less than when I first started. Partly because practice makes you better at doing them, and partly because I occasionally look for ways to improve the process.



Setting up my recording “studio”

I have a small computer desk area in my apartment that I use as my “studio”. Unfortunately, the desk, cabinets, and shelves are built-in. So, I couldn’t setup the equipment exactly how I’d like to. But, with a little work, everything works “good enough”.

If you have the room, and the budget, having multiple monitors is extremely helpful. I record on one monitor, while displaying my “script” on a second monitor.


The setup I use for my screencast computer


Your recording studio should be as quiet as possible. To do this, you need to consider three things:

  1. Sound from outside
  2. Sound from inside
  3. Sound reflections inside


Sounds from outside

My computer area doesn’t have a door, which would help reduce outside sounds from the rest of my apartment building, So, I hung thick curtains over the doorway. That seems to help cut down on random outside noises.

When I record, I don’t wear headphones. That way, I can hear if one of my neighbors starts walking down the hallway – and I can pause the recording until they go past.

As I mentioned in the Step 5 (above), I also eliminate outside sounds by turning off my air conditioner before recording.

If you have other machines that might make noises during your recording, I suggest writing down a list of them. Use it to know what to turn off before you start recording, and turn back on, when you are done.

Keep the list near your computer, in case something interrupts you during a recording.

If you’re in an apartment, you’ll need to discover the best time to record. There are probably many normal noises that you don’t pay attention to. But, now that you want a quiet time to record, you’ll notice all those noises.


Sounds from inside

The loudest things in your studio will probably be the fans inside your computer. To eliminate this problem, I built a silent PC. It has silent fans, and an insulated case.

The parts I used for this computer are listed here: Silent Development PC. This computer is so quiet, I have it on the desk, around one yard (one meter) from the microphone. I also have a quiet keyboard, in case I need to type during a video.

NOTE: The PC I built does not have a video card. Because I’m using it for programming, I only need the graphics built into the motherboard. If you want to record gaming videos, and you get a powerful video card (with lots of extra fans), you’ll need to make sure your computer is far from your microphone – or well-insulated.


Sound reflections

To have the best quality sound, you also want to reduce the echoes in your studio. To do this, you want to cover “hard” surfaces (wood, tile, concrete, etc.) with something “soft”, which will block some of the echoing.

I bought rugs to put on my wood floor and desk. I also bought a package of acoustic tiles, and stuck them to the wall with double-sided tape. I also wrapped one of the acoustic tiles around the microphone, to help block keyboard noise – since the microphone is directly above my keyboard when I’m recording.

If you don’t want to get acoustic tiles, you can mount a curtain rod on the wall and hang a thick blanket over it. That’s a simple way to reduce the echoes.


The recording equipment

When I first started making videos, I didn’t want to spend too much money.

I spent around $100 for a CAD U37 USB microphone, boom arm (to position the microphone), and pop filter (to eliminate “popping” sounds, when you say the letters “b” and “p”).

To record and edit the screencasts, I spent a little more money – $200 on Camtasia. From watching many programming screencasts, I realized the importance of good video and audio editing. So, I went with a more-professional recording program.


After two years of making screencasts, I decided to upgrade the equipment.

I bought the Rode Podcaster microphone, with the Rode boom arm and shock mount, and noticed a dramatic improvement in the quality of the audio recording. Not that the CAD U37 was bad. It’s a good microphone. But, the Rode microphone had almost no background noise. So, my screencasts didn’t need as much noise filtering as they used to – making my voice sound a little more natural.



As a programmer, you will probably never need to record a screencast. But, it can help in your career.

Nowadays, when I’m interviewing for a new project, my videos are a good way to demonstrate my knowledge to potential clients. Plus, it helps you stand out from the other candidates. Unless you have a specialized skill, your resume (c.v.) probably looks like most other programmers. It can greatly help you to have something “unique”, that the interviewers will remember.

If you have something to share, a screencast can be a great method to do that.

Even if you aren’t great at them when you start (I’ve been doing them for three years, and still need to improve – a lot), it is a way to improve your communication skills. And that’s something many of us programmers need to work on.