I thought it would be nice to do a few interviews with some of the speakers we have lined up! For the first one, I turned the tables on Geoffrey Grosenbach, producer of the peepcode screencasts & books, podcaster, interviewer, blogger, developer and trainer.
MC: Firstly, thank you for taking the time to answer a few questions!
GG: No problem.
MC: Usually, you are the one doing the interview on the Ruby on Rails podcast - do you have any good tips?
GG: I usually find out some side project or other interesting thing and ask someone about that or a current event.
It's easiest to do a podcast interview if the guest has interesting ideas of their own. With Zed Shaw I just put a few questions on the table and he took it away for an interesting interview
Hampton Catlin is also an interesting person to talk to. That interview went over an hour!
I like to hear a podcast where unexpected ideas or questions come up. I remember watching a documentary about a movie director (I can't remember who) and they would re-take a shot until the actor made some small mistake. That was the one that went into the final movie. I'm not trying to make guests make a mistake, but sometimes the conversation winds around ideas or thoughts that I didn't plan to talk about, and that often makes it interesting!
MC: I guess the amount of time you need to spend preparing an interview is fairly small compared with the work involved with preparing your peepcode screencasts?
GG: Indeed. A podcast is more of a spontaneous, one-shot event. A screencast involves planning and coding, then I do a draft, add a voiceover, and do other post production. So I want my screencasts to be very polished and useful, whereas the podcast has more of a live feel.
Personally, I like it best when I can do an interview in person at a conference or in the offices of a startup. When that can happen, I often find that there's another conversation AFTER the conversation.
And the environment adds to it. I've done short interviews on a subway, in a bar, and even in a van while riding to the airport.
I didn't expect it, but many of my good friends in the Ruby community are people I met when I sought them out for a podcast interview
I gave a short presentation at a business networking conference here in Seattle and advised people to start a podcast even if they don't have any listeners. It's a great way to meet people you admire or just want to have a serious conversation with.
MC: And how do you find people to talk to and pick your interviewees? Do you have a big wish-list, or get suggestions, or find interesting people at events?
GG: I always have a long list of people I want to talk to, and it keeps growing. Sometimes it will be in response to a recent news event. For example, I heard that PennyArcade.com had been rewritten in Rails, so I tracked down Sean Chittenden, the developer who worked on it. Or it was a similar thing when AListApart.com redesigned their site with Rails and I met Dan Benjamin for the first time.
At conferences, interviews often happen spontaneously. Desi McAdam suggested that I talk to her and a few other female developers. That turned out to be a fascinating two-part conversation and has been one of the top downloads.
Lately, I've been travelling less, so I try to call someone on Skype every two weeks.
So there's no overall plan, but I try to keep it current while occasionally talking to people who might be off the radar but are working on projects that I think should be noticed more. For example, I interviewed Christian Neukirchen two years ago about Rack. I'm not going to claim responsibility, but I'm very glad to see that Rails 2.3 is now built on Rack and can take advantage of its features.
MC: Moving on to your other work: As well as the podcast, you produce the peepcode screencasts & PDF books, you do training and you have developed several popular plugins like gruff & calendar_helper... you certainly keep yourself busy!
GG: I often feel that I'm not productive enough, but maybe that's what keeps me motivated to get organized and finish projects.
I think there's also a natural cycle of developing an open source project or plugin, then discovering that it's not that useful (or is complete and doesn't need any more work). Or, I need a feature so I'll add it to a project and keep it going. For example, I implemented bullet graphs in my sparkline gem a few months ago because I needed them for my internal reports at PeepCode.
I've found it helpful to have goals. Yes, this seems obvious, but I went over a month without releasing a podcast and decided to try to release one every other Friday. I've been pretty close to that so far in 2009, and it has actually been less stressful to just put it on the calendar and arrange a conversation every other week.
And of course, PeepCode is my day job. It's a lot of work to start a business but I've refined some parts of my workflow as I discover roadblocks. For example, it previously took me a day or a day and a half to record a voiceover for a screencast. I now do a draft, send it out to be transcribed, then go to a recording studio and do it in about 90 minutes. I think the overall quality is better because I'm working off an edited transcript so I know what I'm going to say. And I don't have to fight with the sound of planes, birds, and cars driving by. The studio I found happens to belong to an independent heavy metal recording label, so it's a fun environment to record in.
MC: Sounds cool :) As you say, you've been working hard on your business by improving processes. You also advocate 'eating your own dog food'. Can you explain what that means to anyone who just started feeling a bit queazy?
GG: In spite of the quantity of open source software available, there's still a value in writing parts of your app from scratch. I try to use existing plugins and gems where possible, but I've been burned lately. Rails changes so fast that the plugins that were previously authoritative are no longer maintained by their authors. So writing one's own plugin makes it easier to know what it does. With a good test suite, you can keep it up to date with changes in Rails.
On the other hand, it's also easy for bugs to occur without really knowing it. So I guess that's one of the values of open source software...many eyes to discover bugs and fix them. But if people aren't reporting bugs or if they never encounter them, the system fails on that account. At one point, I think I was the only person using REST with Rails 1.2 on FastCGI with page caching. I encountered some very weird problems that apparently no one else had experienced. Eventually, they switched the URL syntax to the slash instead of the semicolon. By that time I wasn't using FastCGI anymore, and I'd guess that few other people were either.
But back to the dog food, I tend to write my own when I want a specific feature and it doesn't exist elsewhere or doesn't work the way I want it to. So "eating your own dog food" means that you use the software that you write.
MC: And do you use the same concept for your peepcode work? How do you pick the topics? I notice there are a number of iPhone things in the works - is that something you have a particular interest in, or due to popular demand?
GG: Selecting the next PeepCode topic is one of the most difficult parts of the business, but I'm learning how to do it better. I use the UserVoice suggestion site (http://suggestions.peepcode.com) to get feedback on what people want to hear about. I look at how well other topics have sold.
The Objective-C screencast has been one of my best sellers and has received great reviews, so iPhone-related content will be next.
In addition to finding it personally interesting, iPhone development provides a direct way for people to write applications and profit from them. That's one of the core principles that I started with: Teach skills that will be profitable for the student. My philosophy is that if I teach people concepts that help them run a more profitable business, or increase their hourly rate, or improve on their productivity, that they will be willing to pay for those tutorials. So I want to give people more value that what they paid for.
Some topics have been obvious. Many people were interested in RSpec, but few resources were available. Even now, the first book is yet to be published even though RSpec has been popular for a few years.
Others were topics that I felt I needed to know about, but that weren't quite popular yet. When I did the screencast on Git, very few people bought it. A few months later, around the launch of GitHub and the movement of the Rails source to Git, interest in Git skyrocketed. So it was affirming to place a bet like that and see it pay off.
Now with over 35 screencasts and PDFs, I'm planning a maintenance cycle where I'm going back and updating the older content for the upcoming Rails 3 and newer versions of RSpec and other software.
MC: Well, I think we've just about run out of time already!
GG: thanks for the conversation!
MC: Thanks again for taking the time to chat, and I look forward to seeing you at Rails Underground :)
GG: me, too!
Thanks again to Geoffrey. I hope you enjoyed this interview, I'm working on doing some more, and will be posting them soon! (They should appear in the interviews category)
And we're also using uservoice to chat about proposals or suggestions for talks at the conference - please come and tell us what you think.
