Podcasting is having a moment.

As of 2019, about one quarter of all Americans listen to podcasts each month. And they listen a lot. About 20 episodes per month.

As a result, a lot more people are investing their time and energy in producing podcasts. Now even billionaires like Reid Hoffman are creating podcasts.

Podcasts have become a powerful medium for sharing stories, conducting interviews, and helping people learn on the go.

And Apple even released a major upgrade to their podcast analytics — the biggest change to the podcasting ecosystem in a decade.

A screenshot of freeCodeCamp’s data on Apple’s beta Podcast Analytics tool. These data only cover listeners who have iOS 11 installed on their phones, but they’ll become more useful as more people upgrade.

How I decided whether podcasting was a good fit for the freeCodeCamp community

freeCodeCamp is a global community of software developers and developers-in-training.

Millions of people visit freecodecamp.org each month — mostly on their laptops. I wanted a way to help them learn more about programming and technology on their phones.

Well, coding on your phone is hard. And people are often too busy doing things like commuting or exercising to look at their phones, anyway. But with podcasting, they could learn purely through listening — without needing to look at a screen.

A Venn Diagram from Jeff Meyerson’s article on why if you like blogging, you should try podcasting.

As an added bonus, you can download podcasts. So they’re an ideal way to learn when you’re on an airplane or on the subway, and don’t have internet access.

So after encouragement from several friends — including Software Engineering Daily host Jeff Meyerson — I finally decided to create a podcast.

I love listening to audio books — especially when the original author reads their work. So I decided to go with a format I call the “mini audiobook.”

We already had articles by hundreds of contributors to draw from. So I reached out to the authors of these personal narratives. I asked them if they’d be interested in taking these lessons they’ve learned from working in tech and sharing them with a broader audience.

The result is short, 10-minute podcast episodes that are jam-packed with wit and insight.

Since these are highly-binge-able, I decided to publish the first 6 episodes all at once. And I’ve published one episode each Monday every week since.

How I learned how to do all this

So now I have a little experience at producing a podcast. I’m excited to share how I’ve been recording and editing these.

My hope is that more people within the developer community will publish podcasts. There’s so much to talk about, and still relatively few developers who podcast.

I started by reading Code Newbie podcast host Saron Yitbarek’s comprehensive podcasting guide.

Edaena Salinas hosts the The Women in Tech Show, and she coached me extensively. She recommended I get the following hardware:

I got a one-week trial of Amazon Prime and ordered these. They arrived two days later, and I started recording.

I tried using the software tools that come free with MacOS: Quicktime for recording and Garage Band for editing. But I quickly discovered that Audacity — a free open source sound editor — was much better suited for both tasks.

Note that The freeCodeCamp Podcast is quite minimalistic compared to most podcasts. It’s a single person reading an article they wrote, and talking about it. There are no ads, intros, or outros.

Since we don’t use an interview or group discussion format, there’s only one microphone to manage. We don’t have to worry about things like differences in volume levels between mics, background noises, and bad Skype session audio quality. So if you’re using this as a guide for your own podcast and doing a multi-microphone format, your milage may vary.

Step #1: Recording

I find a quiet room after my kids are in bed, then start recording.

The main thing I’ve learned about recording is this: if I butcher a sentence or say a stop word like “um” between sentences, I should immediately stop talking. This gives me a moment to pause and refocus before I start again.

This makes the editing process much easier. I can just look for long pauses in the waveform and know that a section needs special attention.

Manually highlighting an “uh” stopword in Audacity and deleting it and the pause that follows it.

Step #2: Edit your recording

I listen to the entire recording all the way through in one sitting to make sure everything sounds right and that I didn’t leave in any duplicate takes.


I eliminate long pauses. Pauses shouldn’t exceed one second unless there’s a big dramatic reason for it. Pauses can be used for transitions, too, but they should only be a second or two long — otherwise listeners will zone out.

I always create a second save file after I’ve finished editing. This is because the sound wave transformations I’m about to do next can’t be undone.

Step #3: Remove noise

If there’s noise in the background, you can remove it with the Noise Reduction effect. You should first find a short segment with nothing but the background noise, select it, and create a “noise profile.”


Then you can re-run the Noise Reduction effect to cancel out that noise.

You’ll want to experiment with the levels until you find levels that sound just right.

Step #4: Amplify

Most podcasts are mixed to be as loud as possible. So I use Audacity’s Amplify effect. This will make the entire podcast consistently loud. This way, listeners won’t need to adjust the volume when they finish listening to someone else’s podcast then start listening to The freeCodeCamp Podcast.


There’s no magic number for how many decibels to amplify the track. Just eyeball it and try to get the waveform to fill up most of the space. You may have to control+z a few times and retry.

But be careful not to have too many peaks. It’s OK for sound to peak in a few places, but too many peaks will cause your podcast to sound tinny and distorted.

Step #4: Limit

Apply a limiter with a setting of -0.5. This will prevent the sound from peaking and “clipping” — which creates an unpleasant noise. Instead, the sound will never quite reach maximum volume.

Pre-limiting, you can see that the sound bar occasionally touches the top and bottom edges. So I limit the volume to -0.5 decibels to keep the audio from clipping.

Limiting softens the sound slightly and reduces any noise you may have introduced during the amplify step.

After applying the limiter, the sound never quite peaks (touches the top and bottom edges). This prevents a nasty “clipping” sound that would otherwise occur.

Step #5: Add music

Almost every podcast I listen to has a musical intro and outro — usually 5 to 10 seconds in length.

I tried to find Creative Commons Zero music (no attribution required) or easily licensable music. In my limited search, I couldn’t find anything that sounded right. So I decided to get permission from a band to use one of their songs as the official freeCodeCamp theme.

I edited the specific segments for the opening and closing and put them into an Audacity file so I can quickly add them and move them to the opening and closing.

Step #6: Export them MP3 and post it

Some podcasters say that spoken word can sound fine in as low as 48 kilobits per second, but that sounded way too compressed for me. So I opted for 128 kbps, which comes out to about 1 megabyte per minute of audio.

I use a service called libsyn to post these and syndicate them to iTunes, Google Play, Stitcher, Pocketcasts, Soundcloud, and a bunch of other podcast platforms.

I add detailed show notes with links to any resources mentioned on the podcast episode, credits to the author and reader, and a full transcript of the podcast (which in my case, I can get by reformatting the original Medium article to plaintext).

Then I can just send listeners directly to freeCodeCamp’s libsyn page, which has a nice reverse-chronological feed of all our episodes in one place.

Podcasting doesn’t take as much time as you’d think

I probably invest about 3 hours into recording, editing, and posting each episode.

If you’re doing an interview-format, you should budget some additional time to research the topic and learn more about the person you’re interviewing. I experimented with this earlier this year with my Quincy Interviews Devs YouTube Live Stream series, and it was a blast. Be warned though that interviewing is a skill all its own. And it is not one I’ve even begun to master.

With freeCodeCamp’s “mini audiobook” format, the article’s original author is often interested in reading it themselves. This makes the podcast more personal.

Many of these articles have been viewed hundreds of thousands of times and syndicated in major news sites. By revisiting their article a few months later, the authors get a chance to read their favorite comments and reflect on what’s changed since they published it.

For example, Bill Sourour’s article “The code I’m still ashamed of” sparked a broader public discussion on developer ethics in a time when many tech companies were doing scary or outright illegal things.

When he read his article for The freeCodeCamp Podcast, he was able to add additional details and talk about its aftermath.

You should contribute to The freeCodeCamp Podcast or start a podcast of your own.

Overall, I’ve found podcasting to be incredibly rewarding. I’m optimistic that we can get more people from the freeCodeCamp community to help produce these, and that we can publish a lot more frequently than once a week — all while keeping quality as high as possible.

If you get a chance to listen to The freeCodeCamp Podcast, I’d love to hear what you think. And if you run your own podcast, I’d welcome any advice you may have for how we can further improve this.

Podcasts have been around for more than a decade now, and they’re finally getting their moment in the sun.

I’m so excited to be a part of this movement.

I hope you’ll join me and start podcasting in 2019.

I only write about programming and technology. If you follow me on Twitter I won’t waste your time. ?