Joe’s Favourite Podcasts (2018 Edition)

I commute. 75 minutes each way, every day. That’s 2½ hours every day of otherwise slack  time which I like to fill in with some sort of learning, which come from various podcasts I’ve picked up over the years. Here’s my current list, in alphabetical order…


Agile Uprising

agile-uprisingTopics: Software, Agile


Interviews with a lot of the agile manifesto authors, plus a lot more about working and managing agile software projects.

Bad Voltage

bad-voltageTopics: Technology, Open Source, Politics


Jono, Stuart and Jeremy talk about whatever interests them, which often involves technology, open source, Linux, politics, music or whatever else is on their mind. This podcast is the spiritual successor to LUG Radio, which I listened to religiously until it ended(ish) around 2008 (10 years ago!)

Feeling Good

feeling-goodTopics: Behavioural Science, Cognitive Behavioural Therapy


Dr Burns talks about a lot of topics related to communication and understand. This podcast was recommended to my be @Jtf a couple of months ago, and it has rapidly become one of my favourites. A good place to start is Episode 65: The Five Secrets.

HTTP 203

http-203Topics: Web technologies, Javascript


The name of the podcast refers to the HTTP response indicating “Non-Authoritative Information”, which is pretty apt. It’s fun banter between Jake and Surma, two members of the Google Chrome development team.

Late Night Linux

latenightlinux-smTopics: Linux


Late Night Linux is a podcast that takes a look at what’s happening with Linux and the wider tech industry. Every two weeks, Joe, Jesse, Ikey and Félim discuss the latest news and releases, and the broader issues and trends in the world of free and open source software. Expect drinking, swearing, strong opinions and Ikey being told to shut up about Solus.

More or Less: Behind the Stats

more-or-lessTopics: Statistics, General News


OK, I listen to a show about statistics. It’s actually really good! Tim Harford and his team make it a really engaging topic as they rip apart inaccurate numbers reported in the news.

Software Engineering Radio

se-radioTopics: Software Engineering


Software Engineering Radio is a podcast targeted at the professional software developer. It features interviews with experts from the software engineering world about the full range of topics that matter to professional developers.

The Infinite Monkey Cage

infinite-monkey-cageTopics: Science, Brian Cox’s Hair


Brian Cox and Robin Ince host a science/comedy podcast that explores important questions such as “are strawberries alive?”.

The Skeptics’ Guide to the Universe

SGU-LogoTopics: Science, Scepticism


My longest lived podcast. I’ve been listening to this for over 10 years now. I initially found the SGU logical fallacies page, and graduated to the full podcast a year later. Still one of my favourites.


Troubleshooting Agile

troubleshooting-agileTopics: Software development, Agile


Jeff and Squirrel, two CTOs of a company I previously worked at, combine to from mega-agile-CTO in a Voltron style. Troubleshooting Agile is a problem-solving session for agile teams. Jeff and Squirrel look at common problems agile teams face and provide practical, immediately useful advice for getting back on track.

You Are Not So Smart

you-are-not-so-smartTopics: Psychology, Neuroscience


Dave McRaney is awesome as he explores all the various quirks of our brain and psychology. I only started listening to this 6 months ago, and I had to spend the next 4 weeks going over the full back catalog.

Voice of XTC

This podcast doesn’t exist. I’m thinking about trying it, though…

Your Favourites

The above are all my favourites (that I’ve discovered so far). What’s missing? What are your favourites?


Converting to Kotlin

kotlin_250x250After dipping my toe in the water a number of times, I’ve finally taken the plunge. Over the last couple of weeks I’ve been migrating a private project from Java to Kotlin. This is a report of how it’s been going…

Firstly, my main interest in Kotlin was the cleaner language design, the clear Java migration path and good interoperability with the JVM ecosystem. What do I mean by “cleaner language”? The my favourite example are the Kotlin data classes. In my code base, I have a large number of classes deriving from “Event”. Each one of these event classes has a number of attributes, with corresponding getter functions, plus an equals, hashcode and toString function. Here’s one of my classes:

public class LearnerAddedToOrganisation implements Event {

    private final LearnerId learnerId;
    private final OrganisationId organisationId;
    private final UserId agentId;
    private final Instant eventTime;

    public LearnerAddedToOrganisation(LearnerId learnerId, OrganisationId organisationId, UserId agentId, Instant eventTime) {
        this.learnerId = requireNonNull(learnerId);
        this.organisationId = requireNonNull(organisationId);
        this.agentId = requireNonNull(agentId);
        this.eventTime = requireNonNull(eventTime);

    public LearnerId getId() {
        return learnerId;

    public LearnerId getLearnerId() {
        return learnerId;

    public UserId getAgentId() {
        return agentId;

    public Instant eventTime() {
        return eventTime;

    public boolean equals(Object o) {
        if (this == o) {
            return true;
        if (!(o instanceof LearnerAddedToOrganisation)) {
            return false;
        LearnerAddedToOrganisation that = (LearnerAddedToOrganisation) o;
        return Objects.equals(learnerId, that.learnerId) &&
                Objects.equals(organisationId, that.organisationId) &&
                Objects.equals(agentId, that.agentId) &&
                Objects.equals(eventTime, that.eventTime);

    public int hashCode() {
        return Objects.hash(learnerId, organisationId, agentId, eventTime);

    public String toString() {
        return String.format("LearnerAddedToOrganisation{learnerId=%s,organisationId=%s,agentId=%s,eventTime=%s}",
                learnerId, organisationId, agentId, eventId);

Here’s the code for the same class after I converted it to Kotlin:

data class LearnerAddedToOrganisation(
        override val id:                LearnerId,
                 val organisationId:    OrganisationId,
        override val agentId:           UserId,
        override val eventTime:         Instant) : Event {
    val learnerId: LearnerId
        get() = id

This Kotlin code has exactly the same functionality as the Java equivalent, plus it also has a copy function as well.

This conciseness can lead to some large reductions in code size. The module I converted to Kotlin originally had ~8,000 lines of Java code. After conversion, it contained ~4,800 lines of Kotlin, which corresponds to a 40% reduction in code size. This is a significant improvement! Consider that programmer output in terms of lines of code tends to be relatively stable, independent of language. Switching to a language where the same features can be implemented in fewer lines of code means more features can be built.

The more I use Kotlin, the more I find I enjoy using it. I’m definitely going to use it more in the future.

The Hosting of has Changed

This is just an administrative announcement: I have moved to be hosted by It was previously hosted on a EC2 server and database. At the time I moved to AWS, I felt it was an interesting project to learn the AWS tools and infrastructure. In that sense, it was a good way to learn. However, years later I’m running months behind on keeping everything updated with security patches and paying too much for AWS services. Given that 90% of my website was already running under WordPress, I decided to bite the bullet and let manage my site for me, allowing me to kill my EC2 server and save some money.

The transfer wasn’t quite painless: some of the URLs have changed. All the content is still available, but if you have any bookmarks, they may need to be updated, and the RSS feed location has changed too, so you may need to update your subscription.

Software Development is an Engineering Discipline

There is a view that software development is a craft; that “Software Craftsmanship” is a better metaphor for software development than is engineering or science. I’m going to argue against this view: software development is an engineering discipline, and relies strongly on scientific principles. Firstly, what is an engineering? Here’s one definition of the engineering method:

The Engineering Method is the use of heuristics to cause the best change in a poorly understood or uncertain situation within the available resources. – Billy Vaughn Koen

What heuristics? In general, they look something like this:

Engineering method

(from the article “Comparing the Engineering Design Process and the Scientific Method“)

The first thing to notice is the feedback loops here. The steps brainstorm ⇒ develop ⇒ test corresponds to the TDD cycle in software development:

TDD cycle(from “Growing Object-Oriented Software, Guided by Tests“)

The difference between the engineering design process with physical products and TDD in software is mainly the speed of the feedback loop. A skilled developer can often go through the red-green-refactor loop in less than 5 minutes, as there is no physical materials to manipulate. When you then add in the steps specify requirements ⇒ … ⇒ meets requirements around the TDD cycle, you get the ATDD cycle: ATDD Cycle

Depending upon the size of feature that the the acceptance test describes, this could take anywhere from an hour to a week, though high-performing teams learn that quicker feedback is critical to quality.

Zooming out, there is a larger feedback loop surrounding the ATDD loop: the lead time between new software capabilities being prioritised and the capability being used by an end user. The DevOps movement is built on the focus on the software and organisational structures required to get software into the hands of end users as quickly as possible.

The size of the feedback loop is probably the most critical part of successful engineering. Consider, for example, the first human powered flight across the English Channel. The Kremer Prize was established in 1959 to give some motivation to show that human powered flight was both possible, as able to go long distances.

The challenge was picked up by many peoples and teams, but there was very little progress until the problem was examined by Paul MacCready, who noted that the engineers were trying to solve the wrong problem.

MacCready’s insight was that everyone working on solving human-powered flight would spend upwards of a year building an airplane on conjecture and theory without the grounding of empirical tests. Triumphantly, they’d complete their plane and wheel it out for a test flight. Minutes later, a years worth of work would smash into the ground.

The problem was the process itself… He came up with a new problem that he set out to solve: how can you build a plane that could be rebuilt in hours not months. And he did. He built a plane with Mylar, aluminium tubing, and wire.

After two and a half years, MacCready team successfully flew the Gossamer Albatross II across the English Channel in just under 3 hours.

Gossamer Albatross

(Gossamer Albatross II in flight, from Wikimedia Commons, public domain)

Compare this feedback loop to a more traditional engineering discipline based upon something less malleable than software: traffic engineering. This is a branch of civil engineering that uses engineering techniques to achieve the safe and efficient movement of people and goods on roadways. In this case the engineering medium is road signs, lane markings, asphalt, road size and shape. In some cases, the traffic engineer will look to move roads through entire buildings. The behaviour of traffic can be very complex, with surprising effects from interventions (think of adding a lane to a busy road, causing induced demand, causing worse traffic delays). In all these examples, the feedback loop for understanding if the intervention was successful can range anywhere from days to years. In order to reduce the risk of untested changes, traffic engineers must use models of the road, and run the simulation in software.

In summary: software development that makes use of feedback loops to help understand and direct the problem solution is most definitely engineering.

One question is left to ask: where does Software Craftsmanship fit in the context of software engineering? My take is that Craftsmanship is the focus on the skills that are known to be effective, a body of knowledge on the techniques that are effective. Engineering without skills won’t get you very far. Skills without engineering means that you can build the wrong thing very well. Both are required.

(This post was prompted by a discussion between Dave Farley and myself when we were both at the book launch of Infrastructure as Code by Kief Morris. A subsequent discussion with Andy Parker helped refine the topic)

Devops 101

I recently saw a reference to Devops 101 on Twitter. It looked interesting, so I bookmarked it, and forgot about it for a few weeks.

Devops 101 - Part 4

Last night I finally got around to trying the exercises – it was a bit of an eye-opener. There’s a huge amount of functionality on AWS that I’m not really up-to-date with (and I say this as a person who has been running an AWS EC2 instance for many years now).

The “101” part of the name implies that it’s a starting place for graduate developers. I would clarify to say that it’s very useful for anyone who isn’t working on infrastructure-as-code day to day. If you’re developer who is not yet embedded in a team working devopsly, give it a go.

I had never had a chance to place with the AWS command line, and leveraging that with cloudformation and ansible was an real pleasure to use.

I previously worked at a company where we had built our own stack builder tool. I never got to grips with it at the time, but I now want to go over it again.


Well, I finally received an invitation to join My Keybase profile is:

I first heard about Keybase from a post by Tim Bray in March. I’ve been quite interested in crypto stuff since forever, but I’ve never been able to use it consistently in all my communications. Given the increasing surveillance issues on-line, it seems prudent to increase use of encryption, but it’s still very hard when pretty much everyone I would ever chat with can’t decrypt. Wider use of tools like GPG and usability wrappers like Keybase might improve the situation. As a first step, this is my announcement of my public key and availability to receive encrypted messages, should you so desire.

Keybase is currently still in a closed alpha. You can request to join, but it will probably take a while (it was 6 months for me). Even without Keybase, you can still use GPG directly, just retrieve my public key from