Perl Weekly Issue #704 – Perl Podcast
perlweekly.com
perlweekly.com
It's either technical stuff that would be much better served in an article or video format, or else it ends up being vapid hype about new language features or the like.
If anybody has counter-examples I'd be interested to hear them.
I feel like the only programming language related content that is suited to the format would be something like history/historiographical content and the like. Like I said, interested if anybidy has examples of the format working though.
The setup I've found to at least be somewhat entertaining + thoughtful enough to feel meaningful, is interviews with people who have a ton of experience seeing how the world evolved over time, and can contrast that with how things are today. People would get a lot better at avoiding mistakes if we could get better at listening and hearing folks that are older than us.
But it's really hard to find good interviewers who also end up having good guests. Most interviewers seem to be more like announcers, and then they don't seem to think/react at the spot to dig deeper into things, but just gloss over some talking points they wrote the day before.
That's been my experience too, so I've been pleasantly surprised by the Julia podcast (Julia Dispatch). Instead of trying to shoehorn the mechanics of code in a podcast (the way most programming podcasts do), they sidestep the issue by making it a human-to-human conversation that happens to have a programming language as an anchoring point.
A small part of it is the historical angle you mention, the interviewee's journey into the project they're talking about, and the project's own journey from idea to infancy to now.
But the more important part to me is the discussion of the mindset behind the project, the reasons for design choices, and how their views have evolved over time. Even as a mere user, it helps a surprising amount to get insight about the thought processes of Karandeep on the Tidier ecosystem or Tim Holy on developer experience; it makes it easier to predict how things will work, and reason about why they work that way.
The format only takes you part of the way though, IMO, a lot of it also comes to down to just interviewing skill. Most podcasts go one of two ways here too: templated boilerplate questions that repeatedly disrupt the rhythm of the conversation, or direct questions about the guest's answers which end up going too niche for most listeners. Michael Tiemann on JD instead follows up on the answer, but not with a direct question that digs deeper (and goes niche), but in a lateral way that often takes the chat in new interesting directions. I think part of the "secret" here is that he takes a few moments after an answer to collect his thoughts and come up with a question - which is a simple thing a lot of podcast hosts seem scared to do, and so they end up taking one of the two quick-and-easy ways above.
(Sorry for the essay, I've had these thoughts bouncing around in my head ever since I found out I liked the podcast more than I thought I would, and I took this as a chance to organize and write them down.)
> If there's one thing I like more than writing code, it's talking about code. My best memories about code usually involve a late night discussion with a drink in one hand and no keyboard in the other.
> In 2024, I seriously started listening to podcasts. "Live conversation with eventual interventions from the audience" is the format I find to be the closest to the bar conversations I like so much, and I'd love to listen to (and chat with) my friends from the open source community, talking about random mostly technical topics.
> So, I figured I should just try it! How hard can it be to setup a conference call, invite a few interesting people, pick a topic to start the conversation, hit "record", and stop after roughly one hour? And make the recording public afterwards, for others to enjoy.
> (If you don't like the undertones of "bar", you can think of this as "campfire stories".)