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:05 This is episode 383, recorded May 14th, 2024.

00:11 And I am Brian Okken.

00:12 And I am Michael Kennedy.

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

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

00:21 And if you want to connect to us, we're all on Fostadon 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 okay.

00:39 But you can catch us later.

00:41 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 well. I'm excited about that.

00:50 And also the open rate is staying very high.

00:54 So that's pretty exciting.

00:55 So thank you.

00:56 People must care. I think it's cool.

00:57 I enjoy getting it myself, actually.

00:59 Yeah, I do too.

01:00 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:08 Brian, why aren't you shipping code faster?

01:10 Come on.

01:11 What's taking so long?

01:12 Well...

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

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

01:23 You know what I mean?

01:24 Or something like that.

01:24 Yeah.

01:26 It's tricky.

01:28 And so we're not the only ones to wonder this.

01:32 Bhasky 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 a hundred developers why they aren't shipping code faster.

01:43 And then write it up.

01:45 So I read it up and let's share it.

01:46 There's some interesting things in here, basically.

01:48 Like, look, I talk to people from a lot of the tech companies you would know.

01:53 Meta, Pinterest, Heroku, Roblox, et cetera, et cetera.

01:57 Something 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.

02:03 But I thought it might be fun to summarize this for you.

02:05 All right.

02:06 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:18 So code.

02:19 And right at the top is tendency bugs.

02:23 So you kind of got to look at these a little bit of where, 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:41 You want a dependency?

02:42 You crack it open and you get the algorithm and you start writing.

02:45 You know what I mean?

02:46 Like that.

02:46 So, so the problem is they say, look, if I hit, they've got a bunch of quotes that are actually nice.

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

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

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

03:12 You know what I mean?

03:13 And I would change that a little bit.

03:15 Or maybe Michael's version is when something changes and it becomes incompatible and a worst case scenario.

03:23 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:34 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:39 Right.

03:39 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:50 You're now hunting around and it's, you're like, well, guess we're done.

03:55 And you can roll back.

03:56 Right.

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

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

04:04 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.

04:13 I spent juggling the intersection of these dependencies such that I didn't care about their interaction.

04:19 Really.

04:19 I just want the, I just want them both to be here, but there's this bizarre interaction I got to deal with.

04:24 And my, my complaint about the pip being a hundred percent, like, no, we can't find it.

04:29 So you don't get it is that incompatibility.

04:32 The one thing that said less than the other thing said 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.

04:40 Even though there's like a known intersection bug, if you're not using that part of the code path, it's not your problem.

04:46 And you can say, like, 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:55 Okay.

04:55 There also is bugs in your dependencies.

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

05:02 Yes, that's true.

05:03 That's true.

05:05 But that's, that's one of those.

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

05:11 So we, like you said, we used to write all of our code and even if, even if you got it out of a book, you wouldn't blame the book author.

05:19 If there was a bug in it, you would fix it yourself.

05:21 Yeah.

05:21 Yeah.

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

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

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

05:42 Exactly.

05:43 Exactly.

05:44 And it's usually open source.

05:45 Usually PRs are welcome, right?

05:47 You don't want to do it.

05:49 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.

05:58 Because there were no packages, right?

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

06:05 Right?

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

06:12 And when it takes a step back by 20% because that thing has drawbacks, it's still vastly better than it used to be.

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

06:20 Yeah.

06:20 Yeah.

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

06:23 Yeah.

06:24 Yeah.

06:24 Okay.

06:25 So that's not the only one.

06:26 No, no.

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

06:29 It's, it's true.

06:30 Yeah.

06:31 It's tricky.

06:32 I would have put this at number one if it was me.

06:34 Yeah.

06:34 Yeah.

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

06:38 You've got a growing startup.

06:39 You've got to ship faster.

06:40 You're going to die.

06:41 No time to write docs.

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

06:44 New engineers come into a big mess and they've got to deal with it, but they still got to grow fast,

06:50 ship fast.

06:51 et cetera.

06:51 Right.

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

06:59 records of new features, non-existent or outdated info in our dependencies, or even essential

07:04 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 the nobody has time to write documentation, which creates a vicious cycle.

07:14 This is your number one.

07:16 The complicated code base would definitely be number one, but the documents,

07:21 the documentation and comments part.

07:24 I used to have a tool handy that would strip out, do a fork of a repo and strip out all

07:31 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.

07:37 Comments are great.

07:38 Comments are great.

07:38 But if it's, and I don't really know what else you do for this, but if the function is,

07:43 let's say 10 lines, but the documentation is 20 or 30, all of a sudden you're like, okay,

07:51 okay, I'm trying to see.

07:51 I'm trying, you know what I mean?

07:52 It's like a little tricky.

07:53 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.

07:59 That could help.

08:00 Yeah.

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

08:03 Sometimes not.

08:05 Sometimes not.

08:07 Okay.

08:09 Let's move on.

08:09 All right.

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

08:12 I can see what you think about this, but it's not so much a test or no test, but when you

08:18 have a, say a QA department and so on, it says Taylor, who's worked for a series of high

08:23 growth startups, says me creating a test spec for QA, QA finding problems, getting a list

08:30 of problems two days later, fixing the merge conflicts because the code has changed since

08:35 then, switching back, back to QA, keep looping.

08:39 And that kind of thing, right?

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

08:43 Yeah.

08:44 Or I think that's always in large projects, always going to be a thing, but having one

08:49 of the things that helps with that.

08:50 I know we're not trying to fix this here, but having embedded QA developers in the development

08:55 teams.

08:55 But yeah, that's an interesting suggestion for sure.

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

09:05 build?

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

09:10 whatever.

09:10 These people wishing we had waterfall again.

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

09:14 Yeah, exactly.

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

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

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

09:27 So we, we, we're a pure vegetarian team, so we have no stakeholder.

09:30 Put the stake down.

09:33 Okay.

09:34 Raj from AWS said it.

09:38 Amazon meetings approval, taking 10 different stakeholder, talking to 10 different stakeholders

09:43 because changing the color over a button affects 15 microservices.

09:47 Oh, microservices.

09:49 Could that just be its own thing?

09:51 Like microservices.

09:52 Okay.

09:52 Let's go.

09:52 Writing tests.

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

10:01 So grant at a FinTech unicorn.

10:04 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 end to end testing of stuff whenever I wanted to

10:13 ship things.

10:13 Yeah.

10:15 Yeah.

10:15 You could have read them.

10:16 He could have wrote them.

10:17 Yeah.

10:17 Yeah.

10:18 Yeah.

10:18 Yeah.

10:18 Another one has to do with, it doesn't at first sound like bad tests, but CICD taking

10:24 so long.

10:25 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:34 Yeah.

10:35 Yeah.

10:35 There's a, I know there's more here, but one of the, one of the metrics that I love is, is

10:41 throughput.

10:42 So was it, is it throughput or cycle time?

10:46 I don't know.

10:47 I think it's cycle time.

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

10:54 shipping and, and how like all that process through the CI, the pipeline, the testing approvals,

10:59 whatever you have to do to measure that and try to get that as low as possible and get the

11:03 junk out of it.

11:04 Because that does, that is a problem.

11:07 Yeah, absolutely.

11:08 All right.

11:08 I kind of also blended the last one together with this.

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

11:13 Scope creep.

11:14 Josh says the human tendency to stuff last minute items into the crevices of their luggage

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

11:27 slowly and surely it will push back your release date with every incremental edition feeling

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

11:39 velocity.

11:39 Yes.

11:41 Yes.

11:42 Just ship it.

11:42 And then, then add those features later.

11:44 Excessive meetings.

11:47 I agree.

11:48 This, okay.

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

11:51 interesting.

11:51 Motivation.

11:52 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 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:08 I was miserable.

12:09 Yeah.

12:11 Like, so basically 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 to

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

12:26 Like not the same as sort of inspiration is it?

12:29 All right.

12:29 Well, people can check this list out and hopefully, you know, maybe bring some of these ideas

12:34 together to push back some of these problems at your company.

12:37 Yeah.

12:38 Yeah.

12:38 All right.

12:39 Back to you, Brian.

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

12:43 Yay.

12:44 Speaking of shipping things.

12:45 Yeah.

12:46 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:56 Anyway, Beta 1 released and there's some fun stuff in here.

13:01 So betas are available to play with.

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

13:07 It is half-baked.

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

13:14 I guess.

13:15 Is it a feature freeze?

13:15 I believe so.

13:16 Oh, okay.

13:17 Yeah.

13:17 I believe when they hit beta, they say, what's here is here.

13:20 Yeah.

13:21 Okay.

13:21 Ideally, unless maybe they have to got to take something out because they can't get it to

13:25 work in the end.

13:25 All right.

13:26 So disclaimer, it is still under development, but there are four beta releases, previews

13:33 planned for 3.13.

13:35 So this is a good time to, it says, we bold, strongly encourage maintainers of third-party

13:42 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

13:49 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 are, that I'm excited about, but, you know,

14:00 end users maybe might not care about.

14:02 There's the experimental Fred, free threaded build mode with, to disable the GIL.

14:08 That's kind of fun.

14:09 A preliminary experimental just in time compiler.

14:14 That's kind of neat.

14:15 This is cool.

14:17 A cyclic garbage collector that is now incremental, which should mean shorter pauses for collection

14:25 and programs with a lot of objects and a different version of MimeAlloc.

14:31 MimeAlloc?

14:32 I don't know how to pronounce that.

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

14:38 The thing that I'm really, okay, a couple other notes.

14:41 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.

14:49 Whatever.

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

14:52 However will I run my website?

14:53 And last week I did, I mentioned this last week.

14:58 Typing.type is.

15:00 Type is.

15:01 I think I pronounced it type LS.

15:03 It's IS.

15:04 That makes more sense.

15:05 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:18 And this is so exciting that actually Trey Hunter wrote an article about it.

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

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

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

15:39 We like colors now.

15:41 And then, ooh, it's like blue.

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

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

15:50 Or exit.

15:51 What?

15:51 It'll exit?

15:52 Yeah.

15:52 Exit works now.

15:53 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?

15:58 Yay.

16:00 I mean, I mean, a pep.

16:01 Just like, we gotta, like, we gotta rally, folks.

16:04 Oh, this is worth 3.13 just to get exit to work.

16:07 Block level history.

16:10 Really cool.

16:11 So basically, this is like some of these niceties that you used to get from other sort of alternative

16:18 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:28 And pasting code works better.

16:30 So if you copy some stuff out of the REPL and paste it in the REPL, it doesn't paste in the

16:36 dot, dot, dots correctly.

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

16:39 So neat.

16:40 The downside, it's curses, so it won't work correctly on, doesn't currently work on Windows.

16:48 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:55 Why not Rich?

16:56 Rich and Textual.

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

16:59 Right?

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

17:02 Like, there's, it works all cross-platform.

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

17:06 Would have been cool.

17:07 Yeah.

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

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

17:13 Maybe, 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 a, not, it's not like, well, there's, there's one, one particular MicroPython type of device.

17:30 It'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 Yeah.

17:37 So, I don't know.

17:38 That's a.

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.

17:48 Next.

17:49 Anyway.

17:51 All right.

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

17:55 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:03 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:09 But it's weird, right?

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

18:12 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:23 Not just interpreted.

18:24 This is great.

18:26 So, very interesting.

18:27 And then a follow-up.

18:29 I apologize.

18:29 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:38 Deployment frequency or lead time for changes to measure team velocity.

18:44 Change failure rate and time to restore service.

18:47 Measure stability.

18:49 So, that's pretty cool.

18:50 Dora metrics.

18:51 Yeah.

18:52 How about we talk Mailtrap now?

18:54 Okay.

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

19:00 An email sending solution with industry-based analytics.

19:04 And email API.

19:05 And email API.

19:05 As well as SDKs for major programming languages.

19:09 And 24-7 human support.

19:11 Try for free at Mailtrap.io.

19:14 Yeah.

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

19:17 Awesome to have them on board.

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

19:22 All right.

19:22 So, if you do Jupyter Notebooks, Brian.

19:25 Let me zoom in 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 that I want to highlight, JupyterLab Theme Editor, which is an extension to provide basically editing colors, font families, font sizes of different elements in the user interface.

19:51 Right?

19:51 Yeah.

19:52 So, pretty cool.

19:53 You can just install it.

19:54 And then you can open up this little sidebar, and it lets you pick the layout color, the ax out 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, you know, think about like Zoom.

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

20:13 Like, what if I just want to Zoom just the stuff I actually care about, like the text?

20:17 And I don't want all the other crap to take up more space on my screen to make the text even harder to read.

20:22 Well, let's just stay over there and just see.

20:24 All right.

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

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

20:32 And, yeah.

20:33 You can basically pick all these different colors that you like, you know.

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

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

20:47 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:53 Yeah.

20:54 I want to try to make it themed like an early 2000s.

20:59 Yeah.

21:00 Where's like the blinking elements and the gradients?

21:03 Come on now.

21:05 Yeah.

21:06 Yeah.

21:07 So, that's a quick one.

21:08 But people can check it out if they use JupyterLab.

21:11 Nice.

21:11 Yeah.

21:12 All right.

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

21:16 We were talking about using rich and textual for colors and stuff.

21:23 And love both of those projects.

21:25 One of the things that, and you can get colors and nice help output if you're using like Typer,

21:32 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:40 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:51 So, rich arg parse is cool.

21:54 It's not, so if you're having a command line program that you want to use colors, of course,

21:59 you could use rich, just use the colors.

22:01 But the help is auto-generated.

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

22:06 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

22:15 different great colors to really highlight.

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

22:21 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 that this is so easy?

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

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

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

22:44 help formatter.

22:45 They're 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:52 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:19 And so, the help for my little program looks like this.

23:23 It's just white, normal.

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

23:32 It's really much nicer.

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

23:37 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.

23:45 And I still want argument parsing.

23:47 So, keep that in mind.

23:49 That's a totally good point.

23:50 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.

24:01 Without writing much different code, right?

24:03 Yeah.

24:03 And I love that it's, I mean, there are more features.

24:07 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:15 Indeed.

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

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

24:23 Yes.

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

24:27 If you've got a test break, you can take that out.

24:30 That's assuming that the original developer that knows that is still there.

24:33 They could have left.

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

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

24:38 So, anyway.

24:39 I like it.

24:40 Well, those are our items.

24:42 Do you have any extras for us?

24:43 Only one.

24:45 Okay.

24:45 Only one.

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

24:47 So, I'm, but it's just one of them.

24:49 It was good.

24:50 It's the only one.

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

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

24:58 So, it's called Getting Started with NLP and Spacey.

25:02 Oh, neat.

25:03 Yeah.

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

25:09 understand things about it, right?

25:11 Like, at a real deep level, you know, NLP, Spacey is one of the most important ways that you can,

25:17 one of the most important libraries for doing that.

25:19 And so, here's an awesome course that talks about how to do that with Spacey,

25:24 but also even goes into using a little bit, some of the extensions and fun things like Spacey LLM

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

25:38 Talks about training custom Spacey models.

25:41 Vincent did a really cool job where basically all the examples of this course are based on Talk Python

25:49 to me podcast transcripts.

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

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

26:03 And completely not useful.

26:05 Very interesting, right?

26:08 Very interesting use of generators.

26:09 But then you can just start feeding that kind of information and say, well, you know,

26:13 who has talked about FastAPI?

26:15 And when you do talk about FastAPI, what other projects and libraries were

26:19 talked about and like, you could do things to discover sort of the zeitgeist of a topic

26:25 or a tool over time by seeing how much other guests on the show talk about it and stuff.

26:30 It's a really cool, really cool course.

26:32 And I think people should definitely check it out.

26:35 You can train and annotate your own data.

26:37 I do all sorts of fun things.

26:38 So, the link is in the show notes.

26:40 And if you're on the list, I will probably be sending you an email about it as well.

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

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

26:47 Yeah.

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

26:54 the one at pythontest.com.

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

27:01 Definitely still worth trying out.

27:03 But there's the 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:12 So, well, almost done.

27:14 It's there.

27:15 Everybody's been invited except for one person.

27:18 So, they didn't get their invite.

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

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

27:30 But please switch over soon.

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

27:38 So, I'm switching from ConvertKit to Podia for email.

27:42 And I'm starting that this week.

27:45 So, doing that.

27:45 That's the news on my end.

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

27:55 it's to keep my overhead down so that I can do smaller courses cheaper and get more of them out to you.

28:04 There's still good quality stuff.

28:05 It's just awesome.

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

28:08 Keep the optionality open.

28:09 So, yeah.

28:10 All right.

28:12 Yeah, congratulations.

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

28:15 Yeah, it was a little stressful.

28:17 I was worried that tons of people are going to be mad.

28:19 But I haven't had any complaints so far.

28:22 And I'm not inviting other people to complain.

28:24 But...

28:25 You want to need 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 the course.

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

28:37 I know it's a complicated topic.

28:38 So, it's kind of cool to have comments.

28:40 Yeah, that is cool.

28:41 Anyway.

28:41 Do you have anything funny for us, Michael?

28:43 I do.

28:45 I do.

28:46 I do?

28:47 Let's see.

28:48 Let me put it up here.

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

28:53 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:01 Did you know there was a Software Testing Day, Brian?

29:03 No.

29:04 Yeah.

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

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

29:12 Yeah.

29:13 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:24 And then if you look at the hover, as you do on XKCD, it says, the company tried to document how often employees were celebrating Software Testing Day, but their record-keeping system kept mysteriously crashing.

29:37 This is good.

29:38 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 completely test our complicated software so that we never see anything after we write the code.

29:57 Yeah.

29:58 What was 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, and it's not worth going down that road.

30:12 Yeah.

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

30:20 You know what?

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

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

30:29 You just can't.

30:31 Yeah, absolutely.

30:32 All right.

30:32 Well, here's a nice little test case for him to use.

30:35 Yeah.

30:36 Every negative one years.

30:38 Indeed.

30:39 Nice.

30:40 All right.

30:40 Well, oh, fun.

30:42 Cool.

30:43 Blaze just mentioned, speaking of testing, BlazeTube says, fun fact, right after this session, they're meeting to go through chapter six of the pytest book.

30:51 Yay.

30:52 Anyway.

30:53 Awesome.

30:53 Cool.

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

30:56 Yep.

30:57 As always.

30:58 Bye, Brian.