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

This is episode 463, recorded December 22, 2025.

I'm Brian Okken.

And I am Michael Kennedy.

And this episode is sponsored by us.

So support us by heading over to Michael's courses, my courses, Talk Python Training or python test.com, or just go over and see what we got at the pythonbytes.fm.

Let me add one more thing real quick there, Brian.

Sorry to hijack your intro, but hey,

we're coming up on 2026 and it's about time to be scheduling sponsors on the ad calendar for the next year.

So if companies out there, if you're listening, you're like, why does my company not support Python Bytes and sponsor it?

Yes, a fine question you should be taking up with your marketing team.

Have them reach out to me.

And right now there's a bunch of openings.

We'll see if they get bought up or not as things go.

But yeah, just send me an email.

Yeah, actually, that'd be great.

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

If you want to reach us for sponsoring or any other ways, there's links on the show page, pythonbytes.fm.

You can also find links to all of our socials.

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

And also, if you'd like to watch us live, you can go to pythonbytes.com/live and see what it is and find the links.

And then as well, while you're there, sign up for the mailing list so we can send you all the links we talk about directly to your inbox.

Alrighty, oh, one more thing before we get started.

We are taking, normally we record on Monday mornings and we are taking next week off and we will be back in 2026.

All right.

Kick us off, Michael.

It's end of the year.

As you said, we'll be back first week of January.

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

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

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

They'll make you really evaluate the situation.

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

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

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

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

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

Yeah.

And what are the consequences?

Right.

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?

Or does it mean something else?

We'll see.

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

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

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.

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.

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

Kubernetes, sure, they're advancements and they help in some way or another for various things, but they're not bending the curve dramatically on how we write software, how much more we get done, and so on.

Somewhat, but not massively.

But they say, let me see if I can find it.

Yeah, here we go.

The economics have dramatically changed now with agentic coding.

And I agree.

I think it really has.

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

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.

And Martin thinks so as well.

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

And I think so too.

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.

A lot of other things.

So in a lot of just sort of how complexity has grown over time, instead of these things making us able to write more software or better software, a lot of times it's just handle more complex software or kind of doing the same thing.

So where's the 90% savings come from?

So he says, like you, probably I was incredibly skeptical of a lot of AI coding tools at the beginning of the year, but things are changing fast.

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

How do you do it?

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

You're going to set up continuous integration.

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

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

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

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

And that's just direct labor, right?

You've got all the management.

And one of the things that's really interesting about this article is the mythical man month aspect of this.

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

Well, what if we add four people to it?

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

Like, wait, why is that not half a week?

You know, it's like the coordination, the communication, the in factorial ways in which there can be like blocking or communication or meetings or coordination and so on.

And so these coding tools have got really, really good.

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

You don't have to have it working with three other ones of them so that it can coordinate different skill sets and so on.

And so in a sense, it really lowers the number of connections in that mythical man month, but still adds a lot of capabilities.

So pretty interesting.

So final takeaway is like on the face of it, this seems like incredibly bad news for the software development industry.

Indeed.

But a look at history.

Let's see.

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

Instead of just burning it in an open pit or whatever to like heat something, we put it know the steam engines and it does way more work per you know joule of energy or whatever right it says look at least this guy martin thinks this applies jevon's paradox also is going to apply to software that when something becomes cheaper to produce it's not that we just use it less it's like well we've got five developers but now they're way more efficient so let's get rid of four of them that's one possible outcome the other is like let's just build five times as much software as we used to, right?

And so an example is from history is when coal became way cheaper, its use skyrocketed, not cheaper, efficient, right?

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

But in fact, it actually blew up way, way more.

So super interesting.

And I think there's something to that.

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

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

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

I think there is a lot of light in demand.

I am dealing with both agent-driven or agent-developed software on a professional basis, both from experts and from novices in a company.

And it's producing five times as much code, but you get five times as much bad code from bad developers.

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.

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

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

Yeah, I agree with that.

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

Just kind of a point from my book.

Of course.

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.

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

And that's the big part that I get.

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

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

I think we might get efficiency gains, but I don't think, I think we're going to get some, the complexity is going to go up just like it did with cloud.

You know, what's really interesting about all this discussion, and I'm not disagreeing with you on this.

I think it's, if people have the opinion that are just going to like cut, set these things loose on code bases, or especially on greenfield projects, you're going to end up with all sorts of mishmashes of stuff.

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

Like, now I have to know two frameworks.

Like, why am I doing this, right?

Yeah.

There are a bunch of engineering practices and tools to apply to this stuff to get much more constrained, uniform output out of it than just letting it go free, right?

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

This is not just letting the thing go.

This is, like, engineer plus...

Working with it.

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

engineers at your company to work twice as fat like get twice as much productivity out of them and they're going to actually be happier because they're um it's like they've got a second brain working with them even 2x like is incredible to get incredible yeah to get your best engineers um to get to figure out stuff faster also um even not generating code but even just having stuff explain it to you.

Like, how does this algorithm work?

What should I care about?

Asking it what tests you should write, asking it where the problem areas might be.

Those are incredible things that we couldn't do before without trying to pull other people off of their

own projects.

So, yeah.

Yeah, absolutely.

So two more thoughts before we wrap this up quickly.

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

Yeah, Greenfield.

Okay.

So one objection is just not in a header sort of thing.

One objection that I hear a lot is LLMs are only good at Greenfield projects.

And you were kind of talking about that as well, Brian, but I actually strongly disagree with this based on my experience.

And so does Martin, by the way.

Yeah, I do too.

So I think when you turn an agentic LLM loose on a Greenfield project, it just does whatever is popular on the internet that it's done, or it thinks it's trained on or whatever, when you turn it loose on a greenfield project, if you're careful and you set up the guidelines, it can follow the same patterns that are already established in the code and use the same libraries and use the same techniques.

And I just used, I spent, I would say probably an hour coming up with a prompt to do a security review for some of my code, an hour before I started, even before I try that, working on exactly what I wanted it to do, how I wanted to do it, how I wanted to go about fixing it.

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

And I thought that is awesome.

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

It was thousands and thousands of lines of code that had been around for a long time with established patterns of solving things.

And it was very, very, very good.

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

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

Yeah.

Because they have nothing to go on.

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

stuff i think greenfield for for throwaway code or for just like uh like scripts that you it just has to get the job done sort of the internal thing i think those are fine but um oh gosh i had an incredible recent experience with just um getting stuck on an algorithm that was too slow and uh i spent an hour with an llm uh and an agent um trying to um get it faster and it was like an intense hour you know yeah exactly and then i just threw it in a branch and slept on it and came back the next day and made spent another hour trying to make sure i understood all of it and i and um and tweaking it more there were some non-pythonic things that i got rid of it had recursion in there and i'm like let's get rid of that and we actually made it faster than we did before so spending a like don't don't stop with it works go a little bit further to make sure that you can maintain it in the future it doesn't take that much extra time and you're going to still be proud of it and it was an incredible experience and i'm definitely going to do that again so yeah

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

send stuff to and make it go and then i but i also spent some time an hour recently or two reviewing some test code from a junior developer and i obviously this stuff was just spit out by a agent and um and it didn't make sense and i and so it just took time away for me to review bad code and that's going to take away from your experts as well so yeah yeah that's a very good Good point.

It is indeed.

All right.

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

A warning, yeah.

So last episode, we talked about deprecation warnings.

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

So I'm glad that listeners chimed in.

We got a couple of listener feedbacks.

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

John Hagan mentioned you should totally use from warnings, import deprecated, And instead of calling your own, calling warn, use the decorator deprecating.

And I totally, now after playing with it, totally agree.

It's awesome.

So let's back up a little bit.

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

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

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

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

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

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

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

The reason is important in Seth alludes to it, but doesn't point it out directly, is in the dash WR argument for Python, you could say just ignore, like ignore all warnings.

And I think it's just, you can either ignore all warnings or it even tells you, for example, to ignore all your deprecation warnings, do this.

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

Don't encourage people, come on.

Don't encourage people.

Instead of ignore, somebody else, and then again, sorry for whoever mentioned this, but somebody mentioned just use once.

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

And it's the whole bunch of times that I think people turn it off for because it fills up your CI logs and everything like that.

But you really should see it at least once.

I like the once.

You know what else I like about once?

The W once is the pronunciation is the same as just once.

That's just once.

Yeah.

Okay.

So I played with it.

I looked at this deprecation warning thing.

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

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

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

And so I tried this out.

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

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

This is just built in.

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

But then if you use this deprecated decorator and pass your new warning category as deprecated, and this sounds complicated on the air, it's not.

We'll do a code example.

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

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

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

And I was doing it.

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

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

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

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

Yeah, it's like a strikethrough.

It says, don't use it.

I love it.

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

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

And then I was playing with pytest as well.

And what did we get?

I wrote it down in the show notes.

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

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

So that'll turn.

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

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

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

So anyway, lots of great information from readers.

So thank you for listening.

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

Yeah, they could be readers.

John pointed out that you can set an environment variable, and people may be hesitant to just set an environment variable for their computer to turn Python into dev mode, which makes it slower potentially.

But if you create a virtual environment, which you should be doing, there's an activation script in that virtual environment, And you can just go and export that environment variable set to debug or whatever mode you want to set it to.

- Oh yeah.

- Only when you activate that virtual environment.

So if you're on a particular project, you're like this one really, I don't care about speed right now, I just care about getting things right.

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

So that's a cool hack I think.

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

- Exactly, it's not just about

This dev thing, like it's like a little shell script basically.

Yeah.

Indeed.

You could do it for open source things, Brian.

I love open source.

So, oh yeah.

So here's another article.

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

This is a pretty interesting article.

And what it looks at open source, free and open source software angle from is not just why do people like writing open source software?

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?

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

That's different in a different way.

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

Okay.

Okay.

So it's really interesting.

So it says like, look, why did it win?

Well, people want to pay less.

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

Well, how do companies make more money?

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

So not paying for software is great.

But that's not just open source software.

That's for everything.

And so companies implement what's called cost control.

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

So employees will either not or hate doing it.

All right.

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

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

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

We could go to procurement and have them find it.

But what do they know about date pickers?

So we're going to do that ourself.

We're going to get a report.

We're going to bring it to procurement.

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

You're going to go with this company?

Fine.

So what we're going to do is first we're going to need to set up a vendor agreement with them because it turns out they're not currently a vendor of ours.

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

It's just like, what is going on?

And then on top of it, there's all these copyright laws like indemnification of like, you prove you haven't stolen from another company then to resell this to me in like some other way of that stuff, it's like eventually you get permission to buy the thing and then you could start using it.

So open source software enters the scene.

It says this comes with a pre-agreed, pre-reviewed license, MIT, Apache, whatever.

And so the lawyers are already like, yep, we know what that is.

We know how to deal with that.

There's no pain.

So there's no vendor research, vendor approval, contracts, copyright, all that kind of stuff.

And so it really interesting like is this hack to skip around this like make buying stuff at companies

super hard right so it wasn't always that way though it took a long time for companies to realize that open source was fine yes that's for sure i mean they did have to work through it but

i think once they kind of it feels like they had to go through this the same process we're kind of describing once in a sort of an abstract sense like okay then well now you can just go you know know what I mean?

It says, Hey, look, it also works both ways.

If you're a FOSS maintainer, the miracle of your software passing, bypassing copyright laws and liabilities and procurement means that you can get your software out there and have people use it pretty easy, right?

Because your stuff is much easier to adopt because it's open source.

I mean, I've been on the vendor side of these negotiations and paperwork and accounting and legal more than once.

And it sucks.

It sucks.

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

I'm here for it.

But at the same time, it is not fun.

Right.

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

All right.

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

So if we're trying to solve, if we're trying to solve the sustainability of open source software, you have to keep in mind the reason, one of the main reasons it's so popular is it skipped the copyright rule stuff.

It skipped the vendor onboarding and all these things.

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

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

I put it at the end of the year.

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

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

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

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

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

Yeah.

The article does a lot more detailed explanation than I did, but they're for people to think about.

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

There are pressures to push it back.

Like you were saying, there's the projects that just, they can't, they know that enterprise is using it and they're not getting paid.

And that isn't as a bummer.

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

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

Still zero.

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.

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.

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

But it's still some extra work.

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

And they don't benefit from it.

The companies benefit.

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

Yeah, I 100% agree.

I do.

But yeah.

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

But yeah.

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

If we were a major sponsor of this project, we could have the ear of the maintainer team to get the thing that we really want.

I think that's a possibility.

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

It's definitely open source, but also whoever the main maintainer is, is for a small fee promising to look at your defect reports or things like that.

Yeah, there's this whole productized consulting sort of thing I think would be pretty good, where it's like you're going to pay, basically I'm going to pay you a retainer and you have a certain amount of credits you can redeem that expire at the end of the month for me to potentially come and do exactly like what you're suggesting.

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

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

Yeah.

You pay me $5,000 a month and I may or may not have to work for you that month, but you know what, that'd be good.

But at the very least, or even having lower ones so more people do it and to make sure that things are actually stayed maintained because there's a lot of stuff that's just done and you can't tell whether or not it's really maintained.

Anyway.

Yeah, that's 100%.

100%.

In fact, you might even want to go and find just a complete, I don't even put it on GitHub anymore.

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

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

And so I just left it as the title.

Should I be looking for GitHub alternatives?

And why am I talking about that?

I mean, GitHub's awesome.

Why would you?

Anyway, I think it's great.

I'm still happy with GitHub.

But they sort of fumbled recently.

Did you hear about all this, Michael?

yes with the billing oh yes I heard about oh yeah so so what happened what bothers me more even is the the clear lack of craftsmanship and care around the code that runs these it's like you get janky code and we're gonna charge you oh and our bug is also gonna sometimes make it run for hours and then we'll charge you still for that too yeah so there's some pricing changes and the message

pricing changes and they like released it on December 15th and then they they think and then just recently updated it i can't i don't know when the update was on oh the original announcement was on the 16th um there's an update to it so they um the gav actions it's way popular than they thought it would be and actually like just tons of people just switched from and it happened at a similar a lot of times where people were like travis was imploding so people were trying to uh leave travis and were like oh you have actions is here let's just use that um that's part of it But it also benefited GitHub a lot.

A lot of projects started using it more.

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

However, they've said, let's see, they're going to have GitHub or hosted runners are going to reduce their price by 39%.

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

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

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

They were going to charge for that, too.

Look, I think that's insane.

It was not a lot.

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

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

Why would they charge for that?

Anyway, I don't know.

There's been a change.

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

I didn't get too much into the details of the pricing change, but it's kind of weird to charge the same amount for both, whether or not you're using a hosted runner or your own runner.

That's weird.

So they've actually backed off.

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

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

It's just postponed.

Yeah, that's weird.

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

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

That doesn't apply to self-hosted.

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

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

It's just.

Right, right.

But I mean, if you have a self-hosted GitHub Action runner, they're not paying for the compute to run it because you're self-hosting.

Yeah.

Like maybe, like, and if they are having to, I mean, they have to have something that sits around and like waits for it or something.

I don't know.

But figure out how to do that way cheaper.

It should be like super cheap.

Anyway, because that's like, that's one of the reasons why people have their own runner is to save on compute.

So yeah, that was weird.

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

So let's look at some other.

That's the warning thing.

Some other alternatives.

So I found this article.

I just searched for it.

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

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

So this is kind of fun.

I hadn't heard of Codeberg.

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

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

So maybe something to look into.

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

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

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

Just only open source.

Yeah, it's like free.

You almost got to apply to a join sort of thing.

And then Bitbucket.

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

Sorry, Bitbucket.

I did too.

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.

Yeah.

And still, I forgot Bitbucket exists.

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

I think it predates GitHub.

I'm not sure.

But it launched around the same time in 2008.

it's still maintained it's still there so you can um and the interface is a lot better than it was way back in the 2008 9 10 time frame when i was using it but uh bit bucket git lab and actually git lab's a solid alternative i use uh git lab at work and um the thing that yeah i like git lab 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 it's around as well and then while i was looking around for this i also came up came around some some comments on socials about tangled it's an alpha it's a new it's a new thing it came out this year i think um a uh tightly knit social coding so they're really trying to um and they're launching as a lightweight lightweight github repo get repo hosting but the way they're dealing with it, I think, is the pipelines and the runs are running.

I don't know if they have runners in the cloud.

I think it looks like they're mainly trying to get you to run your own runners.

So it's interesting.

I could be wrong, but there are definitely some different options around there if you really do want to get off GitHub.

I like GitLab and GitHub mostly.

I'm always tempted to do some self-hosted thing.

I love the idea of it so much.

Yeah.

So I have to talk myself off the ledge periodically.

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

Or some kind of philosophy of the company.

Like this one is only open source, or this one is super privacy, or this one is European-based or whatever, right?

However, if you're doing open source and you actually want it to be used by people, there's no other option than GitHub.

Well, okay.

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

I mean, contributors, yes, exactly.

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

But I've seen a lot of projects that a lot of the community is just complaining, either complaining or asking for features that aren't even part of it.

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.

But if you really don't want people to file defects and contribute junk, yeah, I think switching to GitLab or something like that totally makes sense.

Yeah.

I mean, it's like saying, I don't like that Twitter went away, so I'm going to set up my own private social media and then invite my friends to join.

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

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

You know what I mean?

It's like, even though these things are awesome in GitHub as being not ideal in some ways.

Yeah.

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

Otherwise, it's tough to work with.

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

Anyway, okay.

All right.

How are we feeling about extras?

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

Okay.

Let's talk about PyCharm for a second.

So I'm a big fan of Ruff.

No doubt about that.

I'm also a fan of Pyrefly, which I've been using a lot lately, And ty, which I believe ty just went into beta.

Shouldn't that be one of our items?

I believe it should be.

It probably should.

But ty, the one from Astral, that is sort of the high-performance companion or frenemy of Pyrefly, they both are now in beta mode.

And with the latest release of PyCharm, it expands its LSP support so that it has native integration for Ruff, ty, and Pyrefly plus Pyrite.

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

So thanks, Dean, for sending that in.

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.

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

So anyway, shout out.

Shout out to that.

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

The LSP being for language servers always throws me.

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

I know.

Also, it feels redundant, an LSP server.

It's already a language server.

I guess a language server, protocol server.

Shouldn't it just be a language server?

I don't know.

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

I don't know.

It's HTTP protocol.

Yeah.

Right.

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

Okay.

Last thing.

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

I saw this on xTwitter, and it's just like a little sign off, like sort of wishing you well or like, take care till next time I see you.

But here's the developer version.

May your bug tracker be forever empty.

Oh, nice.

Yeah, very nice.

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

May the odds be forever in your favor.

You know, that sort of thing.

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

Yep.

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, but, but this is an attempt to explain to people how to actually get productivity gains from test driven development.

But I'll pick it up in January.

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

That's the goal.

That's a, that's an aggressive goal, but, but I have all the stuff I want to do.

So we'll see.

Okay.

Finally, pie, the pie test course.

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

Love the Python Testament by this book.

And I'd like the course.

Can I get a discount?

And I just love people that just ask.

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

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

So last minute Christmas shopping for yourself.

I'll put this in the show notes, But if you use the code Xmas, X-M-A-S 2025, I'll give you 50% off.

Very, very nice.

And I'm looking forward to a more efficient and error-free 2026 Christmas after Rudolph and team use your discount, learn test-driven better.

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

You're doing a service for all the kids.

Yeah.

All right.

All right.

We got a couple of funny things.

We do.

One is mine, one is yours.

So what if you have errors in your code?

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

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

But what do you do when the error happens, Brian?

What do you do when the error happens?

One possibility is to log it.

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

So, you know, there's a few steps.

I guess you could print it.

That's a bit of a help.

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

I don't know.

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

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

It says, if I catch an exception, I'm going to create a string that's HTTP colon slash slash stackoverflow.com slash search question mark Q equals.

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

Wow.

Problem solved.

Old school.

That's old school.

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

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

Exactly.

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

I don't need to review it.

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

Exactly.

Let's see.

Any good comments?

Is this real?

This is hilarious, whether or not.

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

Cutting out the middle, man.

Literally saves a precious three seconds.

3.531, actually.

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

Nice.

Yeah, there you go.

Yeah, perfect.

So it even came up with a prompt for you.

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

Please write code that resolves this issue.

Respond only with code.

Here's the exception.

Oh, yeah.

Pretty good.

Pretty good stuff.

All right.

This one's for you.

You got it.

Okay.

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

Something like LinkedIn something?

Anyway, somebody responded with, oh, LinkedIn Cringe.

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

It's AI blockchain kombucha startup.

Anyway, this comes from Archtoad referring to a post by Tim Kellogg using nano banana prompt, create a super annoying LinkedIn profile, which is amazing.

So the profile is great.

The with a with a like a hero image with somebody giving a speech and the on the screen is disrupt or die, which is great, great screen capture.

But the let's see, let's read his profile.

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

That's awesome.

Helping Fortune 500 CEOs maximize human synergy means nothing.

A TEDx speaker applicant.

Not even TED, just like a TEDx.

Yeah, sure, TEDx, which is like the original.

I applied to speak.

I didn't get it, but I applied.

Forbes 30 Under 30 nominee.

Oh, my gosh.

A dog dad, coffee addict.

Why are you still reading this?

Let's connect.

About Bryden just doesn't just work.

Bryden shifts paradigms.

That's awesome.

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

This is pretty good.

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

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

Yeah.

Pretty amazing.

Pretty amazing.

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

Things are going good.

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

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

So it's been a, you know, the backhanded compliment curses, may you live in interesting times while things are interesting.

Definitely interesting.

I do want to say though, thank you to everyone for listening this year, all the years and here's to 2026.

Yeah.

happy holidays and hope everybody has a good new year.

Yep.

Bye.

Bye.

Thanks, Brian.