WTF is WTF#?

What? | How? | Why? | Next Steps?

WTF# is a podcast about the F# programming language. It's a side project of mine that's connected my enjoyment of the language itself to something larger, forcing me to dive into topics from audio editing to coordinating multi-time-zone meetings for recording sessions. As with any side project, my little venture has taken me down rabbit holes and emotional conflicts; my F# Advent 2018 contribution as follows is a simple reflection of what it takes to run a podcast, explanation for why it took over a year to get 6 episodes out (ha!), and a sneak peek at WTF#'s eventual future.


(Hey! If you don't know the F# programming language, that's ok!
I'd recommend checking out and F# for Fun and Profit to learn more about the language. That said, this post should make sense regardless of your F# experience.)

Who am I?

and why do I think anyone should listen to what I have to say about F#?

Hey, I'm Stachu (the bald guy in the center).

I'm not the best F# or functional programmer.
I haven't written type providers, touched the compiler's source code, and I still don't quite know what a monad is. It's incredibly easy for me to look at that data and feel like an imposter, as if someone else would be so much better off as a podcast host.

That said, I do use and love F#, and passion usually takes you further than raw knowledge, in my experience.

I've been toying with F# for ~5 years now; I've read the blog posts, the books, watched the courses, attended the conferences, gave F# talks at various user groups and conferences, etc. Heck, I even met my wife after giving an F# talk (true story!).

Anyway, I'm pretty into F#, but I'm not quite as smart as the people who push forward the technical stuff. As such, I think 2 quotes are relevant:

  • "Those who can, do; those who can't, teach"
  • "Great men are forged in fire. It is the privilege of lesser men to light the flame."


I had no idea getting a podcast out would be so hard. Between infrastructure (one-time, up-front work) and per-episode effort, podcasting is not for the faint of heart.

I'll break down effort related to "podcasting" into 4 major categories,
Organization, Recording, Editing, and Distribution, and discuss them individually.


Getting guests and topics

I'm interested in understanding all use cases for F# at some level (from embedded systems to cross-cloud computation abstractions), and I believe that a broad F# podcast has higher entertainment/educational value than one with too narrow a focus. Thus, I've set myself up with a system to have a rough knowledge of and keep in ---touch with the F# ecosystem at large, consisting of:

  • Twitter
    As silly as it sounds, I get most of my programming news by following "software people" on Twitter, and checking the app (at least) daily to see what people are doing. Social media gets a bad rap sometimes due to privacy concerns, but the value of connecting you to far-away "nodes" in the graph of people still rings true.
  • Slack
    The F# Software Foundation hosts a Slack group with a lot of F#-related rooms - everything from language design (#langdesign) to getting an F# job (#jobs). It's often useful to peek into each room one-by-one and discover what's going on in all of the little sub-spaces.
  • GitHub
    I get emails about every GitHub issue related to F# that I can handle.
    Every repository that I'm interested in, I "watch" so that issues and PRs are sent to my inbox on a regular basis. This helps me stay current on the secret stuff before it hits Twitter. (sneak peek of Fable 2.0 REPL? Lovely. Internal discussions of SAFE Stack decisions? Sweet.)
  • Conferences
    My wife and I went to 3 F# conferences this year; London for F# Exchange in April, San Francisco for Open F# in September, and Berlin for FableConf in October.
    These conferences helped me connect with many F# users and speak to them on a more personal level than you typically get purely over the internet.
    (by the way, all 3 conferences are worth showing up to! Just probably not all 3 in a single year... some vacations have to not include computers.)
  • F# Weekly
    Sergey's F# Weekly is a great summary of what public activity happens in the F# world on a particular week.
  • Reddit
    Although not a very active subreddit, there is discussion over at /r/fsharp that provides a fresh perspective. I find that /r/fsharp's discussions of F# are often negative, and I see value in reading through this, as Twitter tends to be a positivity-bubble in the F# space.

These sources help me have a feel for where F#'s over-all ecosystem is, where it's heading, and gets me somewhat comfortable in understanding which topics in the broad F# space are appropriate for a general audience via audio.

Getting guests given those topics... is harder.
There are a few sub-challenges here:

  • finding F# people that I have an "in" with, so I feel comfortable in taking their time
  • pairing a guest with a specific topic of the form "WTF# is ___?"
  • having an initial conversation to "discover" the topic a bit, and at a high level hit the topics we'd like to make a recording about
  • scheduling the actual recording, which is tough due to time-zone differences and the fact that... well, people have other things going on :)
  • getting a guest comfortable in being recorded

I haven't gotten this science down yet, so I won't bother expanding here much.
(That said, if YOU want to be a guest for the WTF# podcast, check out the GitHub issues here: Feel free to sign up for a topic, or create a new issue. Read the

Structuring an episode and creating show notes

Once I have a guest paired with a topic, the flow goes something like this:

  • 15-min skype / zoom / hangouts call between myself and the guest to discuss at a high level what we can cover in an episode of 30-60mins
  • I create a rough episode outline and provide the document to the guest
  • Guest makes any relevant updates to that structure
  • We have a ~90min recording call together
  • I update the outline with show notes that I'll later use
  • I ask the guest to spend some time altering the show notes as they wish
  • I re-record the intro, for my own sake
  • I sent the audio to @fergusmeiklejohn and he gets it back to me
  • I sit through the final audio and adjust show notes as I listen
  • I upload the audio to my podcast host (, adding show notes, and publishing

Throughout this flow, you'll notice that there's "adjustment" of the structure of an episode long before recording, and by all parties involved. I find it important to keep the conversation "real" and not too rehearsed, but I'm also not about to waste the listeners' time wandering in conversation; as such, I feel a need to create a well-formed structure to guide the conversation in a useful way.

There are a number of tools I use in the process of developing show notes

  • My reMarkable tablet [link!]
    I love this thing. It's pretty expensive, but it's been worth the purchase.
    Basically, it's a Kindle (or any other eReader) that you can write on, feels (almost) like writing on paper, and exports files to .pdf.
    Specific to the podcast: after my initial (short) conversation with a guest, I'll take my tablet, and spend a half hour simply sketching out the outline of a potential conversation on "paper." Typically, I'll go to a coffee shop or library, hiding away with just the tablet and some music, to digest in peace. Then, I'll go home and upload the writings (via an emailed .pdf file that the reMarkable software provides) to my computer, and transcribe the notes onto a Dynalist document.
    Here's a sample use of the tablet, in creating this blog post:
  • Dynalist [link!]
    Dynalist is an organization tool centralized around nested bullet lists, and is my favorite piece of software out there.
    Specific to WTF#, I create a document (e.g. "WTF# is Fable?"), enter my sketched-out outline into the document, and massage the bullet points around each other, filling the outline in where appropriate. This is also how I write my talks for user groups and conferences.
  • Time and sleep
    Taking the time to sleep on an episode is key; per-episode, I aim to fall asleep thinking about an upcoming WTF# episode for one night, allowing my sleeping brain to contemplate the subject before another outline-massage.

Throughout the whole process, the intended audience must be kept in mind. My target audience is any sort of software developer curious about F#, which is a pretty wide net - as such, I have to consider topics that are approachable without too many dependencies I haven't covered, and guests that are able to express both their knowledge and passion to a beginner audience. Sometimes, this requires coaching of a guest, telling them to go back and clarify points, or to skip certain topics that may alienate a large portion of the audience.


Recording a podcast can be very awkward at first. And later. Most people aren't used to being recorded and published, and they get a bit nervous. That said, after talking down a guest, there are just a few components to recording:

The Hardware

To record a podcast, you basically need:

  • A computer. Pretty much anything will do.
  • A microphone. Any external microphone should be ok. Some sort of pop filter (meshy black thing on my microphone below) gets you some bonus points.

Personally, I have a Blue Yeti microphone ($125 on Amazon) connected to my HP Spectre x360 laptop. You can see my set-up here:

I'm still not a full-on audio nerd, so I won't expand here too much.

The Software

If I'm recording in-person, I use a (free) software called Audacity. It's really easy. All I have to do is hook up my microphone, set the gain (on the hardware of the actual mic), open up Audacity, position the microphone appropriately, and hit the record button. Easy (after doing a bit of research on microphone-positioning).

If I'm recording someone remotely, I'll use a software called "Cast." With this software, I (1) log in, (2) start a recording session, (3) copy the 'guest link' that the software provides, (4) send the link to the guest, and then (5) hit the magic 'record' button. At the end of the recording session, the software spits out 2 audio files (one for me and one for them) and I have my audio.

The Process

Throughout recording, I'll have a print-out of the Dynalist document that I've shared with the guest, and simply work through it. I start out with an introduction, attempt to hit each of the major points with the guest, and in general just try to keep the conversation light.

Generally speaking, the actual recording process is the least stressful thing on my end; having an outline ready ahead of time means that we have topics to fall back easily if conversation gets dry or off-topic.


The podcast is recorded, but there's plenty of work left! Open up your favorite audio editor (mine is Audacity) and get to work.

At the end of a recording session, I'll have about 90 minutes of mostly good content. At points in recording, we'll go off topic or get dry, or 'umm' and there are many subtle corrections to make before exporting to the wild, not to mention the music that surrounds the main content.

If I output a 50-minute show and 1000 people listen to the whole thing, that's 50,000 humans minutes (34 human DAYS) spent listening to the content. If it's not pruned, I'm doing the public a large disservice. If I can cut a 60minute episode down to a 50minute episode without taking out any actual content, I've saved the human population a fair amount of time they could better utilize.

Back when I edited my own audio (more on that in a minute), I took two major passes through the audio to try to "save human time":

  1. Getting rid of bad content
    In the first pass, I'll listen to the episode fully, and remove any redundant sections of audio. Per episode, I'm typically able to remove up to 30 seconds at a time in redundant chunks of audio - people, including myself, tend to repeat themselves a bit much.
  2. Getting rid of distracting/useless 'fillers'
    In the second pass, I'll get rid of more minor blips - coughs, sneezes, 'ummms', dog barks, etc. This is much less exciting, but funny patterns seem to emerge.. for example, I know pretty well how the audio waves of my 'umms' look like in Audacity! When you're in an editing groove, it becomes possible to visually see someone saying an 'umm' and highlight it to delete after verification.

Beyond focusing on time and content quality, it's nice to add a bit of spice to the podcast in the form of music.

Music isn't (always) free, and I saw 3 obvious options to satisfy this need:

  • Create my own music (hard. too much time.)
  • Find free royalty-free music. (lots of unintersting music to weed through)
  • Pay for music via PremiumBeats or a similar service (not free)

For a day or so, I perused through PremiumBeats' selection (worth going through) but eventually I landed on a 4th option - begging bands I like for free usage in my podcast.

Long story short, there's a band called Boxed Wine in New Jersey that I stumbled upon via BandCamp, and sent them an email. A few days later, I got permission to use their song "Into the Nite" for WTF# for free. Pretty cool - sometimes you just need to ask nicely!


Fortunately for me, I no longer edit the audio myself.
A kind F# enthusiast, Fergus Meikeljohn, offered to edit WTF#'s audio for me, and so I presently don't have to go through the above struggles. (thanks, Fergus!)


I'm not about to burn the podcast audio to CDs and mail them to interested parties, so suddenly I needed to think about:

  • A podcast host and website
    A podcast host is a service that hosts and serves the audio files.
    Related, a website helps to provide more than a simple RSS feed for a podcast (what fun would that be?)
    There are many single-purpose podcast hosts available on the market, with varying price range, but the one I went with eventually was, as they also provide a free, accompanying website that's very easy to manage.
  • Art/graphics
    Text and audio? Not enough - we need pretty pictures, too.
    For fun, I sketched out a few ideas for a logo, and got in communication with an artist/designer who could bring the ideas to life. After some exchanged monies and a few iterations, I got a bunch of images back to use as I wish, for the website and social media. (thanks, Nadya!)
  • Podcast app support
    There are so many podcast applications... from Apple Podcasts to Overcast.
    The science of getting your podcast onto these apps is not simple, and I don't have the space here to cover the material. Google is your friend.
    (I still haven't gotten the podcast on Apple Podcasts - very frustrating for me, too!)
  • promotion (via social media)
    Naturally, no one is going to hear about WTF# unless I promote it.
    So, I created a twitter account and use/promote that wherever I can as a main source of WTF#-related news.


Organizing a podcast is a lot of effort, and I've gotten $0 for it.

Actually, I've spent a few-hundred $ on the podcast so far, between domain ( $12/year ), microphone ( $125 ), hosting ( $19/mo ), recording software ( $10/mo ), related travel, etc. I could do it for cheaper or free, but I'm a lazy man - I like conveniences.


Every episode of WTF# has been a fun adventure for me.

  1. WTF# is Fable?
    F# has traditionally been a .NET language. With Fable (a lovely F#->JS compiler), we now have an opportunity to target client-side web development as a core target of the F# language, a totally different world than back-end .NET development. Do you remember when Node came out, and dynamically-typing developers everywhere were excited by the promise of full-stack development in one language? With Fable, I now have that same excitement, but for statically-typed functional programming!
    Recording an initial episode of WTF# on Fable gave me a great excuse to dive deeply into a subject that I knew wouldn't be use at my at-the-time employer with a concrete goal: give an overview, for about an hour. Further, it got me in touch with the Fable community.
    And deeply I did dive... my "outline" for the first episode was an excessive 3 pages, front and back:
  2. WTF# is Concurrency?
    For the second episode, I interviewed Riccardo Terrell, who had been writing his book "Concurrency in .NET" at the time. We had met before on several occasions, but decided to take the drive down to D.C. where he lived at the time and record in-person. It was a great time to talk about this content fresh in Riccardo's head, and occasionally wait for his pugs to stop barking so we could record again. :)
  3. WTF# is the F# Mentorship Program?
    At this point, I decided that it would be best to tackle something non-technical once in a while; a history lesson, discussions on employability, etc. Luckily at the time, Gien Verschatse was planning another round of the F# Mentorship Program. I had the opportunity of making a friend all the way over in Belgium while discussing the education of F# - fun!
  4. WTF# is the SAFE Stack?
    Until this point, my back-end F# web development had been with done with traditional (not F#-specific) .NET web libraries (Web API, NancyFx, etc.). I tried out Suave at some point, but hadn't had much exposure to the frameworks available.
    Through this episode, I was able to interview a leading expert on F# web development, Isaac Abraham. Isaac is a dominant force in this space, and it was a pleasure to speak to him. Further, Isaac recently had come out with his book "Get Programming with F#," which I believe to be the best F# book out there, and it was nice to speak about that briefly.
  5. WTF# is Elmish?
    I packed about 50 Rubik's Cubes and a heavy microphone in my suitcase to take with to San Francisco to Open F# 2018.
    While there, Alfonso Garcia-Caro (creator of Fable) and Kunjan Dalal (avid F# blogger and maintainer of awesome-fable) were available to record an episode of WTF#... so, we stole a room at the conference venue, and talked about Elmish for a while. It was a bit less structured than a normal episode, but it was fantastic to sit with them and listen to their passion for the language and its ecosystem. Although previously familiar with Elmish, I found Alfonso and Kunjan's take on the subject to open my eyes further, and caused me to look into the Elmish.Bridge library further.
  6. WTF# is Live Coding?
    (released the same day as this blog post!)
    (edit: ok, I have to go to sleep now. I'll publish it tomorrow; I promise.)
    One day on Twitter, I stumbled upon something interesting ... someone teaching F# via Twitch, a platform typically used to stream video game playing.
    Long story short, Gareth Hubball introduced me to a totally new (to me) world of streaming software development. I still can't watch a software developer's Twitch stream and work (too distracting!) but I highly appreciate being able to peek into that world, and share that learning experience with others.

I'm Selfish.

The adventures that come along with each episode aren't the only reasons to pursue podcasting. There are some notable selfish benefits to producing a podcast that I've seen:

  • Employability. People tend think you're smart if you give any sort of presentation... even if you're not!
  • Recruiting. In my career, I've made sure to keep in touch with the good recruiters and developers. Where I can, I try to match these people up where I suppose an opportunity could be had. Through this, I've managed to make some money in referrals, while not spamming devs. WTF# gives me yet another channel to get into contact with developers for this purpose. (p.s. if you're looking for a job or a dev., bug me! I only connect people if I think there's a very good chance there's a match)
  • Breadth <- breadth + 1. In software development, it's very easy to get stuck into one part of the WIDE software development world. I have predominantly done full-stack web development in my career; as such, I'm typically most exposed to that world, seeing updates in JavaScript frameworks far more than I listen into the worlds of game development or natural language processing. Hosting a language-specific podcast allows/forces me to explore a broader landscape. How does MonoGame work? Normally, I would have no idea without doing a lot of reserach or changing jobs. Alternatively, I can find some F# person that uses MonoGame, and ask them questions about this other world for an hour straight - and they'll thank me for it! How cool?
  • Speaking/Writing Experience. My long-term ambitions demand strong writing and speaking skills, applied to a wide audience. Be it technical evangelism, hosting parties, leading a company, or writing software for a living, these skills apply universally, and as such I've been delighted by the fun experience here.

Next Steps?

So, the podcast is there. It exists. Woo-hoo!
Yet, I want more, and have a few concerns regarding WTF# still:

  • frequency/consistency of releases
  • getting a consistent and wide array of podcast guests
  • limited website functionality
  • social media efficacy

Presently, I have been refactoring the infrastructure of the relevant operations; communications happen through GitHub, I no longer edit my audio, I have a backlist of topics in mind available for public viewing, and I am moving the user-facing website to an open-source solution rather than the site included with my podcast host. These refactorings are making for a much smoother per-episode effort on my end, which should allow me to get more content out - though, you know how life is!

Beyond a Podcast?

I have, sketched out, intentions of turning the site into a central learning resource - bridging a gap between GitHub OSS, Slack/Twitter community, and fantastic learning resources such as F# for Fun and Profit. By next FsAdvent (2019), I expect the domain to be split into two sections: Learn and Contribute, providing context for developers to both take the world on with the F# language, and contribute to the F# ecosystem in an organized way. More to come in ~February (so April).


It's been a fun adventure recording WTF# so far, and I'm looking forward to continuing it. If you're curious in some stats, I have some pretty charts below.


too long; didn't read

Man has obsession with programming language, bugs people on Twitter to talk to him, and then publishes recordings of their conversations for other software developers to listen to. Writes a whole thing about it.

Thanks for reading! Want to get in touch?

  • Email: hello at stachu dot net
  • GitHub, Twitter, FaceBook: @stachudotnet