#463: 2025 is @wrapped

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

00:05 This is episode 463, recorded December 22, 2025.

00:10 I'm Brian Okken.

00:11 And I am Michael Kennedy.

00:12 And this episode is sponsored by us.

00:14 So support us by heading over to Michael's courses, my courses, Talk Python Training or python test.com,

00:24 or just go over and see what we got at the pythonbytes.fm.

00:29 Let me add one more thing real quick there, Brian. Sorry to hijack your intro, but hey,

00:34 we're coming up on 2026 and it's about time to be scheduling sponsors on the ad calendar for the

00:41 next year. So if companies out there, if you're listening, you're like, why does my company not

00:45 support Python Bytes and sponsor it? Yes, a fine question you should be taking up with your

00:50 marketing team. Have them reach out to me. And right now there's a bunch of openings. We'll see

00:54 if they get bought up or not as things go.

00:57 But yeah, just send me an email.

00:58 Yeah, actually, that'd be great.

01:00 I'd love to have more sponsors on the show.

01:04 If you want to reach us for sponsoring or any other ways,

01:11 there's links on the show page, pythonbytes.fm.

01:16 You can also find links to all of our socials.

01:19 We're at Mastodon and Fosstodon, both us individually and the show.

01:24 And also, if you'd like to watch us live, you can go to pythonbytes.com/live

01:31 and see what it is and find the links.

01:33 And then as well, while you're there, sign up for the mailing list

01:37 so we can send you all the links we talk about directly to your inbox.

01:41 Alrighty, oh, one more thing before we get started.

01:44 We are taking, normally we record on Monday mornings and we are taking next week off

01:51 and we will be back in 2026.

01:54 All right. Kick us off, Michael.

01:56 It's end of the year. As you said, we'll be back first week of January.

02:02 But it's a little bit of an introspective end of the year is what I want to leave people with.

02:07 So people may have noticed I usually cover tools, libraries, or updates to those kinds of things and so on.

02:14 But on this episode, I want to cover two articles that I came across recently that I think they'll make you think.

02:20 They'll make you really evaluate the situation.

02:23 One has to do with agentic coding and one has to do with why open source won and continues to win.

02:30 But more importantly, what is one of the really key ingredients?

02:34 So as we look towards the future for more sustainability, let's not kill the golden goose by changing that thing.

02:40 So the first one is, has the cost of building software just dropped 90 percent?

02:46 That's a pretty stark headline, isn't it?

02:48 Yeah.

02:49 And what are the consequences? Right.

02:50 Does that mean, does that mean like, well, you thought it was hard to get a job earlier as a junior and just hang on to your pants now?

02:57 Or does it mean something else?

02:58 We'll see.

02:58 Well, at least we'll see what Martin Alderson said, because that's the article.

03:02 He wrote this article and I think it is super insightful and interesting.

03:06 So I kind of want to just pull out some highlights and put it out there for you all to think about as you got some downtime.

03:10 So the premise is basically that many of the recent programming quote advancements that are like gonna change the world, gonna actually absolutely change the way things work, haven't really.

03:23 For example, test-driven development, cloud computing, especially hyperscale clouds, microservices, complex front ends like React and so on, Angular, whatever.

03:33 Kubernetes, sure, they're advancements and they help in some way or another for various things,

03:38 but they're not bending the curve dramatically on how we write software, how much more we get done,

03:43 and so on. Somewhat, but not massively. But they say, let me see if I can find it. Yeah, here we go.

03:50 The economics have dramatically changed now with agentic coding. And I agree. I think it really

03:57 has. And I know a lot of people are frustrated with AI or they don't want to use AI and so on.

04:02 I'm not here to make people do that, but I am here to put on your radar that this is something you're going to have to be paying attention to.

04:08 And Martin thinks so as well.

04:09 Says in 2026 is going to catch a lot of people off guard.

04:13 And I think so too.

04:14 So it kind of goes through the history a little bit of like changes, how open source actually made a huge change, how cloud was supposed to make a big change, but it just added a crap ton of complexity.

04:25 A lot of other things.

04:26 So in a lot of just sort of how complexity has grown over time, instead of these things

04:31 making us able to write more software or better software, a lot of times it's just handle

04:35 more complex software or kind of doing the same thing.

04:37 So where's the 90% savings come from?

04:41 So he says, like you, probably I was incredibly skeptical of a lot of AI coding tools at the

04:46 beginning of the year, but things are changing fast.

04:49 And previously, if I want to, let's say I want to add some small capability to my app.

04:55 How do you do it?

04:55 Well, you're going to assemble a team of people.

04:57 You're going to set up continuous integration.

04:59 You're going to build out data access patterns, and you're going to plan that out in an architecture meeting.

05:03 Really, it's just a bunch of crud, but people make a big deal out of it.

05:06 So you're going to over-engineer it probably.

05:10 And you're going to set up some testing and so on.

05:12 And that's just direct labor, right?

05:13 You've got all the management.

05:14 And one of the things that's really interesting about this article

05:17 is the mythical man month aspect of this.

05:20 Like, okay, well, that's going to take two weeks.

05:21 Well, what if we add four people to it?

05:23 Well, it'll take one and a half weeks.

05:24 Like, wait, why is that not half a week?

05:26 You know, it's like the coordination, the communication,

05:29 the in factorial ways in which there can be like blocking

05:33 or communication or meetings or coordination and so on.

05:37 And so these coding tools have got really, really good.

05:39 And as you add one of these coding tools in, you don't have to have meetings with it.

05:45 You don't have to have it working with three other ones of them

05:48 so that it can coordinate different skill sets and so on.

05:51 And so in a sense, it really lowers the number of connections in that mythical man month,

05:56 but still adds a lot of capabilities.

05:57 So pretty interesting.

05:58 So final takeaway is like on the face of it, this seems like incredibly bad news for the

06:02 software development industry.

06:04 Indeed.

06:05 But a look at history.

06:07 Let's see.

06:08 So Jevons paradox comes from back in the day when coal usage became super efficient, right?

06:16 Instead of just burning it in an open pit or whatever to like heat something, we put it

06:21 know the steam engines and it does way more work per you know joule of energy or whatever right

06:27 it says look at least this guy martin thinks this applies jevon's paradox also is going to apply to

06:32 software that when something becomes cheaper to produce it's not that we just use it less it's

06:37 like well we've got five developers but now they're way more efficient so let's get rid of four of them

06:42 that's one possible outcome the other is like let's just build five times as much software

06:46 as we used to, right?

06:47 And so an example is from history is when coal became way cheaper,

06:52 its use skyrocketed, not cheaper, efficient, right?

06:56 Like you didn't need to spend as much coal to get stuff done.

06:59 But in fact, it actually blew up way, way more.

07:02 So super interesting.

07:03 And I think there's something to that.

07:04 I think there's a ton of latent demand for software.

07:08 So anyway, there's a whole section on that that's pretty interesting, I think.

07:12 Yeah, I think there is a lot of, I've mixed emotions about this.

07:17 I think there is a lot of light in demand.

07:19 I am dealing with both agent-driven or agent-developed software on a professional basis,

07:27 both from experts and from novices in a company.

07:33 And it's producing five times as much code, but you get five times as much bad code from

07:39 bad developers.

07:41 I'm just saying, there is a, like, let's say we have five times the amount of code or five times the product, you know, do more things.

07:50 That's 5xing your code base that you have to maintain in the future, too.

07:55 And we really haven't figured out how to deal with the increased maintenance cost of this agent-driven software yet.

08:04 Yeah, I agree with that.

08:06 Also, the test-driven development, I think we didn't get the gains out of that because people were teaching it wrong.

08:14 Just kind of a point from my book.

08:16 Of course.

08:17 But I think also there's a difference between full-on extreme programming and just, hey, let's make sure we have tests for our code.

08:25 Yeah, there's also, should we test our code and should we unit test it?

08:28 And that's the big part that I get.

08:32 But also, can we scroll up to that complexity chart?

08:36 or the little graph, I think that AI agents are going to not drive down complexity.

08:42 I think we might get efficiency gains, but I don't think,

08:47 I think we're going to get some, the complexity is going to go up just like it did with cloud.

08:52 You know, what's really interesting about all this discussion,

08:54 and I'm not disagreeing with you on this.

08:56 I think it's, if people have the opinion that are just going to like cut,

09:01 set these things loose on code bases, or especially on greenfield projects,

09:05 you're going to end up with all sorts of mishmashes of stuff.

09:09 Like, oh, this time it decided it wanted to react, but last time it used Vue.

09:12 Like, now I have to know two frameworks.

09:13 Like, why am I doing this, right?

09:15 Yeah.

09:16 There are a bunch of engineering practices and tools to apply to this stuff to get much more constrained,

09:23 uniform output out of it than just letting it go free, right?

09:26 And also, to Martin's defense, he says, like, look, this is not vibe coding.

09:30 This is not just letting the thing go.

09:32 This is, like, engineer plus...

09:34 Working with it.

09:35 these tools right like human in the loop all the way and even if we can get like your expert

09:40 engineers at your company to work twice as fat like get twice as much productivity out of them

09:44 and they're going to actually be happier because they're um it's like they've got a second brain

09:50 working with them even 2x like is incredible to get incredible yeah to get your best engineers

09:58 um to get to figure out stuff faster also um even not generating code but even just having stuff

10:05 explain it to you. Like, how does this algorithm work? What should I care about?

10:09 Asking it what tests you should write, asking it where the problem areas might be. Those are

10:15 incredible things that we couldn't do before without trying to pull other people off of their

10:20 own projects. So, yeah. Yeah, absolutely. So two more thoughts before we wrap this up quickly.

10:27 One down at the bottom here talks about, hold on before I lose track of where I was. Yeah,

10:33 Greenfield. Okay. So one objection is just not in a header sort of thing. One objection that I hear

10:37 a lot is LLMs are only good at Greenfield projects. And you were kind of talking about that as well,

10:43 Brian, but I actually strongly disagree with this based on my experience. And so does Martin,

10:48 by the way. Yeah, I do too. So I think when you turn an agentic LLM loose on a Greenfield project,

10:55 it just does whatever is popular on the internet that it's done, or it thinks it's trained on or

11:00 whatever, when you turn it loose on a greenfield project, if you're careful and you set up the

11:04 guidelines, it can follow the same patterns that are already established in the code and use the

11:08 same libraries and use the same techniques. And I just used, I spent, I would say probably an hour

11:15 coming up with a prompt to do a security review for some of my code, an hour before I started,

11:22 even before I try that, working on exactly what I wanted it to do, how I wanted to do it,

11:28 how I wanted to go about fixing it.

11:30 And I got what looks like top tier security pen testing analysis on a code base.

11:36 And I thought that is awesome.

11:38 And that's because it was not a greenfield project.

11:40 It was thousands and thousands of lines of code that had been around for a long time

11:44 with established patterns of solving things.

11:46 And it was very, very, very good.

11:48 So yeah, I would like to put it on the world that that is when done right.

11:53 That is not, I think greenfield projects are less good, not better.

11:56 Yeah.

11:57 Because they have nothing to go on.

11:58 right they just go on whatever they feel like i haven't really done a lot of greenfield on

12:03 stuff i think greenfield for for throwaway code or for just like uh like scripts that you it just has

12:10 to get the job done sort of the internal thing i think those are fine but um oh gosh i had an

12:16 incredible recent experience with just um getting stuck on an algorithm that was too slow and uh

12:23 i spent an hour with an llm uh and an agent um trying to um get it faster and it was like an

12:31 intense hour you know yeah exactly and then i just threw it in a branch and slept on it and

12:37 came back the next day and made spent another hour trying to make sure i understood all of it

12:43 and i and um and tweaking it more there were some non-pythonic things that i got rid of it had

12:48 recursion in there and i'm like let's get rid of that and we actually made it faster than we did

12:53 before so spending a like don't don't stop with it works go a little bit further to make sure that

12:59 you can maintain it in the future it doesn't take that much extra time and you're going to still be

13:03 proud of it and it was an incredible experience and i'm definitely going to do that again so yeah

13:09 definitely should be partners like a like a super excited coding buddy not not just a junior you just

13:16 send stuff to and make it go and then i but i also spent some time an hour recently or two

13:22 reviewing some test code from a junior developer and i obviously this stuff was just spit out by a

13:30 agent and um and it didn't make sense and i and so it just took time away for me to review bad code

13:39 and that's going to take away from your experts as well so yeah yeah that's a very good

13:44 Good point.

13:45 It is indeed.

13:47 All right.

13:47 We should have a warning or something about that, Brian.

13:49 A warning, yeah.

13:50 So last episode, we talked about deprecation warnings.

13:55 And I have to admit, I didn't do enough research on that.

13:59 So I'm glad that listeners chimed in.

14:01 We got a couple of listener feedbacks.

14:03 One of them I'm going to credit because we got his email right up here.

14:06 John Hagan mentioned you should totally use from warnings, import deprecated,

14:12 And instead of calling your own, calling warn, use the decorator deprecating.

14:17 And I totally, now after playing with it, totally agree.

14:21 It's awesome.

14:21 So let's back up a little bit.

14:23 We started with this Seth Larson article about deprecations via warnings don't work for Python libraries.

14:29 And I kind of agree after experimenting because I played with it a bit.

14:35 And one of the things that I found out was in, so in the Python documentation, one of the things that's cool.

14:42 somebody mentioned this and I didn't really know about it is development mode.

14:45 So there's dash X dev and you can also set it with a Python dev mode environmental variable.

14:52 And it sets a bunch of stuff, including setting the default warnings to W.

14:57 And the reason why that's important, I'm like, why is that important?

15:00 The reason is important in Seth alludes to it, but doesn't point it out directly,

15:05 is in the dash WR argument for Python, you could say just ignore,

15:11 like ignore all warnings.

15:13 And I think it's just, you can either ignore all warnings

15:16 or it even tells you, for example, to ignore all your deprecation warnings,

15:20 do this.

15:21 Ouch, I kind of wish they hadn't mentioned that.

15:25 Don't encourage people, come on.

15:27 Don't encourage people.

15:28 Instead of ignore, somebody else, and then again, sorry for whoever mentioned this,

15:33 but somebody mentioned just use once.

15:36 Ignore, like dash W once makes any warning in your code show up once and not a whole bunch of times.

15:43 And it's the whole bunch of times that I think people turn it off for because it fills up

15:47 your CI logs and everything like that.

15:49 But you really should see it at least once.

15:51 I like the once.

15:51 You know what else I like about once?

15:53 The W once is the pronunciation is the same as just once.

15:57 That's just once.

15:58 Yeah.

16:00 Okay.

16:00 So I played with it.

16:01 I looked at this deprecation warning thing.

16:04 And we'll link to the documentation in Python as well.

16:10 But you can do it, combine both solutions, which I love.

16:15 So you can just go ahead and declare your own warning and use the deprecated.

16:20 And so I tried this out.

16:24 So what you do is you just say, create your own, just a class and derive it from user warning.

16:31 And you don't have to import anything for this.

16:32 This is just built in.

16:34 It doesn't have to do anything, just a passing class.

16:36 But then if you use this deprecated decorator and pass your new warning category as deprecated,

16:49 and this sounds complicated on the air, it's not.

16:53 We'll do a code example.

16:55 But what you get is this, I had it, warning both.

17:01 Oh, yeah, it's over just right on the same screenshot.

17:04 The cool thing is that mypy and other type checkers, when you use the deprecated, will flag that it's a problem.

17:13 And I was doing it.

17:14 I think PyCharm does the same thing, but I was doing it in VS Code.

17:19 And what happens if you've got this deprecated decorator is that the IDE will just cross it out.

17:25 And they're like, why is this crossed out?

17:26 And if you hover over it, it'll say, oh, this is deprecated.

17:29 Yeah, it's like a strikethrough.

17:30 It says, don't use it.

17:31 I love it.

17:32 Yeah, it's very visual and it will make you like look at it.

17:36 So I think that instead of just calling more and yeah, please use the deprecated.

17:42 And then I was playing with pytest as well.

17:45 And what did we get?

17:47 I wrote it down in the show notes.

17:50 Yeah, you want to pass in the dash W just like you would for Python.

17:54 If you do dash W error within pytest, at least in one of your tests to find out actually all of the tests.

18:02 So that'll turn.

18:03 Well, even by default, pytest will warn you and do the warnings.

18:07 But if you're in CI, maybe you're not watching those.

18:10 So in CI, having a check for those deprecation warnings with dash W error will flag all those failures.

18:18 So anyway, lots of great information from readers.

18:22 So thank you for listening.

18:24 We got, if they read the newsletter you send, they could be readers.

18:29 Yeah, they could be readers.

18:31 John pointed out that you can set an environment variable,

18:34 and people may be hesitant to just set an environment variable for their computer

18:40 to turn Python into dev mode, which makes it slower potentially.

18:44 But if you create a virtual environment, which you should be doing,

18:48 there's an activation script in that virtual environment,

18:51 And you can just go and export that environment variable

18:56 set to debug or whatever mode you want to set it to.

18:59 - Oh yeah.

19:00 - Only when you activate that virtual environment.

19:02 So if you're on a particular project, you're like this one really,

19:05 I don't care about speed right now, I just care about getting things right.

19:08 Tweak its virtual environment, that doesn't have really many knock on effects.

19:11 So that's a cool hack I think.

19:13 - Yeah, it's a great place to throw in temporary pytest flags as well or any runtime flags.

19:19 - Exactly, it's not just about This dev thing, like it's like a little shell script basically.

19:24 Yeah.

19:25 Indeed.

19:26 You could do it for open source things, Brian.

19:27 I love open source.

19:29 So, oh yeah.

19:30 So here's another article.

19:31 And this one is by Thomas Dupree called How Foss One and Why It Matters.

19:36 This is a pretty interesting article.

19:38 And what it looks at open source, free and open source software angle from is not just

19:44 why do people like writing open source software?

19:46 Why do they like it better than having locked away software or having to pay or having bugs you can't fix or black box security issues potentially?

19:56 As we've seen lately, open source has its whole supply chain story on that.

20:00 That's different in a different way.

20:02 But anyway, it really looks at it from why has it won from a company perspective, especially large companies.

20:09 Okay.

20:10 Okay.

20:10 So it's really interesting.

20:13 So it says like, look, why did it win?

20:16 Well, people want to pay less.

20:19 So paying less, aka free software, that's great, right?

20:23 Well, how do companies make more money?

20:25 They either make more profit or they have fewer expenses for a fixed level of profit.

20:30 So not paying for software is great.

20:32 But that's not just open source software.

20:34 That's for everything.

20:35 And so companies implement what's called cost control.

20:38 So business term for making buying things painful, hard, and time consuming as possible.

20:44 So employees will either not or hate doing it.

20:47 All right.

20:48 So an example is like, hey, I need a cool date picker for our site that imagine open source doesn't exist.

20:54 Well, someone's going to have to start by creating a ticket to get this date picker.

21:00 And then, well, we have to research the various commercial options.

21:05 We could go to procurement and have them find it.

21:07 But what do they know about date pickers?

21:08 So we're going to do that ourself.

21:09 We're going to get a report.

21:10 We're going to bring it to procurement.

21:13 And when we get there, then procurement says, okay, great.

21:16 You're going to go with this company? Fine.

21:17 So what we're going to do is first we're going to need to set up a vendor agreement with them

21:21 because it turns out they're not currently a vendor of ours.

21:24 So we have contracts, we have reviews, we have negotiations, all for a stupid date picker, right?

21:30 It's just like, what is going on?

21:32 And then on top of it, there's all these copyright laws like indemnification of like,

21:37 you prove you haven't stolen from another company then to resell this to me in like some other way

21:42 of that stuff, it's like eventually you get permission to buy the thing and then you could

21:47 start using it. So open source software enters the scene. It says this comes with a pre-agreed,

21:52 pre-reviewed license, MIT, Apache, whatever. And so the lawyers are already like, yep,

21:57 we know what that is. We know how to deal with that. There's no pain. So there's no

22:01 vendor research, vendor approval, contracts, copyright, all that kind of stuff. And so it

22:07 really interesting like is this hack to skip around this like make buying stuff at companies

22:13 super hard right so it wasn't always that way though it took a long time for companies to

22:19 realize that open source was fine yes that's for sure i mean they did have to work through it but

22:24 i think once they kind of it feels like they had to go through this the same process we're kind of

22:28 describing once in a sort of an abstract sense like okay then well now you can just go you know

22:33 know what I mean? It says, Hey, look, it also works both ways. If you're a FOSS maintainer,

22:39 the miracle of your software passing, bypassing copyright laws and liabilities and procurement

22:44 means that you can get your software out there and have people use it pretty easy, right? Because

22:49 your stuff is much easier to adopt because it's open source. I mean, I've been on the vendor side

22:55 of these negotiations and paperwork and accounting and legal more than once. And it sucks. It sucks.

23:03 I mean, look, Hey, people want to put me in as a vendor and buy stuff.

23:06 I'm here for it.

23:06 But at the same time, it is not fun.

23:08 Right.

23:09 And there needs to be like, if you're just a hobbyist, like, well, no.

23:12 All right.

23:12 So the final bit of this article, the final bit of this thought piece is you can't go back.

23:16 So if we're trying to solve, if we're trying to solve the sustainability of open source

23:22 software, you have to keep in mind the reason, one of the main reasons it's so popular is

23:27 it skipped the copyright rule stuff.

23:30 It skipped the vendor onboarding and all these things.

23:33 So if your solution to fix sustainability is to recreate any of the supply chain framework problem, your solution is dead on arrival.

23:41 So I think that's what this is why I wanted to bring up this article.

23:45 I put it at the end of the year.

23:46 It's kind of like I would love to see more sustainability options for open source.

23:51 But I do think that this guy is on to something here.

23:54 I do think that Thomas is on to something with his skipping the legal, skipping the procurement.

23:59 And if we put it back and say, well, you got to set up a vendor agreement with us again.

24:02 And then you're unraveling a lot of the things that made it a really good fit.

24:07 Yeah.

24:08 The article does a lot more detailed explanation than I did,

24:11 but they're for people to think about.

24:13 I hope this, yeah, I hope we don't go back.

24:17 There are pressures to push it back.

24:20 Like you were saying, there's the projects that just, they can't,

24:24 they know that enterprise is using it and they're not getting paid.

24:27 And that isn't as a bummer.

24:31 And if you're not charging anything, you can't just make it up in volume.

24:37 We've tripled our revenue from what it was last year.

24:39 Still zero.

24:40 With things like trying to secure the supply chain, we are, I mean, even open source is part of the supply chain, whether or not you want to believe it is.

24:51 And so there are pressures to, you know, put SBOMs on or the software bill of materials to verify all your subcomponents and all that stuff.

25:01 Python is helping to make that easier for individual maintainers of projects, which is cool.

25:08 But it's still some extra work.

25:10 And I don't think it's fair that maintainers are having to do that work.

25:15 And they don't benefit from it.

25:17 The companies benefit.

25:19 And we do need to find a way to get money to vendors better or money to contributors.

25:27 Yeah, I 100% agree.

25:28 I do.

25:30 But yeah.

25:31 I don't have a great direct, like force them to do it type of answer.

25:35 But yeah.

25:36 Hopefully many of them will see like, hey, we benefit from this thing.

25:39 If we were a major sponsor of this project, we could have the ear of the maintainer team

25:46 to get the thing that we really want.

25:47 I think that's a possibility.

25:50 Yeah, there might also be some like maintenance agreements sort of stuff.

25:55 It's definitely open source, but also whoever the main maintainer is,

26:02 is for a small fee promising to look at your defect reports

26:08 or things like that.

26:09 Yeah, there's this whole productized consulting sort of thing

26:13 I think would be pretty good, where it's like you're going to pay,

26:15 basically I'm going to pay you a retainer and you have a certain amount of credits you can redeem

26:20 that expire at the end of the month for me to potentially come and do exactly like what you're suggesting.

26:24 And if you don't use it, that's fine.

26:25 but I'm here at the drop of a hat if you need me, sort of.

26:29 Yeah.

26:30 You pay me $5,000 a month and I may or may not have to work for you that month,

26:33 but you know what, that'd be good.

26:35 But at the very least, or even having lower ones so more people do it

26:38 and to make sure that things are actually stayed maintained

26:43 because there's a lot of stuff that's just done and you can't tell whether or not it's really maintained.

26:48 Anyway.

26:49 Yeah, that's 100%.

26:51 100%.

26:52 In fact, you might even want to go and find just a complete,

26:55 I don't even put it on GitHub anymore.

26:56 That's how much I'm changing my mind about open source.

26:59 Yeah, so this next topic was going to be about looking for GitHub alternatives.

27:09 And so I just left it as the title.

27:12 Should I be looking for GitHub alternatives?

27:14 And why am I talking about that?

27:16 I mean, GitHub's awesome.

27:17 Why would you?

27:18 Anyway, I think it's great.

27:19 I'm still happy with GitHub.

27:21 But they sort of fumbled recently.

27:23 Did you hear about all this, Michael?

27:25 yes with the billing oh yes I heard about oh yeah so so what happened what bothers me more even is

27:31 the the clear lack of craftsmanship and care around the code that runs these it's like you get janky

27:38 code and we're gonna charge you oh and our bug is also gonna sometimes make it run for hours and

27:42 then we'll charge you still for that too yeah so there's some pricing changes and the message

27:49 pricing changes and they like released it on December 15th and then they they think and then

27:53 just recently updated it i can't i don't know when the update was on oh the original announcement

27:59 was on the 16th um there's an update to it so they um the gav actions it's way popular than they

28:08 thought it would be and actually like just tons of people just switched from and it happened at a

28:13 similar a lot of times where people were like travis was imploding so people were trying to

28:17 uh leave travis and were like oh you have actions is here let's just use that um that's part of it

28:24 But it also benefited GitHub a lot.

28:26 A lot of projects started using it more.

28:31 However, I get that they have to pay for that compute somehow.

28:35 However, they've said, let's see, they're going to have GitHub or hosted runners

28:43 are going to reduce their price by 39%.

28:46 And I actually didn't realize that they were charging because apparently I don't use it enough to get billed for it.

28:52 But in the announcement, they also said that you could see the hosted the non hosted runner.

28:58 So like the code that you you've got your own computer set up to run your stuff.

29:03 They were going to charge for that, too.

29:05 Look, I think that's insane.

29:09 It was not a lot.

29:09 It was like two tenths of a cent per minute or something like that.

29:14 But but that's like it's just sitting there waiting for your GitHub runner, your get runner to finish.

29:21 Why would they charge for that?

29:23 Anyway, I don't know.

29:24 There's been a change.

29:25 So we're going to link to the announcement of the pricing change.

29:29 I didn't get too much into the details of the pricing change,

29:34 but it's kind of weird to charge the same amount for both,

29:37 whether or not you're using a hosted runner or your own runner.

29:41 That's weird.

29:41 So they've actually backed off.

29:43 So they're going to postpone the billing for the self-hosted.

29:49 They didn't say they're going to not do it, though.

29:51 It's just postponed.

29:52 Yeah, that's weird.

29:53 So I get the argument like, wow, we thought we'd have to buy 100 computers and we're on our 100,000th VM.

30:00 We've set up this as a little out of control.

30:02 That doesn't apply to self-hosted.

30:04 Well, I mean, the actions are still running, so they're not really charging that much for the actions.

30:10 Just the, I mean, all the rest of the stuff is mostly coming for free.

30:17 It's just.

30:17 Right, right.

30:18 But I mean, if you have a self-hosted GitHub Action runner,

30:21 they're not paying for the compute to run it because you're self-hosting.

30:26 Yeah.

30:27 Like maybe, like, and if they are having to, I mean, they have to have something that sits around

30:32 and like waits for it or something.

30:33 I don't know.

30:34 But figure out how to do that way cheaper.

30:37 It should be like super cheap.

30:40 Anyway, because that's like, that's one of the reasons why people have their own runner

30:43 is to save on compute.

30:45 So yeah, that was weird.

30:47 So I went ahead and like, you know, why not look at other stuff?

30:50 So let's look at some other.

30:52 That's the warning thing.

30:53 Some other alternatives.

30:55 So I found this article.

30:56 I just searched for it.

30:57 There's four GitHub alternatives that are just as good or better.

31:02 And there's some that I hadn't heard of.

31:03 So this is kind of fun.

31:05 I hadn't heard of Codeberg.

31:06 So nonprofit community-led effort that provides Git hosting and other services for free and open source projects.

31:14 Okay, so it's not for private projects or something, but there's a lot here.

31:19 So maybe something to look into.

31:21 But I don't think that GitHub is charging that much for open source either.

31:26 But it's fun to look at some of these alternatives.

31:28 Yeah, I think Codeberg only lets you have open source.

31:32 Just only open source.

31:33 Yeah, it's like free.

31:34 You almost got to apply to a join sort of thing.

31:39 And then Bitbucket.

31:40 I mean, like, I didn't, I guess I forgot it's around.

31:44 Sorry, Bitbucket.

31:45 I did too.

31:46 I use SourceTree all the time, which was, I believe, made sort of as the front end of Bitbucket if you want to desktop thing.

31:53 Yeah.

31:54 And still, I forgot Bitbucket exists.

31:57 So, Bitbucket, yeah, it's not, oldest established competitor of GitHub.

32:03 I think it predates GitHub.

32:05 I'm not sure.

32:06 But it launched around the same time in 2008.

32:09 it's still maintained it's still there so you can um and the interface is a lot better than it was

32:14 way back in the 2008 9 10 time frame when i was using it but uh bit bucket git lab and actually

32:21 git lab's a solid alternative i use uh git lab at work and um the thing that yeah i like git lab

32:28 uh definitely a an option to look into it uh git ea g g-i-t-e-a haven't heard of this before but

32:37 it's around as well and then while i was looking around for this i also came up came around some

32:42 some comments on socials about tangled it's an alpha it's a new it's a new thing it came out

32:48 this year i think um a uh tightly knit social coding so they're really trying to um and they're

32:57 launching as a lightweight lightweight github repo get repo hosting but the way they're

33:04 dealing with it, I think, is the pipelines and the runs are running. I don't know if they have

33:09 runners in the cloud. I think it looks like they're mainly trying to get you to run your own runners.

33:15 So it's interesting. I could be wrong, but there are definitely some different options around there

33:21 if you really do want to get off GitHub. I like GitLab and GitHub mostly.

33:28 I'm always tempted to do some self-hosted thing. I love the idea of it so much.

33:33 Yeah.

33:34 So I have to talk myself off the ledge periodically.

33:37 And if you're doing something just for you, I think it's cool to pick something based on features, right?

33:43 Or some kind of philosophy of the company.

33:46 Like this one is only open source, or this one is super privacy,

33:48 or this one is European-based or whatever, right?

33:52 However, if you're doing open source and you actually want it to be used by people,

33:57 there's no other option than GitHub.

33:59 Well, okay.

34:00 I think if you really want people to interact with it, GitHub, and contribute.

34:07 I mean, contributors, yes, exactly.

34:09 And file defects and all that sort of stuff, GitHub.

34:14 But I've seen a lot of projects that a lot of the community

34:17 is just complaining, either complaining or asking for features that aren't even part of it.

34:24 So you're doing, basically, if you don't want interact, if you want people to use it, it needs to be on PyPI for Python.

34:32 But if you really don't want people to file defects and contribute junk,

34:39 yeah, I think switching to GitLab or something like that totally makes sense.

34:42 Yeah.

34:43 I mean, it's like saying, I don't like that Twitter went away,

34:45 so I'm going to set up my own private social media and then invite my friends to join.

34:50 They may or may, they probably are not going to come.

34:52 If they do, they're probably going to not visit it after three days.

34:55 You know what I mean?

34:55 It's like, even though these things are awesome in GitHub

34:58 as being not ideal in some ways.

35:00 Yeah.

35:01 The truth of social stuff is you got to be where the people are.

35:04 Otherwise, it's tough to work with.

35:05 So anyway, that's mostly a note to myself in the future.

35:08 Anyway, okay.

35:11 All right.

35:12 How are we feeling about extras?

35:13 I have a couple extras, but why don't you go?

35:16 Okay.

35:16 Let's talk about PyCharm for a second.

35:19 So I'm a big fan of Ruff.

35:21 No doubt about that.

35:22 I'm also a fan of Pyrefly, which I've been using a lot lately,

35:26 And ty, which I believe ty just went into beta.

35:29 Shouldn't that be one of our items?

35:30 I believe it should be.

35:31 It probably should.

35:33 But ty, the one from Astral, that is sort of the high-performance companion or frenemy of Pyrefly,

35:40 they both are now in beta mode.

35:44 And with the latest release of PyCharm, it expands its LSP support

35:49 so that it has native integration for Ruff, ty, and Pyrefly plus Pyrite.

35:55 And this news comes to us from Daniel Muldmer, if I haven't said so.

35:57 So thanks, Dean, for sending that in.

35:59 And there's actually a whole link, a page which I'll link to about the LSP support and how you turn that on if you want.

36:06 So you can have, like, native Ruff integration and so on.

36:09 So anyway, shout out.

36:11 Shout out to that.

36:12 Also, RUF's page has a setup for how to do it in reverse.

36:15 The LSP being for language servers always throws me.

36:19 So I'm like, PyCharm now supports LISP, but that's weird.

36:22 I know.

36:24 Also, it feels redundant, an LSP server.

36:28 It's already a language server.

36:29 I guess a language server, protocol server.

36:31 Shouldn't it just be a language server?

36:33 I don't know.

36:33 It's like saying it's an HTTP website or something.

36:38 I don't know.

36:39 It's HTTP protocol.

36:41 Yeah.

36:42 Right.

36:42 It's an HTTP protocol website that you access with your browser now.

36:45 Okay.

36:45 Last thing.

36:46 I didn't save the link to this, but I thought this was a fun...

36:52 I saw this on xTwitter, and it's just like a little sign off,

36:55 like sort of wishing you well or like, take care till next time I see you.

36:59 But here's the developer version.

37:01 May your bug tracker be forever empty.

37:03 Oh, nice.

37:03 Yeah, very nice.

37:04 It's a little bit of a play on Hunger Games, I believe.

37:07 May the odds be forever in your favor.

37:08 You know, that sort of thing.

37:09 Yeah, and like I was saying, if you really want your bug tracker to be empty, move it away from GitHub.

37:15 Yep.

37:17 A couple of things, just a reminder to people, I am taking this the rest of December off from updates to the lean TDD book,

37:25 but, but this is an attempt to explain to people how to actually get productivity

37:30 gains from test driven development.

37:32 But I'll pick it up in January.

37:34 I'm hoping actually to finish the, finish the entire first draft in January.

37:37 That's the goal.

37:37 That's a, that's an aggressive goal, but,

37:40 but I have all the stuff I want to do.

37:41 So we'll see.

37:43 Okay.

37:44 Finally, pie, the pie test course.

37:46 I just had somebody asked me this morning, sent me an email and said, hey, I bought the book.

37:51 Love the Python Testament by this book.

37:54 And I'd like the course.

37:56 Can I get a discount?

37:57 And I just love people that just ask.

37:59 So I gave him a discount, of course, but also so you can always email and ask.

38:04 But I also just decided to throw a 50% off sale for the Christmas time.

38:10 So last minute Christmas shopping for yourself.

38:13 I'll put this in the show notes, But if you use the code Xmas, X-M-A-S 2025,

38:19 I'll give you 50% off.

38:21 Very, very nice.

38:22 And I'm looking forward to a more efficient and error-free 2026 Christmas

38:28 after Rudolph and team use your discount, learn test-driven better.

38:33 And then, you know, next year round, their deliveries will be more error-free.

38:36 You're doing a service for all the kids.

38:39 Yeah.

38:41 All right.

38:41 All right.

38:42 We got a couple of funny things.

38:43 We do.

38:44 One is mine, one is yours.

38:46 So what if you have errors in your code?

38:49 Well, that's what structured error handling is for.

38:53 Exceptions, you know, try, catch, try, accept, depending on your language.

38:57 But what do you do when the error happens, Brian?

38:59 What do you do when the error happens?

39:01 One possibility is to log it.

39:02 You've got to already have your login set up.

39:04 So, you know, there's a few steps.

39:05 I guess you could print it.

39:06 That's a bit of a help.

39:07 Maybe you just have a beep, play the beep sound when an exception happens.

39:11 I don't know.

39:12 Well, this person decided to write a simple two-liner.

39:17 This is in JavaScript in the example, but it could be just as well.

39:20 It says, if I catch an exception, I'm going to create a string that's

39:25 HTTP colon slash slash stackoverflow.com slash search question mark Q equals.

39:30 And you put the exception message in the end and then you open a browser to that.

39:34 Wow.

39:35 Problem solved.

39:36 Old school.

39:37 That's old school.

39:37 I think the modern version is to just call an open AI API.

39:41 Yeah, just ask your agent to run it, catch all exceptions, and fix it for you with PRs.

39:48 Exactly.

39:49 Yeah, just feel free to go ahead and auto-commit and publish it at production.

39:52 I don't need to review it.

39:53 Yeah, but be sure to label it with the prompt for that we discussed last week.

39:58 Exactly.

40:00 Let's see.

40:01 Any good comments?

40:02 Is this real?

40:02 This is hilarious, whether or not.

40:04 This is perfectly fine for local prod as well, as far as I'm concerned, production as in live.

40:10 Cutting out the middle, man.

40:12 Literally saves a precious three seconds.

40:14 3.531, actually.

40:18 Oh, and someone literally did write a ChatGPT alternative in the comments.

40:23 Nice.

40:24 Yeah, there you go.

40:25 Yeah, perfect.

40:26 So it even came up with a prompt for you.

40:28 Following error, it's occurred in my JavaScript application.

40:30 Please write code that resolves this issue.

40:31 Respond only with code.

40:33 Here's the exception.

40:35 Oh, yeah.

40:36 Pretty good.

40:37 Pretty good stuff.

40:37 All right.

40:38 This one's for you.

40:39 You got it.

40:40 Okay.

40:40 So last week, what did we title our podcast episode?

40:44 Something like LinkedIn something?

40:47 Anyway, somebody responded with, oh, LinkedIn Cringe.

40:53 Somebody called Archtoad said, LinkedIn Cringe made me think of this.

40:59 It's AI blockchain kombucha startup.

41:02 Anyway, this comes from Archtoad referring to a post by Tim Kellogg

41:10 using nano banana prompt, create a super annoying LinkedIn profile, which is amazing.

41:17 So the profile is great.

41:19 The with a with a like a hero image with somebody giving a speech and the on the screen is disrupt

41:26 or die, which is great, great screen capture.

41:30 But the let's see, let's read his profile.

41:33 He's a visionary, 10X growth ninja, chief evangelist at stealth mode, at a stealth mode AI blockchain kombucha startup.

41:43 That's awesome.

41:45 Helping Fortune 500 CEOs maximize human synergy means nothing.

41:51 A TEDx speaker applicant.

41:56 Not even TED, just like a TEDx.

41:58 Yeah, sure, TEDx, which is like the original.

42:01 I applied to speak.

42:03 I didn't get it, but I applied.

42:06 Forbes 30 Under 30 nominee.

42:08 Oh, my gosh.

42:09 A dog dad, coffee addict.

42:12 Why are you still reading this?

42:13 Let's connect.

42:17 About Bryden just doesn't just work.

42:19 Bryden shifts paradigms.

42:22 That's awesome.

42:24 Anyway, really good things I'd like to see in a LinkedIn profile.

42:30 This is pretty good.

42:31 I didn't realize that this originally came from Nana Banana.

42:34 I feel like the challenge is on for the follow-ups.

42:39 Yeah.

42:40 Pretty amazing.

42:40 Pretty amazing.

42:43 Anyway, it's been an amazing run for us and an amazing 2025, I think.

42:49 Things are going good.

42:50 And, I mean, aside from, like, you know, our entire country imploding.

42:55 But, you know, other than that, things have been going pretty good for you and I.

42:58 So it's been a, you know, the backhanded compliment curses, may you live in interesting

43:04 times while things are interesting.

43:06 Definitely interesting.

43:07 I do want to say though, thank you to everyone for listening this year, all the years and

43:11 here's to 2026.

43:13 Yeah.

43:14 happy holidays and hope everybody has a good new year.

43:17 Yep.

43:17 Bye.

43:17 Bye.

43:18 Thanks, Brian.