
Building actually maintainable software ♻️ (Interview)
Streams straight from the publisher. podnod never proxies or re-hosts episode audio.
This week we’re sharing the most popular episode of Go Time from last year — Go Time #196. We believe this episode was the most popular because it’s all about building actually maintainable software and what goes into that. Kris Brandow is joined by Johnny Boursiquot, Ian Lopshire, and Sam Boyer. There’s lots of hot takes, disagreements, and unpopular opinions.
This is part two of a three part mini-series led by Kris on maintenance. Make sure you check out Go Time #195 and Go Time #202 to continue the series.
Changelog++ members save 6 minutes on this episode because they made the ads disappear. Join today!
Sponsors:
- InfluxData – All of the open source software InfluxData creates is either MIT-licensed or Apache2-licensed. These are very permissive licenses. But why are they all for permissive licenses? Paul Dix shares his thoughts on the spirit of open source and why freedom, evolution, and impact drive them to license InfluxData’s open source software as permissively possible. Learn more at influxdata.com/changelog
- Square – Develop on the platform that sellers trust. There is a massive opportunity for developers to support Square sellers by building apps for today’s business needs. Learn more at changelog.com/square to dive into the docs, APIs, SDKs and to create your Square Developer account — tell them Changelog sent you.
- Honeycomb – Guess less, know more. When production is running slow, it’s hard to know where problems originate: is it your application code, users, or the underlying systems? With Honeycomb you get a fast, unified, and clear understanding of the one thing driving your business: production. Join the swarm and try Honeycomb free today at honeycomb.io/changelog
- Retool – The low-code platform for developers to build internal tools — Some of the best teams out there trust Retool…Brex, Coinbase, Plaid, Doordash, LegalGenius, Amazon, Allbirds, Peloton, and so many more – the developers at these teams trust Retool as the platform to build their internal tools. Try it free at retool.com/changelog
Featuring:
- sam boyer – GitHub, X
- Ian Lopshire – GitHub, X
- Kris Brandow – GitHub, X
- Johnny Boursiquot – Website, GitHub, X
Show Notes:
- Go Time #195
- Go Time #202
- Uber’s Go Style Guide
- Why smart engineers write bad code
- Rant about “performant”
Something missing or broken? PRs welcome!
Go Time #196
gotime.fmGo Time #195
gotime.fmGo Time #202
gotime.fmJoin the discussion
changelog.zulipchat.comChangelog++
changelog.comInfluxData
influxdata.comSquare
changelog.comHoneycomb
honeycomb.ioRetool
retool.comGitHub
github.comX
x.comGitHub
github.comX
x.comGitHub
github.comX
x.comWebsite
jboursiquot.comGitHub
github.comX
x.comUber’s Go Style Guide
github.comWhy smart engineers write bad code
changelog.fmRant about “performant”
youtu.bePRs welcome!
github.com
- 0:00Intro
- 1:15Sponsor: InfluxData
- 3:09Welcome to Go Time!
- 5:16Let's talk about maintenance
- 7:46Johnny brings the heat
- 10:31What does 'Maintainable' mean?
- 14:25What does 'Un-maintainable' mean?
- 17:33Code that's untestable
- 20:55How does code become unmaintainable?
- 23:33Sponsor: Square
- 24:49Performant is a made up word
- 27:42Grafana's 'Gardening Week'
- 29:341000 paper cuts
- 30:14Is Gardening Week enough?
- 33:37Kris compares software development to the publishing industry
- 35:08Ian disagrees with Kris
- 36:23Kris says maintainence shouldn't be a 'rotation'
- 37:15But everyone should be aware and familar with the need to maintain code
- 37:55Maintainence engineering needs to be raised to a higher level
- 39:44Sponsor: Honeycomb
- 41:05Sponsor: Retool
- 42:14Maintainable code vs good code
- 45:39The nauance of good vs maintainable
- 49:51Scientifically good code
- 55:55Summarizing the science of good code
- 57:30What makes Go good for writting maintainable software?
- 1:02:07Unpopular opinions!!
- 1:11:23Closing out the show
- 1:12:50Outro