Transcript #383: Why aren’t devs shipping faster?

00:00 Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.

00:06 This is episode 383, recorded May 14th, 2024.

00:11 And I am Brian Okken.

00:12 And I am Michael Kennedy.

00:14 And this, today's episode is sponsored by a new sponsor, Mailtrap.

00:19 Thank you, Mailtrap. Listen to their spot later in the show.

00:22 And if you want to connect to us, we're all on Fosstodon and on Mastodon.

00:27 And those links are all in the show notes, of course.

00:30 And also in the show notes or just at pythonbytes.fm, you can find out information to join us live on YouTube.

00:37 It's always fun. And if not, that's OK.

00:39 But you can catch us later. If you sign up to be a friend of the show, you can get the email.

00:44 And the friend of the show emails are going well.

00:47 It's growing, growing well. I'm excited about that.

00:51 And also the open rate staying very high. So that's pretty exciting.

00:55 So thank you.

00:56 People must care. I think it's cool. I enjoy getting in myself, actually.

00:59 Yeah, I do too. So also, I enjoy hearing from Michael about the exciting news in Python.

01:06 So, Michael, what do you got for us first?

01:09 Brian, why aren't you shipping code faster? Come on.

01:11 What's taking so long?

01:13 Well, you know that feeling when you start a new project and think everything's going quick.

01:18 And then after a couple of years, you're like, why do we have so many meetings to like add a button?

01:23 You know what I mean? Or something like that.

01:26 Yeah, it's tricky. And so we're not the only ones to wonder this.

01:32 Daksh Gupta said, I was also wondering this, but he took more action than most people I imagine would.

01:39 And said, I'm going to ask 100 developers why they aren't shipping code faster and then write it up.

01:45 So I read it up and let's share it. There's some interesting things in here, basically.

01:49 Like, look, I talked to people from a lot of the tech companies you would know, Meta, Pinterest, Heroku, Roblox, etc., etc.

01:58 Some that I could probably make a joke out of, but I'm going to try not to.

02:02 I'm going to try not to. But I thought it might be fun to summarize this for you.

02:06 All right. So they broke it down into multiple big categories like meetings or human interaction type stuff.

02:15 And the first big category is code bases.

02:20 And right at the top is dependency bugs.

02:23 So you kind of got to look at these a little bit of what are your current today blockers?

02:31 And maybe the person who said I'm blocked by this is a 27 year old who never worked when your only resource was a book and there were no packages, no dependencies.

02:42 You want a dependency? You crack it open and you get the algorithm and you start writing.

02:46 You know what I mean? Like that.

02:48 So the problem is they say, look, if I hit what they have got a bunch of quotes that are actually nice in here.

02:54 So Jack, an ex-Microsoft person, says the number one barrier to shipping faster is dependency bugs.

03:00 So hitting a random mysterious bug with libraries that require reading tons of old code or stack overflow links and GitHub issues.

03:09 They're just trying to figure out like, why is this thing, why did it stop working?

03:13 You know what I mean? And I would change that a little bit or maybe Michael's version is when something changes and it becomes incompatible.

03:22 And the worst case scenario is especially with the modern resolver and pipe and pip basically is if we can't find a matching fit for you, you don't get it.

03:35 Rather than we're going to give you a warning that it's not a great idea, but we're going to let you run it.

03:40 So if there's something that says I have to have this version of a library less than a version and something else says I have to have this library greater than a version and there's not an intersection there.

03:51 You're now hunting around and you're like, well, guess we're done.

03:55 And you can roll back.

03:57 You could say, OK, well, what of this like weird combination of things that it's coming up that I got to deal with?

04:02 Can I roll back so that there is an intersection?

04:05 But if you need a new feature, all right, then it's hard.

04:09 Or even if it's not any feature you need, it's just like, well, here's an hour and a half I spent juggling the intersection of these dependencies such that I didn't care about their interaction.

04:19 Really, I just want them both to be here.

04:22 But there's this bizarre interaction I got to deal with.

04:24 And my complaint about the pip being 100 percent like, no, we can't find it so you don't get it is that incompatibility.

04:32 The one thing that said less than the other things that greater than maybe that has to do with multi multi processing.

04:37 If you're not using multi processing, it would probably be fine, even though there is like a known intersection bug.

04:43 If you're not using that part of the code path, it's not your problem.

04:47 And you can say, look, I tested it.

04:48 I don't care if it's says it's the wrong version.

04:50 I want to just keep working.

04:51 Right.

04:52 And so, well, that's a lot of timing spent on that.

04:55 Right.

04:56 OK.

04:57 There also is bugs in your dependencies.

04:59 And I don't I don't know if that was covered by this or not.

05:02 Yes, that's true.

05:04 But that's one of those.

05:06 I think there's expectations that don't match really how they what reality should be.

05:12 So we like you said, we used to write all of our code.

05:15 And even if even if you got it out of a book, you wouldn't blame the book author if there was a bug in it.

05:20 You would fix it yourself.

05:22 But now we've got tons of dependencies and there's a lot of projects that are really 10 to 20 percent new code and the rest of it we're pulling in from everybody else.

05:31 Now, if those other things have a bug, do we think that it's we we just save time to not have to write all that.

05:38 Do we go out and fix those in the dependent projects or do we just complain about it or.

05:43 Yeah, exactly.

05:44 Exactly.

05:45 And it's usually open source.

05:46 Usually PRS are welcome.

05:48 Right.

05:49 And they do it.

05:50 But that's why I brought up like the the younger developer who didn't have to live through the time where there were no package or no package management things because there were no packages.

06:00 Right.

06:01 You just maybe if you're lucky, you download some random code off the Internet and you like work it into your app if you're right.

06:07 And so the velocity of writing software is so much faster than it used to be.

06:13 And it takes a step back by 20 percent because that thing has drawbacks.

06:17 It's still vastly better than it used to be.

06:19 So that was all I was saying there.

06:20 Yeah.

06:22 And I know you live you live through the same thing, right?

06:24 Yeah.

06:26 OK, so that's not the only one.

06:27 No, no.

06:28 There's plenty more complicated code bases.

06:30 It's it's.

06:31 Yeah, it's tricky.

06:32 I would have said number one if it was me.

06:34 Yeah.

06:36 So it says here, look, the law, the logic is sound.

06:38 You've got a growing startup.

06:40 You've got to ship faster.

06:41 You're going to die.

06:42 It's time to write docs.

06:43 Early engineers churn out as the company grows.

06:45 New engineers come into a big mess and they've got to deal with it.

06:49 But they still got to grow fast, ship fast, etc.

06:52 Right.

06:53 It says Maria from Amazon says there's so much undocumented in our service, including

06:58 poor records of new features, non-existent or outdated info and our dependencies or even

07:04 essential things like best practices for testing.

07:06 A lot of time is wasted and things trying to find what this is all about.

07:10 Right.

07:11 And nobody has time to write documentation, which creates a vicious cycle.

07:15 This is your number one?

07:17 The complicated code base is definitely number one.

07:19 But the document, the documentation and comments part, I used to have a tool handy that would

07:27 strip out, do a fork of a repo and strip out all the comments.

07:31 I love it.

07:32 Because it was so much easier to navigate some code bases without the comments.

07:36 But yeah, comments are great.

07:38 But if it's not, I really know what else you do for this.

07:41 But if the function is, let's say 10 lines, but the documentation is 20 or 30, all of

07:48 a sudden you're like, okay, I'm trying to see, I'm trying, you know what I mean?

07:52 It's like a little tricky and you can do stuff.

07:54 I have, for example, in editors, you can code fold the comments and things like that.

07:59 Right.

08:00 That could help.

08:01 Yeah.

08:02 But also like when you fix a bug, do you go back and fix the comment?

08:04 Sometimes not.

08:06 Okay, let's move on.

08:09 All right.

08:10 Next major section is process and QA loops.

08:13 Let me see what you think about this.

08:15 But it's not so much a test or no test, but when you have a QA department and so on, it

08:22 says Taylor, who's worked for a series of high growth startups, says me, creating a

08:27 test spec for QA, QA finding problems, getting a list of problems two days later, fixing

08:32 the merge conflicts, because the code has changed since then, switching back, back to

08:38 QA, deep looping, that kind of thing.

08:40 Right.

08:41 Maybe the challenge here is depending on other people for your code quality.

08:44 Yeah.

08:45 I think that's always in large projects, so it's going to be a thing.

08:48 But having one of the things that helps with that, I know we're not trying to fix this

08:52 here, but having embedded QA developers in the development teams.

08:56 Yeah, that's an interesting suggestion for sure.

08:59 Waiting for specs on larger companies, just waiting for, what are we going to build?

09:05 Well, I got to wait for people to approve the schemas or the API points or whatever.

09:11 People wishing we had waterfall again?

09:13 I don't know what's going on.

09:15 Yeah, exactly.

09:16 Just design it all up front and give it to me.

09:20 I think a lot of the next one also is awaiting stakeholder approval.

09:24 I think there's just a lot of that kind of stuff.

09:27 We're a pure vegetarian team, so we have no stakeholders.

09:31 Put the steak down.

09:34 Okay.

09:35 Raj from AWS said, "Amazon meetings approval, talking to 10 different stakeholders because

09:43 changing the color of a button affects 15 microservices." Oh, microservices.

09:49 Could that just be its own thing, like microservices?

09:52 Okay, let's go.

09:54 Writing tests.

09:55 Devs complain around tests could be basically divided into one, not enough tests or bad tests.

10:02 So Grant at FinTech Unicorn, the biggest thing was we didn't have good tests or good types,

10:08 so I had to do a whole lot of work to do and testing of stuff whenever I wanted to ship things.

10:14 Yeah, he could have wrote them.

10:17 Yeah, yeah, yeah.

10:19 Another one has to do with it doesn't at first sound like bad tests, but CI/CD taking so long.

10:26 So running pipelines for shipping takes a lot of time and ensures proper code coverage.

10:31 The tests sometimes require these pipelines to take their time, which slows us down.

10:35 Yeah.

10:36 Yeah, I know there's more here, but one of the metrics that I love is throughput.

10:43 So is it throughput or cycle time?

10:47 I don't know.

10:48 Cycle time.

10:49 Basically, how long does it take you to get from a single line code change that's to shipping?

10:55 And how all that process through the CI pipeline, the testing, approvals, whatever you have to do

11:01 to measure that and try to get that as low as possible and get the junk out of it?

11:05 Because that is a problem.

11:07 Yeah, absolutely.

11:08 All right, I can also blend the last one together with this.

11:11 So people are waiting for PRs to be approved.

11:14 Scope creep.

11:16 Josh says, "The human tendency to stuff last-minute items into the crevices of their luggage

11:23 minutes before leaving for the airport manifests itself at software companies as scope creep.

11:28 Slowly and surely, it will push back your release date with every incremental addition

11:33 feeling like an insignificant task, but in aggregate, adding significant molasses to the team's velocity."

11:41 Yes, yes.

11:42 Let's just ship it and then add those features later.

11:46 Excessive meetings.

11:47 I agree.

11:48 I'm going to wrap it up with this one, Brian, because it's been kind of long, but this is interesting.

11:52 Motivation.

11:53 Diane, a former engineer at Meta, said the number one reason that slowed her down was motivation.

11:59 So honest answer is, I was working on ads.

12:02 And that's a very old, complicated, and large stack.

12:05 I didn't understand it.

12:06 My friends on younger teams seemed happier.

12:09 I was miserable.

12:10 Yeah, basically, it shouldn't be surprising.

12:13 People want to work on inspiring projects.

12:15 And when you're inspired, think more about it.

12:17 You put more time into it.

12:18 And it's like, well, can we squeeze a percent of a percent out of this retargeting thing

12:24 to squeeze a bit more money for the company?

12:26 Not the same sort of inspiration as it is.

12:29 All right, well, people can check this list out.

12:31 And hopefully, maybe bring some of these ideas together to push back some of these problems at your company.

12:37 Yeah.

12:39 All right, back to you, Brian.

12:40 Well, I want to talk about Python 3.13.

12:43 Yay!

12:44 Speaking of shipping things.

12:45 Yeah, shipping things.

12:47 3.13, 3.13.0, Beta 1 is released as of May 8th.

12:55 I guess this is like a week old.

12:57 Anyway, Beta 1 released.

12:59 And there's some fun stuff in here.

13:01 So Beta is available to play with.

13:04 And reminder, the Beta does not mean that it's completely done.

13:08 It is half-baked.

13:10 So the feature freeze for Python, is it an end feature freeze?

13:15 I guess.

13:16 I believe so.

13:17 Yeah, I believe when they hit Beta, they say, "What's here is here." Ideally, unless maybe they have to take something out because they can't get it to work in the end.

13:26 All right, so disclaimer, it is still under development.

13:29 But there are four Beta releases, previews planned for 3.13.

13:35 And this is a good time to, it says, "We bold, strongly encourage maintainers of third-party projects to test with 3.13."

13:44 So time to turn on your, or at least check to see if you can turn on your 3.13 pipelines in CI.

13:51 So a whole bunch of fun new things in 3.13.

13:55 A lot of these are sort of internal stuff that I'm excited about, but end users maybe might not care about.

14:03 This is the experimental free-threaded build mode to disable the GIL.

14:09 This is kind of fun.

14:10 A preliminary experimental just-in-time compiler.

14:15 That's kind of neat.

14:16 This is cool.

14:17 A cyclic garbage collector that is now incremental, which should mean shorter pauses for collection and programs with a lot of objects.

14:28 Oh, nice.

14:29 Different version of Mimalloc. I don't know how to pronounce that.

14:33 Yeah, some possible memory improvements, which is kind of neat.

14:38 The thing that I'm really, okay.

14:40 A couple other notes. I'll get to the exciting thing that I'm excited about.

14:44 There's a bunch of removals.

14:46 So I guess we're getting rid of CGI now, whatever.

14:50 That's how you run the web.

14:52 However, well, I run my website.

14:54 And last week I mentioned this last week, typing.type is.

15:00 Type is, I think I pronounced it type LS.

15:03 It's IS.

15:04 That makes more sense.

15:06 I was looking at the wrong font, I guess.

15:08 But some of the exciting bits are that we have a new improved REPL or interactive interpreter.

15:19 And this is so exciting that actually Trey Hunter wrote an article about it.

15:24 So even like the URL for this is, I have the URL hidden, is like my favorite thing of Python 3.13.

15:33 So what's cool about the REPL is there's a bunch of cool stuff.

15:37 There's a, it's colored prompt, which is fun.

15:40 We like colors now.

15:42 And then, oh, blue.

15:45 There's, you can exit now.

15:47 You used to have to do, you used to say like exit, bracket, bracket.

15:51 What? It'll exit?

15:52 Yeah, exit works now.

15:54 Oh my gosh.

15:55 I was thinking of doing a PR to make this happen.

15:57 I'm just like, why is this so clunky?

16:00 Yay.

16:01 I mean, a pep.

16:02 Just like, we got to like, we got to rally folks.

16:04 This is worth 3.13 just to get exit to work.

16:10 Block level history.

16:11 Really cool.

16:12 Basically, this is like some of these niceties that you used to get from other sort of alternative REPLs.

16:19 Things like being able to edit the block and, you know, some little block history.

16:25 It's really pretty cool to be able to like go back and modify things.

16:29 And pasting code works better.

16:31 So if you copy some stuff out of the REPL and paste it in the REPL, it doesn't paste in the dot, dot, dots correctly.

16:38 You know, it does that right now.

16:39 So neat.

16:41 The downside, it's curses.

16:44 So it won't work correctly on, doesn't currently work on Windows.

16:49 So that's, actually, it's a pretty big deal.

16:51 But, you know, anyway, some fun stuff.

16:54 Why not Rich?

16:56 Rich and Textual.

16:58 That would have been awesome if they'd done that.

17:01 Right?

17:02 I mean, I'm not joking.

17:03 Like, it works all cross-platform.

17:04 It's got some incredible UI stuff.

17:06 Would have been cool.

17:08 Yeah, Rich and Textual don't work everywhere either.

17:11 But, you know, but more places.

17:13 Maybe this is a to-be-done.

17:16 Or maybe just you get the old terminal on Windows.

17:19 But, you know, that's 50% of the user base, right?

17:21 That's like, it's not like, well, there's one particular MicroPython type of device that's like this odd $5 thing that goes into tractors that it won't work.

17:35 Like, it's like half of the user base.

17:37 So, I don't know.

17:38 That's a surprise.

17:39 Well, Blaze recommends instead of exit, we should just require people to do colon Q.

17:46 How do you exit the ruffle?

17:47 You reboot your computer.

17:48 Okay, next.

17:49 Anyway.

17:52 All right.

17:53 Well, should we talk about our lovely sponsor, Mailtrap?

17:56 Yes, indeed.

17:57 Although, I would like to add two things real quick.

17:59 And then I'll tell everyone about them.

18:01 One, this is very exciting.

18:04 It's going to be interesting to see where the free-threaded Python stuff goes.

18:07 Because that's another one of the big deals.

18:10 But it's weird, right?

18:11 You've got to have a separate build.

18:13 It's not even a flag or something you can set.

18:15 But it's going to be something else.

18:17 But also the high-performance changes outside of this free-threaded thing with a JIT.

18:22 Excuse me?

18:23 A JIT?

18:24 Not just interpreted?

18:25 This is great.

18:26 So, very interesting.

18:27 And then a follow-up.

18:29 I apologize.

18:30 I can't remember who said it in the comments.

18:32 But DORA, DevOps Research and Assessment Metrics, includes four key metrics divided into these areas.

18:39 Deployment frequency or lead time for changes to measure team velocity and change failure rate and time to restore service.

18:48 Measure stability.

18:49 So, that's pretty cool.

18:51 DORA metrics.

18:52 All right.

18:53 How about we talk Mailtrap now?

18:55 Okay.

18:56 This episode is sponsored by Mailtrap, an email delivery platform that developers love.

19:00 An email sending solution with industry-best analytics, SMTP, and email API, as well as SDKs for major programming languages and 24/7 human support.

19:12 Try for free at mailtrap.io.

19:15 Thank you, Mailtrap, for supporting the show.

19:17 Awesome to have them on board.

19:19 We'll be telling you about them on upcoming shows as well.

19:22 All right.

19:23 So, if you do Jupyter Notebooks, Brian, that means you're going to settle so we see some pictures.

19:27 If you do Jupyter Notebooks or JupyterLab in particular, it's got the way it looks and so on.

19:34 But what if you could have a nice theming system for it?

19:38 So, there's an extension I want to highlight, JupyterLab Theme Editor, which is an extension to provide basically editing of colors, font families, font sizes of different elements in the user interface.

19:51 Right?

19:52 Yeah.

19:53 So, pretty cool.

19:54 You can install it and then you can open up this little sidebar and it lets you pick the layout color, the accent color, the border color, the UI font size, the content font size.

20:04 So, one of the things that sometimes drives me crazy about UIs, think about Zoom.

20:11 If you go to VS Code and you say Zoom, Zoom's everything.

20:14 What if I just want to Zoom just the stuff I actually care about, like the text?

20:18 And I don't want all the other crap to take up more space and make the text even harder to read.

20:23 I just stay over there and just see.

20:25 All right.

20:26 So, having different settings for content size versus UI element size is really awesome.

20:31 So, there's a bunch of things like that.

20:32 And yeah, you can basically pick all these different colors that you like.

20:37 You want a style to be light blue on dark blue or dark blue on light blue or purple or whatever you want.

20:44 There's a bunch of color palettes you can pick from, which is pretty nice.

20:48 And it's not a huge thing, but it's kind of interesting.

20:51 So, pip install Jupyter Theme Editor and off you go.

20:54 Yeah, I want to try to make it theme like early 2000s.

21:00 Yeah, where's like the blinking elements and the gradients?

21:04 I want now.

21:06 Yeah.

21:07 Yeah, so that's a quick one, but people can check it out if they use JupyterLab.

21:11 Nice.

21:12 Yeah.

21:13 All right.

21:14 Well, I've got another quick one, a little bit.

21:17 We were talking about using rich and textual for colors and stuff and love both of those projects.

21:25 One of the things that and you can get colors and things, nice help output if you're using like type or click or some of the other extensions for different argument parsing.

21:36 But a lot of people and I do too on simple projects, I just use arg parse.

21:41 It works great for simple things.

21:44 It's nice to test.

21:45 However, it's more black and white.

21:48 So, today we've got rich arg parse.

21:52 So, rich arg parse is cool.

21:54 It's not.

21:55 So, if you're having a command line program that you want to use colors, of course, you could use rich, just use the colors.

22:01 But the help is auto generated.

22:03 Well, rich arg parse or auto generates the format.

22:07 Rich arg parse gets colors in those.

22:09 So, it's got, you know, nice orange color, orange and blue and white and green and some different great colors to really highlight.

22:19 It's a lot easier to read the help text if it's in color.

22:22 So, if you can add, if you're okay with adding a dependency, this is great.

22:26 And it's also like really easy to add.

22:29 I was like, is it possible?

22:31 This is so easy.

22:32 And so, the how you add it, there is a whole bunch of features.

22:35 So, there's built in formatters.

22:39 So, rich arg parse defines different formatters to help with the help formatter or the raw description help formatter.

22:45 There are different types.

22:46 But the easiest thing to do to try it out is all you have to do is import rich help formatter.

22:53 And when you're instantiating your argument parser, you just pass in rich help formatter as the formatter class.

23:02 And those two lines of code, that's all we did.

23:05 So, I wanted to try this out to see how fun colors were in your help.

23:10 And I've got a little test project called test arg parse apps.

23:14 Basically, a hello world app that uses arg parse and runs testing on it.

23:18 And I'm like, how do I do that?

23:20 And so, the help for my little program looks like this.

23:23 It's just white, normal.

23:26 And when I added these two, just these two lines of code for rich arg parse, you just get a nice orange and blue.

23:33 It's really much nicer.

23:34 Yeah.

23:35 Color in the terminal is, I feel it's kind of non-optional.

23:38 I will say that it is one more dependency, though.

23:41 And one of the reasons why I use arg parse a lot of times is because I don't want to add any dependencies and I still want argument parsing.

23:48 So, keep that in mind.

23:50 That's a totally good point.

23:51 But I can imagine plenty of projects that said, we're not going to have dependencies.

23:55 Let's just use arg parse.

23:56 And then eventually they start having some.

23:58 And once you're already there, you might as well throw this on here and make it look nicer without writing much different code, right?

24:03 Yeah.

24:04 And I love that it's, I mean, there are more features you go through, go look at the documentation.

24:09 But I love projects where you can make your program better by just adding a couple lines of code.

24:15 Pretty great.

24:16 Indeed.

24:17 Jeff out there likes to bring it full circle.

24:19 So, wasn't dependency issues one of the biggest causes for slowdown development?

24:24 Yes.

24:25 Well, it's also, it's just two lines of code to change back.

24:28 If you got a test break, you can take that out.

24:31 That's assuming that the original developer that knows that it's still there.

24:34 They could have left.

24:35 And then, no, I'm just kidding.

24:37 It's a fair point, honestly.

24:39 So, anyway.

24:40 I like it.

24:41 Well, those are our items.

24:42 Do you have any extras for us?

24:44 Only one.

24:46 But I will, it's very exciting.

24:49 But it's just one of them.

24:50 It's good.

24:51 It's the only one.

24:52 We have a brand new course over at Talk Python.

24:54 And this is done by Vincent, who's been on the podcast before with us.

24:59 So, it's called Getting Started with NLP and spaCy.

25:03 Oh, neat.

25:04 Yeah.

25:05 So, basically, if you have a lot of text and you want to process it, pull out entities,

25:10 understand things about it, right?

25:12 Like, at a real deep level, you know, NLP.

25:15 spaCy is one of the most important ways that you can, one of the most important libraries

25:19 for doing that.

25:20 And so, here's an awesome course that talks about how to do that with spaCy, but also

25:25 even goes into using a little bit some of the extensions and fun things like spaCy LLM

25:32 to integrate, say, ChatGPT or other LLMs along with the spaCy processing to pull things out.

25:39 Talks about training custom spaCy models.

25:42 Vincent did a really cool job where basically all the examples of this course are based

25:49 on Talk Python to me podcast transcripts.

25:52 So, he wrote a single function that will give you every line ever spoken on Talk Python

25:58 over the last eight years as a generator, which is insanely awesome.

26:04 And completely not useful.

26:06 Very interesting, right?

26:08 Very interesting.

26:09 I'm not going to use the generators, but then you can just start feeding that kind of information

26:12 and say, "Well, who has talked about FastAPI?

26:16 And when you do talk about FastAPI, what other projects in the libraries were talked about?"

26:21 You could do things to discover the zeitgeist of a topic or a tool over time by seeing how

26:28 much other guests on the show talk about it and stuff.

26:31 It's a really cool course, and people should definitely check it out.

26:36 Train, annotate your own data, do all sorts of fun things.

26:39 Link is in the show notes, and if you're on the list, I will probably be sending you an

26:43 email about it as well.

26:45 But yeah, very excited to have this new course up for everybody.

26:47 It's going to be a lot of fun.

26:49 The one extra I've got is last week I announced that I was going to switch the pytest course,

26:55 the one at pythontest.com.

26:57 Of course, there is also a pytest course at Talk Python Training.

27:02 Definitely still worth trying out.

27:04 It's a complete pytest course that covers the entire Python or the pytest book.

27:09 That switched to Podia, and that switch is done to Podia.

27:13 So, well, almost done.

27:15 It's there.

27:16 Everybody's been invited, except for one person, so they didn't get their invite.

27:20 I'll get that out later today.

27:22 But if you're still using the teachable version, it'll still be around until a little bit into

27:30 June, but please switch over soon.

27:34 And then the next step of this is Podia comes with email services, too.

27:39 So I'm switching from ConvertKit to Podia for email, and I'm starting that this week.

27:45 So doing that, that's the news on my end.

27:48 And a lot of this has to do with just since I'm not as turbo of a course creator as Michael

27:55 is, it's to keep my overhead down so that I can do smaller courses cheaper and get more

28:03 of them out to you.

28:04 There's still good quality stuff.

28:06 It's just--

28:07 >> That's awesome.

28:08 Yeah, you keep the optionality, right?

28:09 >> Keep the optionality open.

28:10 So, yeah.

28:11 All right.

28:12 >> Yeah, congratulations.

28:13 I know that's a big deal to move all that stuff around.

28:16 >> Yeah, it was a little stressful.

28:17 I was worried that tons of people were going to be mad, but I haven't had any complaints

28:21 so far.

28:22 And I'm not inviting other people to complain, but--

28:25 >> You want me to complain?

28:27 No, just kidding.

28:28 >> Anyway.

28:29 Oh, one of the cool things that it has that I hadn't used before is there's comments within

28:34 the course.

28:35 So people can ask questions like right there.

28:37 I know it's a complicated topic, so it's kind of cool to have comments.

28:40 >> Yeah, that is cool.

28:41 >> Anyway, do you have anything funny for us, Michael?

28:44 >> I do.

28:46 I do.

28:48 Let's see.

28:49 Let me put it up here.

28:50 So another testing one to follow up with your extra, of course.

28:53 It comes to us from the venerable xkcd.

28:56 This is 2928.

28:58 Okay.

28:59 So it's called Software Testing Day.

29:02 Did you know there's a Software Testing Day, Brian?

29:04 >> No.

29:05 >> Yeah.

29:06 It's right behind Valentine's Day, apparently.

29:08 So do you and the other QA engineers have any fun plans for the holiday?

29:13 Yeah, assuming the schedule system doesn't crash.

29:15 Software Testing Day is a holiday celebrated every negative one years on January 0th at 2571 p.m.

29:22 >> That's why I don't celebrate.

29:26 >> Then if you look at the hover, as you do on xkcd, it says the company tried to document how often

29:31 employees were celebrating Software Testing Day, but their record-keeping system kept mysteriously crashing.

29:37 >> This is good.

29:39 >> It's a subtle one, right?

29:40 >> Yeah.

29:41 >> Celebrate every negative one years.

29:43 I actually had the question today from somebody as to why we can't structure our tests so that we can

29:51 completely test our complicated software so that we never see anything after we write the code.

29:58 >> Yeah.

30:01 >> What a messy place.

30:02 >> I wanted to ask him how much time he had because proving software is correct is something we tried to do a long time ago,

30:10 and it's not worth going down that road.

30:13 >> Yeah.

30:14 The only few places it might make sense is like the Voyager probe or something like that.

30:20 We're sending it out, and we want it to run 50 years from now.

30:24 >> No, thoroughly testing is good, but you still can't prove that you've caught all the bugs.

30:30 You just can't.

30:31 >> Yeah, absolutely.

30:32 All right, well, here's a nice little test case for them to use.

30:36 >> Yeah, every negative one years.

30:38 >> Indeed.

30:40 >> Nice.

30:41 All right, well, oh, fun, cool.

30:43 Blaze just mentioned, speaking of testing, BlazeTube says, "Fun fact, right after this session,

30:49 they're meeting to go through Chapter 6 of the pytest book." Yay.

30:53 Anyway.

30:54 >> Awesome.

30:55 >> Cool.

30:56 Well, thanks a lot for this wonderful episode, Michael.

30:57 >> Yep.

30:58 As always.

30:59 Bye, Brian.