h1

Want to be on my podcast?

June 5, 2013

I have a podcast now: you can listen at http://embedded.fm/ or search for Making Embedded Systems on iTunes (or Instacast or Stitcher). The podcast is about embedded systems and, like this blog, it consists of whatever I’m excited about (and who I con into being my co-host/guest).

But what I really wanted to put here was some of the process stuff I’ve learned having done the first four podcasts. Here is the short version.

  1. Find guest, agree upon general topic.
  2. Make outline (ideally Wednesday before show)
  3. Send outline to guest, get mods back by Friday.
  4. On Saturday (or Sunday), do 2 hour recording session.
  5. Producer does producer-y thigngs
  6. Show comes out on following Wednesday.

So, once I hook a victim and choose a topic (i.e. “What an electrical engineer thinks a software engineer should know”), I make an outline.

The outline isn’t exactly a script, though the intro and outtro are written out. The outline is more a list of points and questions so I don’t forget any of my plans. We don’t have to stick to the outline but it means I don’t have the “err, what was it I meant to ask” feeling all the time. It also lets the guest know what things I’m likely to want to ask about so they don’t get caught off guard.

I sent the outline to the guest. Actually, the outline starts with a notes section:

I tend to script the first few minutes as it helps get comfortable. I have no problem going off script, it is just a crutch for the first few awkward minutes.

If you want this (or something else), let me know. We found paper to be noisy so I’d prefer to put your notes on my ipad if you’re ok with that.

Finally, I put in two end points. The goal is 45 minutes but I’d rather be 5 short than 20 long.

Next in the outline is the intro, all scripted out, as promised above.

This is Elecia White, welcome to Making Embedded Systems, the show for people who love gadgets.

This week I’ll be speaking with Phil King one of my favorite electrical engineers. The plan is to hear what a hardware guy thinks software engineers should know.

Hi Phil, welcome to the show.

[Phil says hello]

I know you’ve worked at some neat places, we made children’s toys for Leapfrog and a gunshot location systems at ShotSpotter. What else have you been up to?

[Phil gives 30s bio]

When I was a manager, hiring new embedded software engineers as my minions, Phil was part of the interviewing team. He was excellent at finding people with really good skills, even better, he could articulate what he liked (and didn’t like) about candidates.

So, Phil, what was your secret question?

And now we are out of scripting and into the outline. From here, there are lots of points I might want made (either by my guest or by me, I don’t usually differentiate). Sometimes these are question (“You always really cared, making sure we hired good software engineers. Why is that important to you?”) and sometimes they are just notes for both of us (“software engineers can damage to HW…”). Also in the outline, I might have reminders purely for me (“tell story about capacitors”) so I don’t forget something I think is nifty.

But these are just conversation points, if we skip one, no big deal. If the conversation is flowing, I’d like it to flow naturally.

Finally in the outline, there is the outtro, what I need to record when the show is over.

We’re out of time though I know we’ve got a lot more to talk about, you willing to come back?

[Phil]

Ok, thank you for joining me. Thanks also to our producer Christopher White and to everybody tuning in. Please leave us comments and questions at embedded.fm or show@makingembeddedsystems.com. We love to hear from you.

Next week, we’ll be talking to (? about ?). Have a good one.

I write the outtro so I don’t forget to thank people or say where to send comments.

Once the outline is done and sent, I start taking notes for random things I might want to say… extra things inside the outline bounds. Sometimes I ask for questions or information from twitter for “voices from the audience” sorts of things. I also try to think up some pre-show chat while we are getting the sound levels right (I jokingly asked Phil about his feelings on exclamation points, we got off on a tangent about the interrobang which made it into the show a little). It calms the guest (and me) and makes the show flow better if we are already chatting.

Recording isn’t hard, thanks to my husband-producer-superhero, Christopher White. He’s done wonders to make us sound good. Despite most people not liking their voice (me included!), everyone has been happy with the recordings, so far. In addition to monitoring sound levels, he tags points where we start and stop (hey, I stutter, sometimes I don’t want to share that) and highlights where we mentioned things that should go in the show notes (that RSS feed doesn’t write itself, you know).

Recording takes about 1-2 hours to get enough info for around 45 minutes of show. Later, usually right before he releases it, Chris edits the audio to eliminate the goofs. He makes us sound good (and balanced), does any bleeping, adds music as needed (he wrote the intro!). He attaches it to the RSS feed, presses publish. That makes it go to iTunes and Instacast and Stitcher where people can get it.

If you want to be on the show, please let me know. Most of my guests haven’t done too much prep (I want to talk about what you know, not something you need to learn and prepare for) so the process is about 2.5 hours of your time: gadgets, embedded systems, parts, technology, working on gadgets, maker projects, etc.)

There are some things I still need to figure out. We have a recorder I can carry about (if I’m willing to get crummier audio) so it is possible to do on-site things. But I need to learn to use it better, especially to get voices right for an interview. I have a plan to interview someone in San Francisco in July so I have a deadline. And I know some people do podcasting via Skype audio which would increases my pool of guests; I want to sort that out.

There’s always more to try out and to learn. And I suppose when there isn’t, I’ll do something else.