I'm a .NET Core Contractor, Podcast editor, and host of both The .NET Core Podcast and The Waffling Taylors. Ask me anything!

My normal weekday looks like:

• 5:45am alarm goes off
• 6:00am shower, etc.
• 6:30am breakfast and download the latest episodes of my podcast subscriptions (I currently subscribe to 94 shows)
• 7:00am commute to work
• 9:00am to 1:00pm work
• 1:00pm - 2:00pm lunch
• 2:00pm to 17:30pm work
  • the whole time, I'm writing code and listening to podcasts
• 17:30pm commute home
• 18:30pm gym for an hour
  • not every day, though
• 19:00pm dinner
• 20:00pm to 22:00pm podcast stuff
  • editing episodes, writing show notes, mixed in with helping the little ones with their homework
• 22:30pm bed
  • although most days extend up to midnight

I'll fit podcast interviews (guests on my shows) into my day, too. But I plan them around the availability of my guests.

Weekends are completely different, as I tend to spend one Saturday a month recording a month's worth of episodes for Waffling Taylors. But mostly, it's family and chill out time.

Ooh! I love that question. But my answer might have to be equally as broad.

The first thing you need is a plan. What do you want to achieve? Be as specific as you possibly can, but also acknowledge that there are:

• known knowns; things that you are aware that you know about -known unknowns; things that you aware that you don't know about
• unknown unknowns; things that you are not aware that you don't know about

Then take a look at how you think this new transition might affect you and your dependents - you may not have dependents, and that's fine, but you are dependent on yourself.

If it's career related, like going full time or moving to contracting work, do a full budget. Take the time to figure out precisely what your finances are, and how much you need to survive for 3 months. Then have at least that much banked before you do ANYTHING. With contracting, you will typically lose any employment benefits that a full time employee has (medical insurance, paid sick leave, etc.), so what happens to your bills and dependents if you become sick? You need to know these things.

Be aware that a big change can have both positive and negative effects. And you need to try and be aware of both of these sides of the coin before you can make a decision. Try and think of it as being similar to informed consent, but you have to inform yourself. But that's hard because of the unknown unknowns.

To combat those unknown unknowns, seek out other people who have done the same. Maybe see if there are meetups or professionals that you can talk with. When I was thinking of changing to being a contractor, I spoke with all of my contractor friends. I also went to seek legal and financial advice (I have experts in those areas in my family, and while they couldn't advise me as a professional, they helped me finding the questions thay I should be asking).

In summation, and to quote Scar from The Lion King:

Be prepared.

So I started the podcast after realising that my blog posts on .NET Core where starting to get longer and longer. One of the longest blog posts clocks in at around three and a half thousand words, which isn't that long for a technical post. But it meant that I was spending a lot of time writing the article and creating the source code to go alongside it.

Mix this in with the fact that I'm an auditory learner - I'm actually listening to an episode of the Retro Asylum podcast as I type this comment - and I started to see that audio would be easier to work with.

I started by writing the first 10 monologues. I figured that if I couldn't come up with content for the first 10 episodes, then I wouldn't be able to come up with enough content to keep the show going. I did this by spending an afternoon at a local coffee shop with a notebook and a pen.

I do all of the production myself: writing questions for guests; interviewing guests; writing the monologues; editing the show; creating the show notes (including the transcriptions); publicising the show; reaching out to guests; etc. As such I spend a lot of time working on the show. A year ago, I would be editing audio over lunch breaks at work and rushing home to continue to produce all evening.

But, since then I've levelled up with my productivity. One of the things that I've walked away from is what Richard Campbell called "The anti-umm thing" (when I interviewed him). To quote Jay Miller (of Productivity in Tech):

For each half an hour of audio, it'll take me around an hour to edit. If you tell me the remove the "umms" and "errs", it'll take another hour to edit that same 30 minutes.

I also dropped from one episode a week to one episode per fortnight. This really helped with the pressure to get the show edited down.

If you're looking to create a podcast, make sure that you really want to do it. It requires a lot of effort, and you need to be sure that you have a large amount of content planned and ready to go before you start. Otherwise you'll run out of content and either podfade or you'll end up putting out low quality, filler episodes.

Also, accept that the first four or five episodes that you record will be terrible. This is because you'll still be trying to figure out what your show should sound like, or what your radio voice sounds like.

You also need to accept that gaining followers with podcasting is a marathon rather than a sprint. Unless you find a super specific niche, you'll find that it will take a long time to gain a good enough following.

I can certainly recommend loads of podcasts. I have two lists on Podchaser:

• Essential Developer Podcasts which is quite short
• My 2019 Podcast Subscription List which has almost everything that I currently subscribe to (some of the shows aren't in podchaser's library).

I'd heartily recommend:

• 99% Invisible
• Arcade Attack
• Pop Culture Happy Hour
• We're Alive
• Clear+Vivid with Alan Alda
• The Feed: The Official Libsyn Podcast
• KEXP Song of the Day

What's great about .NET 5 is that they're bringing Xamarin, Core, and Mono together. With that we'll get native, cross platform access to the Mono linker and tool chain.

My biggest hope for .NET 5 is installed templates not being wiped out with SDK updates. So right now, if you install a dotnet new template then update the installation of the SDK, the template will disappear. I created an issue on GitHub for this, after asking about it on Twitter.

But the most exciting thing to me is the rolling release schedule in .NET 5. Traditionally, Framework is tied to the Windows Kernel. This means that they can't issue updates out of band for Windows. Which means that updates for Framework have always been super slow. Especially since there's nearly 20 years of apps which NEED to keep running, exactly the way that they have before, when a Framework update is released.

But .NET 5 (and beyond) is going to have yearly releases, meaning that we'll get access to new features on a very rapid release cycle. Thinking thay we could have a new feature announced, trialed, previewed, and into our production code bases in less than a year is incredibly exciting to me.

I've just updated the post to include:

Please post any questions that you have as comments on this article.

If you'd have asked me how I prioritise tasks 2 years ago, I'd have said that I firefight. But these days, I take a look at what can allow me to check off the most at once.

One of the things which has helped me a lot recently, and it's super low tech, is pen and paper. Like, I'll write the heading:

What Do I Have?

And list everything that I have about a task. Do I have the spec for a job? Do I have access to documentations? Do I have the audio that I want to edit? Do I have the tools that I need?

Then I'll write the heading:

What Do I Want?

And list what I want the end result to be, in as much detail. For example, I might put something like:

To take this 80 minute audio, remove all of the dead air and multiple takes for certain questions, add indents, add an intro and outro, and mix it ready for release

That way, I can see the list of steps that I need to take to get to the final result, and precisely what that final result will be.

Then I'll make a check list of steps to perform, and check them off, one by one, until they're done.

The biggest thing to remember is that the individual tasks will take as long as they take. And if they go over, then it's not the end of the world.

So I've done this recently with Hugo. What I did for that was find out the bare minimum that I need to be able to build something with it (in this case, ensure that both Go and the hugo cli app are installed).

The next thing that I do is figure out a project that I can get some use out of, and start building it with the new technology. In the case of Hugo, I started recreating the Waffling Taylors website with it, implementing a new design as I went along.

Once I've scratched the surface enough, I'll go back and look into how the technology actually works. That way, I can better understand the inner workings and the design decisions for the technology.

Oh man. I get this at around 8pm on a Wednesday night.

My goto strategy is to take a short break and do something completely different. So when I'm 2 hours into editing some audio and I get all antsy, or just want to give up, I get up from my chair, head outside and walk around the block. Granted UK blocks are a lot smaller than most of the world, but it clears my head.

But if I haven't started the task yet, and I really don't wanna, what I'll do is get myself into a position where I should have already started. So when I used to go running all the time, I'd get changed into my running gear and go stand by the front door. It seemed pointless to be standing there, ready to go, knowing that I'd have to get changed again if I didn't go. So I kind of procrastinated myself into running.

It's what I call the Professor Farnsworth dilemma.