A few weeks ago, I started a Java-oriented podcast. It’s not actually solely my content – it’s actually based on user-submitted data from an channel on the Freenode IRC network.

If you’re wondering, IRC is what Slack and Hipchat were before they decided to spawn clients that looked pretty and took up four gigabytes of RAM.

The podcast is still pretty new; I’m still figuring out things as I go, like “how long should it be?,” “What content goes into it?,” “How should it sound?,” “What should the show notes consist of?,” “Who should be on it?,” and “What should the trappings around it look like?” I have some answers for these, but it’s still a work in progress.

How Long Should It Be?

My initial goal for the length of the podcast was around ten minutes. So far, out of three, I’ve been around twelve minutes for two of them, and seven minutes for the third.

I’m not a fan of long podcasts, because I don’t have the time for them; plus, they tend to withhold content. I want to be high-signal, low-noise if I can; if I have something to say, I want to say it.

However, making the podcast too short is bad, too, for a few reasons.

One reason is that I have to speak quickly – and I’m not a good speaker. Speaking quickly is simply not my forté. Plus, speaking quickly affects those who listen who are not native English speakers.

Another reason is that making it short prevents me from actually trying to communicate about the elements in the podcast; part of the value of the podcast is the curation of the content. It’s not so much that I’m an expert or that I’m proud of what I know or don’t know, but I think I might be able to add insight or at least some observation about why something might be relevant; that adds value through the podcast that I think is the best chance for it to serve its purpose.

So far, I’ve been okay with the twelve-minute format; it’s long enough for me to actually have some room to offer insight or commentary where I can, and it’s short enough that I can just record it without making it too much of a performance or a series of recordings.

What Content Goes Into the Podcast?

This is the fun part: I’m not actually scumming for content! Sure, I have my own RSS readers, and I watch various news sources for interesting stuff on a regular basis, but most of the content from the IRC channel comes from other users. We have a bot set up, with a command – ~submit – and users can simply submit a url that they think represents interesting content, and they can include a comment. So it might look something like this:

~submit http://foo.bar.com/ this is awesome because it just ... is.

Exciting, I know, but it means that anyone who mentions something on-channel has a very low barrier to signaling the podcast’s curator (i.e., me) that there’s something worth seeing. I can look at the list of submissions, and judge whether to approve or disapprove of the content; rejections might be because we have too much content for a given podcast (which has happened), or because the information is duplicated (which has happened), or because it’s not entirely appropriate given the subject matter of the podcast (which has also happened).

This part of things is actually improving over time, I think.

How Should It Sound?

I’m still working on this. I’m not a fan of extremely dry (audio-wise) podcasts; I’m also not a fan of podcasts that have a backing music track, or have lots of noise in the background (as if they’re recorded in a bar or a restaurant, for example.)

What I’m going for is a live feel, so a little bit of room reverb, equalized in such a way that it doesn’t sound horrible. Simple enough, but I haven’t gotten the podcasts sounding the way I want them to yet; so far they’ve been too wet (too much reverb) or too dry (not enough).

For the first two podcasts, I used Cubase 9 Pro for recording and mastering, with Waves‘ Abbey Road Plates (bought on sale) for reverb; the introductory musical flourish was just me using Cubase’ built-in drums and sample kits for a short… thing. I was using a Neewer NW-700 mic for recording my voice; it’s not a great mic but it’s a good mic and I’m used to it.

The third podcast was recorded with the MacBook internal microphone, with Camtasia 3, recording only audio. The flourish was copied in from Cubase as an additional audio resource. There was no real post-treatment of the audio, apart from some noise-reduction and compression.

Don’t get me wrong – Camtasia’s a great product – but it’s not suited for the podcast. The only reason I used it was because my primary multimedia recording machine was occupied with a different project and I didn’t feel like moving it for the podcast.

What Should the Show Notes Be?

As a podcast, it’s very difficult to communicate URLs well. They’re just gross to read out – and the podcast isn’t talking about web sites but specific news items, so I can’t just say “Go to techsmith.com,” or whatever. I have to read out these often ungodly urls – one url from the third podcast was a long string of words mashed together with no dashes or anything.

So … show notes are on the “critical” side of things. I’d originally thought of just having a list of URLs, as a sort of raw form of the submissions, but I didn’t like that idea either, since I would prefer to read than listen anyway; a raw list of URLs wouldn’t be very useful to me. They’d lack the curated aspect that makes the podcast worthwhile (or so I hope).

Plus, recording the podcast purely as a reaction to the URLs didn’t work; I found that I needed to actually annotate the content myself to more or less keep track of what I found interesting, or else recording would sound terrible. I needed to prep myself… by writing a rough script.

That rough script is currently what makes up the “show notes.” I actually read the script for a lot of the podcast, and I give myself the freedom to abandon the script where I feel like it – without the requirement that I go back and “fix the script” to match the podcast.

So far that works best for me. It allows the podcast to flow, and prevents listeners from having to wait while I “gather my thoughts” (and prevents me from having to edit out such thought-gathering moments in production).

I’m not sure if that works best for everyone, though. More on this later.

Who Should Be On the Podcast?

Right now, the podcast “talent”- using the term loosely – is me, and me alone. I find that podcasts with multiple hosts are workable, and the interactions can work very well, but I’m not quite ready to deal with the logistics involved. Plus, having one person on the podcast means there’s no conflict of egos; it’s not that I want my ego preserved, but that if I turned it into a two-person show, I’d probably be happy saying nothing (so it’d be right back to being a one-person show).

I’m not really sure how to handle this; I’m okay with it, but I’m not ego-driven enough to be especially happy with it, if the potential is there to make it a better show by having multiple hosts.

I haven’t even begun to think of interviews yet. I’ve done them in the past (in other jobs), but I think that would be outside of the scope of the podcast as it stands right now; it’s the IRC channel’s content, and I’m not sure how an interview would play into that.

What Should the Trappings Around It Look Like?

I don’t know how to build the front matter for the podcast, or present it such that it’s cleanly represented in listening apps yet. I have an image for the podcast (it’s a Jackson Pollack painting) but I don’t have it watermarked (nor would I feel good about watermarking it, it’s someone else’s work), and I don’t have good RSS content for the podcast yet. I just don’t know what to look for, yet.

So Where Now?

I’d love to get feedback on what I can do better. I’m inexperienced at the whole podcast thing; I think it adds value, but I also need listeners’ opinions on what to change to make it better. I’d love to hear compliments about how well it’s done, I guess, but what I really need to know is how to improve it.