Skip to content

Blog

Extracting Written Content From Podcasts And Livestreams

I wrote before about not wasting content that you’re creating as you answer questions or interact on communities like Twitter, Bluesky, Discord or Slack.

One great source of content for your newsletter or blog is podcasts or livestreams that you are on. Here’s how I’d do that with an example podcast interview I did a few months ago.

First you need to transcribe it. Most podcasts and livestreams are posted to youtube, and my go to tool there is youtubetranscript.com. Here’s the transcript of the interview. I know people who are happy with Descript and I’m sure there are other solutions out there.

Most podcasts are a wide ranging conversations with multiple possible newsletters or posts contained within them. Sorting out these topic areas is a great use case for AI.

Paste the transcript text into Claude.ai and ask for topic grouping as well as verbatim text for the beginning of each of the topic groups.

Here’s an example of the Claude output:

Content Creation and Repurposing Strategies
Starting text: “I think that the reason I wrote this blog post is because I am a member of a lot of different slack communities or follow people on again on some of those platforms that I shall not mention and I see some great great content that comes out and great answers great wisdom and then it just and then it goes poof away”

Themes:

  • Leveraging existing content from platforms like Slack
  • Low-effort content creation
  • Transcribing podcasts for newsletter content
  • Maintaining authentic voice while repurposing
  • Best practices for newsletter creation

Claude identified five topic areas in this transcript. Once you have this, go back to the raw transcript. Search on a unique text string and. Pull out an interesting, relevant section.

I use the youtubetranscript site to understand where I stop talking and other people start. You can click on a section in the text and view the corresponding part of the video. There may be an AI solution or a specific GPT to do the transcription and have it include speaker names, but I haven’t found one yet.

Here’s an example section that I extracted:

I think that the reason I wrote this blog post is because I am a member of a lot of different slack communities or follow people on again on some of those platforms that I shall not mention and I see some great great content that comes out and great answers great wisdom and then it just and then it goes poof away and even on some some like I follow the ietf emailing lists around ooth and things like that I see some great content there but it it especially in in slack but even in those other places it just gets lost and so my point was by picking up and putting it onto um a newsletter you can and maybe you do some editing right because most stuff that you you um write off in a slack it might not be as Pol as you would normally put a newsletter but you can basically take this um wisdom exhaust right like it’s like kind of like data exhaust from the early 2000s but you can like pick it up and put it together and even if you don’t think you have enough content for a newsletter I think you do if you are active on those channels and by taking it from these walled Gardens of the platforms or slacks or discords and putting it out on a in a newsletter you do a couple of things one is you just showcase Bas your knowledge um the same way a Blog would you can deliver it to people you have a low effort way to connect with folks right if you ever run into somebody a conference or whatnot instead of asking them to follow you on something you can say hey I have a newsletter about real estate in Atlanta or I have a newsletter about how developers are the new king makers or AI or whatever it is and that’s just a lower ask than some other things and it will start to build up a longer term relationship with anybody that you’re um engaged with at low effort to you so that’s kind of the the purpose of the blog post is people are creating all this beautiful content and it’s just trapped especially stuff in slack

This one section is 383 words. This is the kernel of a newsletter edition or a blog post. However, this needs some work. I can’t copy it directly into a newsletter or blog post because I don’t talk as clearly as I write.

Let’s take the above content and lightly edit it to be something I’d feel comfortable publishing.

The reason I wrote this blog post about not letting your content go to waste is because I am a member of a lot of different slack communities where people post great content. I also follow people on Bluesky, that which was formerly Twitter, and other platforms where, again, people are dropping lots of knowledge. This even occurs on IETF mailing lists. There the content is available but it can be difficult to separate the gems from the dross.

I see great great content published and great answers for common questions. Then it goes “poof” away.

Especially in slack but even in those other places, this content just gets lost.

By picking up and putting it into a newsletter you save it. You have to edit it, because most Slack posts are not as polished as newsletter content would be.

But even with that work, you can basically take this “wisdom exhaust” and repurpose it. It’s kind of like data exhaust from the early 2000s. Even if you don’t think you have enough content for a newsletter, you do, if you are active on those channels.

By taking it from these walled gardens of the platforms, slacks or discords and putting it out on a in a newsletter, you do a couple of things.

  • you showcase your knowledge
  • you deliver it to people’s inboxes so they remember you
  • now you have a low effort way to connect with folks; if you ever run into somebody a conference or whatnot instead of asking them to follow you, you can ask them to subscribe to your newsletter
  • you start to build a corpus of knowledge and a set of people interested in hearing from you.

I edited to clarify and expand on the content. I added links where appropriate, and also updated it–Bluesky wasn’t a big thing when I did this podcast.

This is fewer words, but a firm foundation for writing a longer blog post. I could also review the transcript for more of my words.

So, that, in a nutshell, is how you can easily generate written content from a podcast, recorded presentation, or livestream.

Don’t just build a backlog, share it too

I have started sharing more blog posts and podcast episodes on Twitter, LinkedIn, email lists, slack channels, and other places. It’s kinda fun to look back over past work and find something that resonates. I’ll often discover this when I’m engaging in a discussion or see a post on a related topic.

This is one of the benefits of blogging. You can lay out your thoughts on a complex subject in detail, considering various points of view before coming to a conclusion. When someone brings up the same subject, you can share your thoughts with a single link copy and paste, rather than retyping all your thoughts.

There’s also value a backlog of stream or podcast guest appearances. Don’t just share the podcast when it first comes out (though you should do so). Share it repeatedly! You and the host had a good conversation, right? Most conversations are just as valuable a year later as it was a day later. Even if you are talking about the news of the day, your analysis should have long term value. And podcast hosts love to see someone share an old episode; it helps raise the profile of their efforts.

I like to use scheduling for some of this backlog highlighting, as that lets me batch i tup.I have successfully scheduled out posts using native tools. Both Twitter and LinkedIn let you schedule posts. Twitter lets you schedule out posts up to 18 months out. LinkedIn is more limited and only lets you schedule out three months. But if you are posting two times a month, that’s still six posts/pieces of content you can share.

Don’t rely entirely on scheduled posts. Engage spontaneously. However, having these posts scheduled means you are still sharing your past work even if you have a busy week or a vacation.

You can highlight a backlog of short form content too. With Twitter, I also do “still true” posts where I retweet one of my posts that I feel is timeless. Here are some examples.

Finally, a public backlog of your thoughts is a great way to show your expertise and growth over the years.

You know who likes to see that?

Employers.

20 years

Wow, it’s been 20 years since I started this blog. The world and my life have changed quite a bit, but I still like to muse on technology, business and more.

Thanks for reading! I appreciate everyone who takes the time to listen to me, whether you scan it, share it, or reach out to me to let me know.

Still think blogging is one of the best things you can do if you want to:

  • engage with people
  • understand a subject
  • build a business
  • create a name for yourself
  • think deeply about a topic
  • find a job (but not quickly!)

Thanks again for 20 great years!

How to have great guest posts on a blog

I have another blog that I’ve been running for a few years, called Letters to a New Developer.

It is full of advice I wish I had had at the beginning of my software development career. I even turned it into a book.

One thing I’ve done the entire time I’ve been writing this is to ask for guest posts. No advice is generic; it’s all based on where and who you are. By asking for guests to share their experiences, I expose my readers to a wider variety of viewpoints. This leads to better understanding of the wide world of software.

After all, if you want to work for a FAANG, it’s better if you hear from someone who prepped, interviewed and was hired for such a company, rather than me, who will never work for such a company. Or if you are looking to understand what it’s like to work in open source, hearing from someone who has made it their career. Have imposter syndrome? Others have struggled with it too. Also works for techniques; it’s great to hear from someone who is a methodical journaler, for example.

I bet you get the point. There’s no way I could have written any of those articles.

Guest posting also helps spread the word about my blog, since a guest poster usually shares their writing with their friends and network.

For the right kind of blog, guest posts can be great. Here’s my criteria:

  • Does the blog have decent traffic? If not, folks probably won’t want to guest post. I’d say at least 25 visits a day.
  • Have you done this for a while? A years worth of regular posting shows you’re serious.
  • Does the blog present a variety of viewpoints? I wouldn’t want a guest post for this blog, because it’s all me, all the time.
  • Is the blog non-corporate? If it is a company blog, guest posts should be paid for with money, or be part of a co-marketing project.

If you want to have great guest posters, here’s my recipe for finding them and fostering them:

  • Don’t accept inbounds, unless you know the person or can vet what else they’ve written.
  • Don’t accept any content that is off-topic.
  • Set a target guest. For me, it is someone who is or was a developer with different viewpoint and perspective. I was especially interested in highlighting voices of people who were not white men.
  • Keep an eye out for interesting posts or interviews. Reach out to the authors and see if they might be game to guest post.
  • Be okay with a cross post. I’d say about 60% of my guest posts are original content, but more recently authors want to post the content on their blog first. Offer a link back.
  • Be okay with a repost, especially if the author is prominent. Review existing content and find one or two articles that fit with your blog’s theme. Ask if you can re-publish. Offer a link back.
  • Some folks will say no. They can do so for a variety of reasons (don’t want to write, don’t syndicate their content, etc), and you have to be okay with it.
  • If someone says “I can’t right now, sorry.” reply with something like “Totally get it. I’ll follow up in 6 months, unless you’d rather I didn’t.” Then, follow up. Sometimes they’ll ignore you, sometimes they’ll have more time.
  • If they are writing original content for you, offer to edit it. Find out how much editing they want. I’ve over-edited a few times and that’s a bad thing if someone is volunteering their time and knowledge.
  • If they ask about topics, advise them to focus. Lots of people want to write about “5 things you need to do” but in my experience, articles with focus on one topic are better received.
  • Write up guidelines so you can easily share. This can include audience, benefits, formatting, delivery mechanism, word count, topic ideas, and more.

Hope this helps. Happy guest blogging!

Thoughts on static site generators and WordPress

Blog in scrabble lettersIn my last few jobs, I’ve done a lot more writing. I’ve learned to work with static site generators (SSGs), such as jekyll and 11ty. I even moved a database driven side project to Netlify. Here’s an interesting survey about SSGs from Redmonk, if you want to learn a bit more. I am also a longtime WordPress user, and think it has some tremendous strengths. I wanted to capture my thoughts on these two options for building your website.

Here’s why I’d pick WordPress for a content heavy site:

  • Avoid any kind of compilation pipeline or step
  • The authors don’t have technical chops and want WYSIWYG
  • You want more than a blog, with additional functionality pulled from the wide world of plugins. Also, themes!
  • You want to allow people to just write, without software getting in the way

Here’s why I’d pick a static site generator for the same:

  • Need performance and scalability at a low low price
  • Wanted ‘set it and forget it’ security (you can’t hack a static HTML page)
  • Authors are technical enough to write markdown and to leverage the data driven possibilities of an SSG
  • No need for interactive functionality, beyond what JavaScript/JAMStack can provide

Like any other choice in software engineering, these two solutions offer tradeoffs.

I think that SSGs are far better for simpler websites, and in some ways they are a more sophisticated version of very early websites. I remember writing a perl program to take a usenet file and turn it into a set of web pages in the last 1990s. (It was jokes, if you must know the content.) When you build and deploy a static site, you know exactly what you’re getting, but you can also extract common functionality to shared files. You will have to compile it, however, and typically uses a version control system, which can be a lot for some non technical folks.

WordPress is fantastic for just getting going. I can get a blog started in 15 minutes that can be used by anyone who knows the basics of Microsoft Word. The flip side of the speed to first page is operational complexity, slower performance (all things being equal), as well as a more complicated application to secure.

I will say that as a developer, SSGs are growing on me.

PS I know some people have combined them both, and using WordPress as the backend and publishing a set of static pages is really appealing. I’ve done some preliminary work on this, but haven’t found a great solution out there.

16 years

Fiat and treesWow, 16 years of blogging. For the record, this is the 992nd post.

Does this mean my blog can drive?

16 years ago I wrote my first post about RSS. I recently just added RSS to a static site generator that had a blog component. What is old is new again, indeed.

Blogging has taught me so much. How to write. How to promote. How to investigate a problem. How to describe what I do to non technical people. How to handle gobs of traffic. How to handle tumbleweeds (aka no one visiting my blog).

I tell everyone I meet to blog. Not for other people, but for yourself.

Having a record of my life (not the whole thing, but at least some aspect of it). Having a chance to help other people. Even just making the time to sit down and think about something deeply. All huge benefits.

Sometimes my posting schedule is less frequenty (especially when I’m writing elsewhere, as I am now on the Transposit blog), other times I speed up (I wrote 100 blog posts in 100 days, it was great).

Either way, I’ve enjoyed this blog immensely, and appreciate everyone who swings by to read a post, leave a comment, submit to an aggregator or subscribes to new posts.

Thanks for 16 great years!

Announcing: Letters to a New Developer

Blank paper, pencil, lightbulb, eraserI’ve been working on a new project that I’m excited to share here. It’s called Letters to a New Developer. It’s a blog with over forty posts full of advice for people who are just starting out in the field of development.

So much of development is not about code. It’s about teams and processes and organizations and questions. I feel like the traditional education system (whether four year college or bootcamp) does a good job of teaching folks coding fundamentals (what you need to be a programmer) but there is so much more to being a successful developer than coding. In my experience, delivering code is a necessary but not sufficient activity for success in a software company.

That’s why I’ve spent the last five months writing up some of my experiences and learnings.

The posts are mostly mine, but some are from guest posters who bring a different perspective. I also excerpt posts I find on the Internet that I find helpful, so that I can stand on the shoulders of some of the giants who have come before.

Here are some of my favorite Letters To a New Developer posts: Always Be Journaling from Brooke Kuhlmann, Get Used to Failure, and Learning to Read Code is More Important Than Learning to Write It.

I hope you find this project as fun to read as I’ve found it to write.

Fifteen years

Birthday cakeWow. 15 years ago today I wrote my first post. Thank you for reading!

I’ve been blogging for longer than I’ve done any other activity in my life. Longer than any job, any romantic relationship, any hobby.

And I can’t see stopping. Sure, I may use other outlets, but I’m trying to keep the streak of no month going by without a post going (darn you, November 2011!). I think that writing is an essential part of software development and it’s been an essential part of my reflective process. I primarily blog for myself. But it is still fun when folks reach out to me and let me know my writing has helped them in some way. It’s also fun when I google a problem and realize that I’ve already written up an answer.

I encourage everyone I meet to blog. It is a fantastic way to accumulate credibility and expertise. (You never learn something as well as when you are trying to explain it to others.) It also gives me a chance to expound on some of my thoughts around jobs, business, and software development. I’m lucky that my work almost always is something interesting enough to write about, at least once a month. Maybe one of these days I’ll put together a ‘best of’ and make a PDF.

I also think it is important to blog at a place you control. Yes, Medium or Facebook make it easier to gain a following. But what they giveth, they can taketh away. I may only have limited engagement here on this blog, but what I write is mine and will never be anyone else’s.

Hard to believe that my blog will be able to drive next year. Again, thanks for reading.

Where I’m Writing

It’s been a bit quiet around here, but since I joined Culture Foundry I’ve been writing over on their site more. I’ve written on a number of topics, but this one about how to move files between different servers in order to scale a traditional CMS application horizontally, is one of my favs:

Compared to the other methods of syncing files, this works well with non cloud native applications. It also has the virtue of using old tested tools. You can use this system on prem or in the cloud, anywhere with SSH and rsync. This system works well with large numbers of small objects because rsync can be configured to only push new objects.

I’ll be splitting my blogging time between this site and the Culture Foundry site in the future. See you there.

 

My first day at Culture Foundry

I am excited to pen that title. I’ve joined Culture Foundry, a digital agency that connects the world through beautiful technology. There are a number of reasons I accepted a position with this firm, but a few that jump to mind are:

  • they are good people. This is important as a great job with a bad manager is no fun. A great manager can help make a bad job better.
  • they are working on interesting technology problems, including API integrations and high traffic websites.
  • they are 100% remote. This flexibility is really important to me.
  • they work on stuff their clients’ value.
  • the team is big enough to take on larger projects, but small enough to be agile.

For now, I’m going to be drinking from the fire hose, trying to get up to speed on their systems, so the blogging may slow down a bit. But I’ll definitely be sharing things I learn from this new opportunity. Here’s to new adventures!