The Artima Developer Community
Sponsored Link

Computing Thoughts
Podcasting Pointers
by Bruce Eckel
October 4, 2007
The basic tenet in podcasting is "Think About the Experience of your Audience." All these points are simply details of that one statement.


When I travel I listen to a lot of podcasts. The right podcasts are a tremendously valuable way for me to keep up on developments in the field.

Things that work and things that don't become pretty obvious. These are suggestions from a listener's perspective.

I'm naming names in this article not to be harsh, but because I listen to these particular podcasts and want them to be better, and if I don't say who does what it's too easy to think "I don't do that." I've certainly made some of these mistakes in my own audio interviews; I'm not suggesting that I've done a lot better. This list is intended to help you improve your own podcasts.

Also note that almost all of the casts I'm talking about here are ones I listen to regularly, which means, regardless of what I say about them, I get enough value that I keep coming back.

Don't Bother if the Sound is Lousy

I put this at the top because it's the one that I find most amazing. The only way you are interacting with the audience is through sound, but many people seem to find it to be too much effort to get the sound right. Podcasts with noise, unintelligible sound or wildly varying levels (so you must constantly keep your finger on the volume control) are fairly common.

The best example of sound in the casts that I listen to is the JavaPosse. Early casts of Drunk and Retired were un-listenable because one guy was at the microphone, and the other one was in the back of the room or something so you alternately couldn't hear or got blasted. Theoretically they got better, but there wasn't enough content to keep my interest.

If you don't get the sound right, you might as well not do the podcast, because I'm going to give up and go to the next one.

Don't Use the Telephone or Skype or a Laptop Microphone

What has really surprised me is the number of discussions on IT Conversations that are phone interviews. I know it's hard to do the necessary technical stuff up front to get a good interview, but really, save yourself the trouble if you're just going to use the telephone, or the microphone in your laptop, or any other compromise solution that seems like a good idea at the time because "doing it right is just too much trouble." Trust me, if it's too much trouble for you to produce it well, it's definitely too much trouble for me to listen to it.

Sometimes Skype will work, but unless you know you have a reliable connection, or that you can redo part of your interview if Skype acts up, don't assume you'll get good sound quality all the time from Skype.

Here's the right way to do a remote interview, which Dick Wall uses for JavaPosse interviews: each party records themselves locally (a good, free way to do this on Windows/Mac/Linux is with Audacity) at the same time they are using Skype or the phone to communicate. At the beginning of the interview, everyone counts down "three, two, one, mark" so they place a mark in their recording. Afterwards, the producer blends the recordings by lining up the marks. You get superb sound quality and everyone sounds like they are in the same room.

I've had great results with the Plantronics DSP500 headset, which plugs into your USB port (so it does the A/D conversion internally and delivers the already-digitized signal). It has an internal digital signal processor to improve the sound quality. Because it's a headset it maintains the microphone position at the same place for very consistent sound. If your interviewee doesn't have the right equipment, spend 50$ and send them one of these. Not only will you get great sound quality, you'll make them feel special.

Test Your Results

This is kind of amazing to be telling podcasters who do software engineering, but: you can't trust the technology.

Make sure your whole podcast gets up there. I've listened to several from Software Engineering Radio and JavaPosse that just got cut off, either by the posters or by iTunes.

And sound levels -- make sure you aren't putting something up that requires the volume to be turned up all the way. Again, see the JavaPosse for examples of not only good sound levels, but ones that are consistent throughought. A Prarie Home Companion, in contrast, is generally too low and varies all over the place (amazing from people who have a whole staff with tons of experience in radio).

Think about what people are hearing and what the real podcasting format is. Software Engineering Radio often says "welcome to a new episode of Software Engineering Radio." If this were a real radio show, then "new" would have some meaning, but these shows are up for a long time.

Figure out how iTunes works. To continue picking on Software Engineering Radio, whenever you hit refresh on your iTunes podcast directory, it always seems to bring up a bunch of old shows that you've already listened to.

Keep it Dense

The best podcasts try to condense the information and don't wander off into topics that the podcast really isn't about. A good podcast doesn't try to have light conversation to establish personalities, but they allow personalities to come through in the process of giving information.

Again, a good example of this is the JavaPosse. Even when they're joking around, they're joking around about the subject. And when they "get off topic," it really means they've found a subject that interests them enough to delve in and discuss for awhile. I almost never fast-forward the JavaPosse. This is an example of a podcast that really works, and really adds value to my listening experience. They always seem to be serving their audience, remembering what the audience has come for.

Software Engineering Radio also tends to stay right on topic. The Agile Toolkit will occasionally wander and should tighten it up a bit, but it's not too bad.

Just Ask Questions

I've caught myself doing this sometimes -- a nervous habit where you feel compelled to say "yes" and "uh-huh" and other such noises while the interviewee is talking. This is a hard one to break, because it might be the way you speak normally. It's annoying then, but really annoying in an interview. The Agile Toolkit can do this a lot, as does Software Engineering Radio.

Even people who are apparently professional do it. The person interviewing George Lucas does it here:

Be Careful About Glitzy Intros or Ads

Try to just say what the name of the podcast is and stop there. If there's any musical portion, it should be a signature, ideally a couple of seconds long. Longer than that becomes annoying.

It's not about you. Try to keep what you do focused on what the listener wants. For technical podcasts, showmanship is not what I am interested in.

Not only is a glitzy intro distracting, it may send the wrong message. Here's a video cast which is over the top. I'm very sorry to say this, Josh, but it made me not want to watch the rest, and I don't think that's what you wanted to achieve. Besides, don't you mean "Live to code" not "code to live?" Isn't the Harley slogan something like "Live to Ride?" "Code to live" is what people with cog jobs do. It basically says "I'm doing this job because I need the money to live, not because it excites me." All podcasters should learn from this and consider their message.

The only ad I would personally want to listen to is one that actually gives information. I have no patience for "push" advertising.

Remember, when thinking about both intros and ads, that we all have Tivo-like control over our media these days. I've gotten quite good at skipping over the IT Conversations intros and the JavaPosse song using the thumbwheel on the iPod. But what you don't want to happen is for the listener to hit the "next" button instead.

Don't use Video if Audio is Enough

The nice about audio is that I can listen while I'm doing something else. Video requires full attention and unless you're actually showing me something, why should I (1) wait for a much bigger download or put up with the pauses in streaming and (2) have to look at someone's face while they're talking? What does it add for the hassle it costs me?

Here's a perfect example. The only ones I looked at were talking heads. Totally unnecessary and I can't put it onto my iPod. It forces me to look at it while I'm sitting at my computer and that's not when I do this, so I'm not going to listen to these.

Don't Make it an Infomercial

A number of people and companies have tried this. With more and more podcasts available, it's too easy to skip to the next one if your podcast is trying to serve you more than it does the listener.

Here's an example -- it's (mercifully) short.

Actually, the interviewer is pretty good; she gets out of the way after asking her questions. And the interviewee is very good. Notice virtually no "ums" and "ahs" and other throwaway words. Just a steady stream of ... well, that's where it falls apart. He's talking a lot and the words and sentences seem to fit together, but what is he actually saying? It's got lots of buzz-phrases, but he doesn't really seem to be saying anything. The message is sort of about agile being good and that it's being adopted in different ways and that you can have problems. But there's not really any "there" there. Which makes me think it's an infomercial, or at least not the kind of thing I want to listen to (the other casts in that series are roughly the same: well done and relatively content free).

Kudos and Gripes?

What does and doesn't work for you in a podcast?

What programming podcasts do you like?

Talk Back!

Have an opinion? Readers have already posted 2 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.

About the Blogger

Bruce Eckel ( provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.

This weblog entry is Copyright © 2007 Bruce Eckel. All rights reserved.

Sponsored Links


Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use