Destroy All Software With Gary Bernhardt - Episode 159


Many developers enter the market from backgrounds that don’t involve a computer science degree, which can lead to blind spots of how to approach certain types of problems. Gary Bernhardt produces screen casts and articles that aim to teach these principles with code to make them approachable and easy to understand. In this episode Gary discusses his views on the state of software education, both in academia and bootcamps, the theoretical concepts that he finds most useful in his work, and some thoughts on how to build better software.

linode-banner-sponsor-largeDo you want to try out some of the tools and applications that you heard about on Podcast.__init__? Do you have a side project that you want to share with the world? Check out Linode at or use the code podcastinit2018 and get a $20 credit to try out their fast and reliable Linux virtual servers. They’ve got lightning fast networking and SSD servers with plenty of power and storage to run whatever you want to experiment on.

GoCD is the on-premise open source continuous delivery server created by ThoughtWorks and modeled after the ideas in the Continuous Delivery book by Jez Humble and David Farley.

With GoCD’s comprehensive pipeline modeling, you can model complex workflows for multiple teams with ease. And GoCD’s Value Stream Map lets you track a change from commit to deploy at a glance.

GoCD’s real power is in the visibility it provides over your end-to-end workflow. So you get complete control of and visibility into your deployments, across multiple teams.

Say goodbye to deployment panic and hello to consistent, predictable deliveries.

To learn more about GoCD, visit for a free download. Professional Support and enterprise add-ons, including disaster recovery, are available.

When your website experiences an error, Airbrake alerts you in real-time, and gives you all the details you need to fix the bug fast. Some of the most useful tools that Airbrake provides for faster resolution are:

  • Exception aggregation to understand the how many users are being affected, so that you can prioritize the work you are doing to have the biggest impact
  • Contextual information to understand how certain states of the application contribute to the exception being raised, and which environments are affected
  • Deployment tracking so that you can easily see whether a new feature is the source of an error
  • Integration with all of the other tools that you use, such as automatically creating issues in GitHub and linking to the line of code where the error came from

Right now, Podcast.__init__ listeners can try Airbrake free for 30 days, plus get 50% off the first 3 months on the Startup plan. To get started, visit today.


  • Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
  • When you’re ready to launch your next app you’ll need somewhere to deploy it, so check out Linode. With private networking, shared block storage, node balancers, and a 200Gbit network, all controlled by a brand new API you’ve got everything you need to scale up. Go to to get a $20 credit and launch a new server in under a minute.
  • Finding a bug in production is never a fun experience, especially when your users find it first. Airbrake error monitoring ensures that you will always be the first to know so you can deploy a fix before anyone is impacted. With open source agents for Python 2 and 3 it’s easy to get started, and the automatic aggregations, contextual information, and deployment tracking ensure that you don’t waste time pinpointing what went wrong. Go to today to sign up and get your first 30 days free, and 50% off 3 months of the Startup plan.
  • To get worry-free releases download GoCD, the open source continous delivery server built by Thoughworks. You can use their pipeline modeling and value stream map to build, control and monitor every step from commit to deployment in one place. And with their new Kubernetes integration it’s even easier to deploy and scale your build agents. Go to to learn more about their professional support services and enterprise add-ons.
  • Visit the site to subscribe to the show, sign up for the newsletter, and read the show notes. And if you have any questions, comments, or suggestions I would love to hear them. You can reach me on Twitter at @Podcast__init__ or email [email protected])
  • Your host as usual is Tobias Macey and today I’m interviewing Gary Bernhardt about teaching and learning Python in the current software landscape


  • Introductions
  • How did you get introduced to Python?
  • As someone who makes a living from teaching aspects of programming what is your view on the state of software education?
    • What are some of the ways that we as an industry can improve the experience of new developers?
    • What are we doing right?
  • You spend a lot of time exploring some of the fundamental aspects of programming and computation. What are some of the lessons that you have learned which transcend software languages?
    • Utility of graphs in understanding software
    • Mechanical sympathy
  • What are the benefits of ‘from scratch’ tutorials that explore the steps involved in building simple versions of complex topics such as compilers or web frameworks?

Keep In Touch



The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA

Notable Replies

  1. Enjoyed the show very much. One comment: since Gary seems concerned that there are undecidable problems in the static analysis of Python, he may need to be aware that type checking in the ML type system that he seems to endorse so strongly is complete for EXP time. Which means neither works in a worst case sense, but it seems they both work enough in practice. Unfortunately theoretical analysis, which is largely worst case analysis, has shown time and again quite a gap from reality (the simplex is a practical worst case exponential algorithm, whereas there aren’t so many n^10 algorithms in practical use). This happens because the infinite set of slow or undecidable instances for a problem may be a negligible fraction of possible instances. Another observation about type systems is that they allow to check some, not all, interesting properties of a program at compile time in exchange for a certain loss of expressivity, that is additional lines of code needed to express a computation. This is simply because the shortest possible expression of a computation may not type check. This is also observed in practice looking at projects in different languages. The evidence that statically typed languages have fewer bugs per line is weak if it does at all exist, even if it stands to reason that if type checking excludes incorrect computations before they run, it should be helpful. So it is a trade off between the useful constrains one adds to a program to be statically less buggy and the additional verbosity required by type checking. The java.array.util library used to contain this comment: “The code for each of the seven primitive types is largely identical. C’est la vie.” That’s a blatant example of type checking and efficiency requirements (the arrays are “unboxed”, no pointers) causing a 7x code bloat. As Gary said, don’t look at Java, but the ML type system is EXP-time complete. That can’t be good either. The alternative is to check properties at run time with assertions. This is infinitely easier but it can cost in execution time an cause crashes in production. Complement with randomized testing, and you have the best of both worlds: simple property checking on concrete data, not types, and catching most errors before production. It seems to me the sw world is slowly voting with its keyboards for this approach.

Continue the discussion