Two's Complement - The Benefits of Experience

Episode Date: July 18, 2025

Matt and Ben explore how experience lets you run across water instead of drowning in options. Ben explains why he doesn't need a life preserver when building software. Matt retrofits good practices into Compiler Explorer while lamenting decisions from 10 years ago.

I'm Matt Godbolt. And I'm Ben Reedy. And this is Tooth Compliment, a programming podcast. Hey Ben. Hey Matt. We are reaching new levels of complacency when it comes to recording an episode here because we haven't gotten a clue at all about what we're doing today. No. But that's never really stopped us before.

No. And it's not stopping us today. So I'm gonna ask how you doing, my friend. It's been a little while. Yeah, yeah, it's been it's been a busy few few weeks. It's been a busy few years. Last week was a busy year. The just just lots of new things happening new stuff stuff happening, new things being built. Hopefully exciting and interesting new things. Yeah.

Yeah. You know, I have the privileged position of working in new projects, which most programmers will tell you is a much better alternative than many other things. Right. And as the listeners of this podcast are well aware, I have many strong opinions on the right way to do things. And being, working in a new project allows me to work in the manner to which I am accustomed, which means I am being very productive, right? Like I'm able to get a lot of things done because I don't have to re-litigate all of the development practices and tools and things. It's just like, nope, we're just gonna do the stuff and we're gonna do it

right. And we know how it all works. And it's all pretty straightforward and simple. And the whole point here is just to do it as fast as you responsibly can. And so that is fun and rewarding, but it's also a bit tiring. Right. Right. But as you say, having the ability to set a project up the way that you would like it to be is powerful. And pretend as you say, potentially gets you to go very fast, lets you go fast. You are not limited by I mean, I guess other people, other people and their choices that maybe you disagree with or what do you think is it? Is it? Is it? I mean, obviously, I don't think you are so

big headed to say that your way is perfect. And everyone should do your way. Although, you know, I agree with most of the things that you say. So maybe it is. But yeah, what is the is it monoculture? Is that the problem? people talk about, it's like, should we continue evaluating options, or should we move forward with the best option of the set of options that we've considered so far? Right? And I think one of the advantages of experience is that you have made a lot of mistakes, and you have evaluated a lot of options,

and you have determined which ones tend to pan out and which ones don't. And therefore, you wind up with some things. There's sort of like the old bit of like, if an old engineer tells you that something can't be done, you can look at them with a little bit of skepticism, right? They probably know some things. But if you look at them with a little bit of skepticism, right? They probably know some things, but if you look at them with a little bit of skepticism and kind of ask the question like, are you sure? But if an old engineer tells you something can be done because they've done it before, well, that's a very different claim, right? That's a really interesting difference, actually. Yeah, this Yeah, I, I see that.

Yeah. Yeah. But yeah, so you're sort of sort of drawing from experience and saying that these things have worked for me, I have explored the space because I've been doing this for 30 years. And I have a pretty good idea. Doesn't mean to say that it's a perfect idea, or there aren't better ideas, whether but these ones have been shown to work. And now I'm choosing in the sort of 8020 theory of, uh, explore 20% of the time and 80% of the time take advantage of the things that

have proven to be well, you're in that 80% section at the moment. Yeah. Yeah. The restaurant, uh, ordering dilemma is how I think of this, right? I go to my favorite restaurant and I look down the menu and there's that thing I like and I'm like, yeah, and there's that thing I like. And I'm like, I really like this thing on the menu, and I will enjoy it every time I come here. Yeah, but there are some other things on this menu, too. Should

I take the risk that it's not as good as the thing I know I like? Yeah, yeah, yeah. I think another interesting dimension to this problem is that, you know, I'm being paid to do this, and I'm being paid to deliver results. And what I'm not being paid to do necessarily is learn a bunch of cool stuff. It's fun to learn a bunch of cool stuff, and it is sometimes very productive and useful to your employers to learn a bunch of cool stuff. Indirectly through you and through your proselytization and sharing of experiences and setting the cut. Yeah, right. But ultimately, it's an investment in your yourself, independent of

your employer. And sometimes that can be purely for yourself. Like, you know, right, we've all we've all seen this. I think we've talked about it before. It's like, hey, some cool new programming languages come out and some programmer goes off in a corner and says, I'm just going to write this new little tool that we needed. And we're going to write it in Haskell because I've just read a book on Haskell. Right. And you're like, that's, I don't know that this is in the best interest of the business. Right. There's a, I guess, you know, you roll your d 20. And if it's a 20, somehow now Haskell is the best thing in the world. And everyone moves to Haskell and the whole company levels up, right? That's a possibility. But very often what happens is that that piece of code gets orphaned and becomes the haunted graveyard of we don't use

that tool anymore. But your friend has been and learned Haskell and has gone off to do something else. Right. They got that job in Haskell that they wanted to get. But you know, you Yeah, you have to have an understanding employer to let you do those kinds of things. Or, you know, or be in between jobs. You get the choice. Like you're every day right now, isn't it? At the moment, I get to choose pretty much what I want to do. Yeah. And yeah, that that's a whole different story. That's perhaps one for later. But yeah, but yeah, so where were we? We were talking, you were you were saying, yeah, you Oh, yeah. No, I mean, I just sort of like, I really like the

model of a sort of exploration versus exploitation and being, you know, or exploration versus execution. I don't know what the better way is. Yeah, I described that describe that. But it's either like, are we evaluating different ways to do things or are we doing things? And I think being responsible with that gives you the freedom that comes with authority. I'm going to be responsible for making this decision and doing it in the best interest of the company. And because of'm, I'm going to be responsible for making this decision and doing it in the best interest of the company. And because of that, I'm going to expect people to trust me to make the right decisions. And then that means when I decide like, yep, we're doing this in Java and with tests, and we're going to do continuous deployment, and we're going to do all these things, like,

so long as the result of that is that I deliver working software that benefits the people who are paying me, then no one's going to ask any questions. They're going to be like, great, thanks for doing that. If it's like, why is this taking so long or why do you continue to have problems? My answer is, well, our continuous deployment system has some bugs and I haven't quite worked out all the ways in which this integrates with Google Cloud yet. They're going to be like, okay, but why? Why are we doing this?

Why didn't we just do this in Python like everything else is or whatever the equivalent is? Right. Right. So this is absolutely the kind of thing where you have chosen to sort of stake and spend some of your reputation points, your goodwill budget with the rest of the organization. So I believe this strongly is the right way to do something. And you've got your evidence to back it up. I'm doing that anyway, though, it just by embarking on this, this responsibility to build this thing, I am staking my reputation. And the only question is, what outcome am I

going to get? Right? So like, you know, if I say equally, if I say, you know, there's not really a nobody got fired for buying IBM effect, right? It's like ultimately, in some ways it's worse. It's sort of like, okay, well, if you're gonna do, if you're not gonna have any strong opinions about how to do things, and you're just gonna do things the way that, you know,

the more senior people around you maybe say to do, or sort of like the, you know,, or the default path of the company. People are going to also still correctly expect you to get things done. If you aren't effective at getting things done that way, it doesn't really matter. The thing that really matters is actual running working software in production. how you get there can be a matter of opinion and can be a matter of even experience, but the proof is in the pudding. So like just doing it the standard way does not absolve you of the responsibility of doing

it. Right. Right. But it does meaningfully change the way that it's perceived, I think, like if you were just to do it the obvious quote, obvious way that everything else is being done, then as you say, it's like the IBM no one that got fired for it, right, you could, there's a defense in not delivering that

it was just like, okay, this was just a difficult thing to do. And I, there's not like an approach that I pulled out of left field that might be scapegoated, perhaps as to why it wasn't the software wasn't achieved, right? I could imagine, for example, you know, like the Haskell thing is like, you know, if you succeed, and you did it in Haskell, maybe you get the free pass, and then everything's better. But if you if you screw up, because it wasn't possible to achieve it, people will latch on to the fact that you wrote it all in Haskell rather than you did it the same way that everyone else is doing is that? Am I too pessimistic? I suppose I am seeing here and

I'll be honest with you some parallels with decisions that I made a few years back in the way that I chose to develop some software. And they that did come back to sort of sort of haunt me in terms of like, I staked quite a lot on something and that was ultimately not the right way to go forward. And I agree with that. But it did. I did have to bear those consequences as you do when you take responsibility. That's that's just what happens. Right. So I suppose I'm a little bit like, oh, If things don't work out for the best, there's, you're definitely going to be able to find a reason why, right? And that, and that reason why can easily be because you decided to do things your own way and not the standard way. I'm not saying that's not possible.

Of course. Yeah. But the, I feel, you know, I've used the metaphor many times of running across a lake and, uh, you know, software software. The Jesus lizard. Yeah. Have you seen this lizard? I don't know that I've seen that particular lizard, but I know that there are. Jesus lizard. It's amazing. It runs across water. And I just, I love that someone was so blasphemously naming things that they were like, this is, this is, I mean, it's like, as soon as

I said it, you knew what it was. Yeah, right. That paints a picture. I'll tell you. But anyway, yeah. So you're a software engineer, you're running fast and you're not falling into the lake because you're just keeping going. Right. And there's, I think, I think there's a lot of value in kind of, and this was a lesson

that I learned relatively like halfway through my career. We have an episode about bad business models and starting a company, right? Yes. And I may be told this story in that podcast, but forgive me, listener, if you've heard this before. But I remember having a conversation. We had formed a small company within the consulting organization I was working at. And we had formed a small company within the consulting organization I was working at. And I, we had all these plans for taking this open source project that we have and closing it and then selling

it. And I had come to like the first or maybe the second board meeting with a long list of things to do, if it doesn't all work out. And it's like, okay, well, we can reopen the software, and then we can do this, and we can, you know, release this thing, we do this. And the person that that was the CEO of the consulting firm and was on the board of this little internal company was like, Ben, stop. Whoa, if you figure out all the ways in which this is going to fail, you're never going to have time to succeed.

You have to focus on how you're going to make this work. And so the kind of analogy that I have in software development is like, like planning for like, as engineers, we think about failure all the time, we think about failure modes all the time. But I don't think that that type of mentality works as well. When you sort of go up a level, and you're like, Okay, how am I going to organize this effort, right? You have to think about like, how are we going to succeed? And so like, you know, the analogy of running across a lake is the way you run across a lake, a lake is you go real fast. That's how you don't stop for anyone. You don't stop

for doing so you don't want the life preserver and the signal flare and the tool belt, like All you really need is shoes, maybe. Just go real fast. And so I grant you that in those situations where you fall in the lake and things have not gone well. Will Barron Everyone says, well, you should have had the life preserver. Why the hell did you not have your tool belt with you? Jason Bahl Exactly. It's like this didn't work because you used Haskell. It's like, Yes. A life preserver. You should have been where, why the hell did you not have your tool belt with you? Exactly. Yeah, yeah, yeah. Exactly.

It's like this didn't work because you used Haskell. It's like, no, this didn't work because we didn't go fast enough because apparently I didn't understand this as well as I thought I did. Right. Right. Um, so I don't know. I, and that's, I, I grant that that is a very, that in itself is kind of like an opinionated view on how to do these things, right?

Like, there are lots of situations in which even I would not apply those principles, but those are sort of my default principles. Right? So, you know, I, I don't know, I, I can, I can see a world in which I don't want to call playing it safe because I really don't think that it's playing it safe, but sort of like playing it safe because I really don't think that it's playing it safe. But playing it safe and just doing what everyone else is doing around you is not a wrong strategy. But I think at the end of the day, so long as you build things that people want and you build them at a reasonable pace. And I think a lot of this also is just not putting

yourself in a situation where you're just slowing yourself down, right? Like creating a lot of mess and cruft and cruft, actually, literally cruft. That that is borrowing from your future productivity in the name of doing something today. I think a lot of it is also, also that and knowing when you need to fight for that. So I don't know, I'm kind of off on a tangent here.

No, that's good. I mean, I certainly craft is top of mind for me as I've been spending the last few weeks, you know, doing compiler explorer things and spending a lot of time regretting decisions that were made 10 years ago that were made, you know, and some of those decisions are it was it seemed like the best idea at the time and they're fine. It's just, you know, they need to be updated. That's cool. But many, many of them are like, I didn't really, it wasn't thought through. And, you know, you, you regret them. But then some of the other things are like, well, if this had never scaled to four terabytes of compilers, then we wouldn't have this, but this is a new problem, right? No one would have thought this, you know, who I mean, when I speak to people about some of the issues we face, oftentimes, they're like, oh, gosh, I'd never even considered that would be a problem. You're like, yeah, no, not that. And now it's a big focal point for us is like, how do you deploy this? Oh, well, you just copy the bits around. Well, there's four terabytes of it and nothing in Amazon works like that. Oh, yeah. Yeah.

Yeah. I don't know that I would argue that those decisions that you made 10 years ago were wrong. I think I think the cruft comes in when you are you don't feel safe changing them. Right? Like, and that that is also true. You know, a lot of this is specifically for compiler explorer, you know, we're a shoestring budget thing. We don't have a copy. We don't have a second deploy that I can play around with, with the sort of big infrastructural changes, right? Especially stuff like, you know, let's just copy all the compiler somewhere else and then poke around with them. I don't even if I did have, I mean, we have some staging stuff, but if even if I did have like a full copy, I could run somewhere else. My

confidence in being able to say this categorically still works. Now I've, you know, moved everything around, I've changed the file systems, I've done whatever I choose to do. My confidence is not very high. You know, I can curl a few things, right? Look at Yeah, it's not straightforward, you know, to an extent, my own personal usage pattern of the site does not comprehensively enough, cover all the things it can do. And because we don't have the tests for most of the user interface,

or even many of the compiler type things that we do, I'm not confident in making changes, we just kind of have to wing it and hope which is not good, right? You know, I'm talking to Ben Rady. And it doesn't feel good. You know, and so some of the things that I'm doing right now, you know, this, this is going off in a tangent to your tangent now. But like the things that I'm trying to do now, I'll set myself up for further success by going back and adding types to a lot of the things that were untyped

and have horrible costs in the typescript. You know, we moved from JavaScript to TypeScript and there's a ton of stuff along the way that just has, you know, as any or as unknown because we didn't know what type things were. And now I'm actually spending the time to go back and put the types in and uncovering all sorts of weird cases where it's like, Hey, sometimes we return that object. Sometimes we return false. That doesn't seem like anyone would choose to do that, but that's what happened. And then you go and, you know, you pull on the threads. And so I feel like that helps to make it easier to make changes. And while I'm doing it, I'm adding tests and even adding test frameworks. I made a big change recently

to move a whole bunch of stuff out of the front end into a place where I can run the test for it, independent of a browser being involved, because most of the code is like, doesn't care about the DOM. Uh, so, you know, you want to test whether this string is a valid descriptor or an identifier, well, then that can be tested outside of stuff like that. All of these things, hopefully, on mass will make it faster for us to go forward in the future. Oh, yeah. Yeah, so that is a very tangent to your tangent. But yeah,

that's top of mind for me is how do I make myself more productive? How do I get myself into the world where the the environment gives me the protections I want? And I think to circle all the way back to the beginning, the thing that you said at the beginning of this was like you're in a greenfield environment where you set it up the way that you think it should be done. And I think you and I both like that, you know, I have a C++ template project, which is like this is all my rules, or my Lint rules are set up, or my pre commit hooks are done this way. You can't, if you make a change to my project and you get it past CI and you get it past the PR, then it should be a good change, right? There should be no way that you can get it passed. And if it's not, that's on me. That's a

bug in the infrastructure that let you put a bad code into my project. Compilers for is not there yet, but it will be, Right. I hope. Yeah. It's sort of getting there. Yeah. Yeah, no, those cars have brakes so you can drive faster. Those kinds of things that reduce fear, reduce risk and let you, you know, take a run across the lake cause you know you're a good swimmer,

will absolutely speed you up, right? And I feel like the unfortunate truth is that a lot of those things kind of have to be built in from the beginning. I actually remembered the thing that I was thinking about earlier with the topic that I wanted to talk about. I was able to talk, log it up for your brain. Actually, no, you actually reminded me of it with all the automation stuff. So just this week, working with a new intern on my team, we figured out how to completely automate in user mode, or in user space, Docker building and running. So for the longest time, one of the big bugaboos for me has been if I want to build a Docker container, I can't use my make download the tools that I want

and stick them into the tools folder approach, because you have to have some pseudo install. You know, I do some. Yeah. All of these terrible, terrible, terrible things. You've been able to use some other. Using a combination of the standard Docker client, which is cool and actually pretty easy to install that way,

a library called KoLima or Ko-Lime, I'm not sure how it's pronounced. And another thing that it depends on called Lima or Lima, which also can be installed this way. I was able to build a Docker container and run it and have all of the tools entirely installed just in the home directory of the user with no special permissions.

So some, yeah, just magical. I could get clone your repo and type make. And as long as I'm on a supported operating system. A supported operating system, yes. You know, it will get the tools that it needs to do this and build this stuff without some Deus ex machina kind of like process that you're like, ah, first you must pseudo apt install all this stuff.

The stuff that you and I dislike. You have to download this DMG file and double click on it and do all these other terrible things. That's awesome. Yes, yes. And that kind of automation, I think, to an outside person would seem like why are you spending all this time to do this? Because I

think it took us about a day to do it. Why are you spending all this time to do it? And it is so that and this is especially true of these this particular type of project we're working on because it sort of gets worked on and fits and starts right like you Like you work on it for a while and then you come back to it and then you just think. So it's like, it is so that six months from now when something is broken and I need to fix it right now, the way that I set up that development environment is I get clone, make, done, figure out what's going on, push it. And not like, get clone, oh, right, none of this works. And it will take me six hours to make it work,

because these versions are no longer up to date and this package doesn't exist anymore. And I can't find the download link for that. And these docs are wrong. And that is like a classic example of the kind of thing where I feel like you get very opinionated about it. You have strong, well-reasoned arguments for why you do it.

And so long as you can successfully achieve the outcomes that you think you're supposed to be able to achieve while using these approaches, no one's going to care because it just works. If it doesn't work, then all the blame comes out and then all the second guessing and the Monday morning quarterbacking comes out and says like, Okay, why did you do it like this? Yeah, yeah. But but also to your point, you know, like the whole, you know, we, you and I have, have talked about this before.

We both love this idea of like a sort of more hermetic build or whatever you need environment. And I think that, you know, there are stuff more modern things along, have come along since then, you know, dev containers and some stuff that uses Docker trickery to actually like make that. I don't, you know, I have opinions about that. But the reason that I went for this from my previous point of view was that some people at Google had set up their development environment like this. And I saw that it was possible. So that yeah, I've tailed

back into your original thing. This is like a senior developer telling you, oh, yeah, you can do this, it is possible to make it so that you can just have a directory. There's nothing magic about compilers. They aren't system software, they they like to masquerade and pretend they are. But if you need GCC one dot two dot three, to run your code, you can download and install it or you can build it so that it can be downloaded installed, or you can do all this stuff, you can spend a bunch of time, you now learn how to do that. And now you can

take that on to the next thing. And then, you know, you know, the frustration specifically, in this case was like, the very first company you and I both worked out together, where we were stuck for a very long time on the version of GCC that came with the operating system that our production machines had, which was also, you know, an ancient version of red hat, you're like, why are we using a 10 year old GCC 10 years ago? Yeah,

oh, because of this. Oh, it's hard to do it like, no, no, let's we can make it we can solve this problem. Yeah, we can build our own compilers, we can make them work. And then we can make it so that that is an easy thing to do. And it's part of was it Fig, I think was the name of the funny little thing that we started installing stuff in. And I was a package management system, whatever. Anyway, that's, and it was a lot of effort and a lot of work, but we got it working. And it was so

beneficial, because then we could upgrade our compiler upgrade everything. And it's just, it just worked. And like, anyway, that was that we didn't do it because of that. I just as a side effect. Yeah, I you know, the funny thing about these practices is I feel like they spread like viruses, but that is they only spread through contact. It's like, it's like, because there's a lot of things,

there's a lot of things that I've seen like this where it's like, I have explained these things till I'm blue in the face. And I made the arguments that I'm making on this podcast right now about why they're beneficial and why you should do them. And I get a lot of people with like blank stares and it's like, okay, sure. Fine. Whatever.

And nodding heads and whatever. And they just walk away and they ignore it. But the second that I work with somebody for like, you know, it's not a second, but when I work with somebody for like a recent reasonable period of time and they actually see how this stuff works, it would becomes impossible for me to convince them not to do it. Right? Right? Like they see the value of it firsthand, and they sort of experience it like this really and it just like now, they can't imagine doing it any other way. Why would you do it? Yeah, just like yeah, you have to get over the hump that is there's some kind

of function where the you're got to get over the hump or quantum tunnel through the hump. You either go up the hill, you spend 30 years climbing the hill and then falling down into a better place, the other side of the hill. You go, hey, this is better than it was the other side of the hill. Or through contact with someone, you allow them to quantum tunnel through experience hill and come to the better place without actually having to make all the mistakes. Right. Right. Yes. Wow. That's a great analogy. I love that. There's an image quantum tunneling through the hell experience. Yeah. That's what that's what mentorship is, is letting other people quantum tunnel to a

better place without having to go through as much of the pain that you did. Right. Let me show you the secret passage through the mountain. Yeah. Yeah. No. Yeah. I don't know. That was that was a surprising amount of talking for no idea. Yeah, I guess I did eventually remember the thing that I was talking about before, and maybe that would have led us to this topic anyway. I suppose so. Yeah, but no, I think your starting point of having a good project and a nice setup

and whatever is certainly top of mind for me now as I'm sort of retrofitting it into Compiler Explorer at some level. I mean, we've always had some level of this, but it's improving it and shoring it up. Yeah. Um, and then, you know, you and I have been discussing, uh, this seems like a complete left tack and late on in the podcast, but it's worth mentioning. And I think is that like, um, the things that make it easy to dip in and dip out of projects like this, or.

Be it because it's easy to set up, be it because there's clear documentation, there's no surprises, be it because the lint rules make it obvious when you're doing something the way that you're not supposed to be doing it or whatever. So you kind of put people on the, on the good path. Be it like decent documentation that says, this is how we do stuff here. All of this is useful for an intern coming onto a project coming off. And that intern could be an LLM in today's climate. And that seems to work fairly well too. there. And it's certainly a decent subset, like a good 80% of the things that are useful to make life easier for this amnesiac junior programmer to come in and try and make a small change on AD, you know, on ADD meds to come in and make a change to my project. But that also helps the actual intern that's going to come on and hopefully mature into into a full featured junior developer and then a senior developer and go on to do great things.

Right. But that's it's an on-ramp for everybody. So that's sort of like top of mind. And yeah, I don't think we have time to talk about the full ins and outs of that. But it was an interesting thought that this nice setup is also conducive to that. Oh, it totally is. And you know, there's this like industrial design and like tool design thing of like trying to design for the edges. Right. Like, and like a lot of things that people started to discover when they started building both like devices and also like buildings and sidewalks and things like that for disabled people is that it actually winds up helping

Everyone a lot more than they wouldn't have expected Yeah Because when you kind of design for those extremes of like well What happens when somebody's like 75 pounds and can't lift this or what happens when somebody is, you know? Seven feet tall or what happens when somebody's in a wheelchair? What happens when somebody can't see you wind up creating these things that are just easier for everyone, right? And I think that there's a lot of that when it comes to both designing for, you know, junior developers and LLMs and me six months from now after I've slept a bunch of times

and don't remember how this all works. All of those people kind of have the same problem, right? Which is they don't understand what's going on and they need some guardrails to make sure that they don't make any stupid mistakes. So like designing for this stuff has tons of value and I think just like with some of the ADA accessible things, it's like you don't really discover that.

And maybe this is why I'm tying it back to the whole like it spreads like a virus and I can't seem to convince people. Maybe this is the problem is like until you walk down the sidewalk that is like gently sloping up to the thing, instead of like the stairs where you're huffing and puffing. You're like, Yeah, this is better. Like I didn't think about it. But it really is better. Right? Yeah, that is it. Yeah. No, I think so. Well, that seems like a decent place to

park. Yeah, conversation because otherwise, I think we're gonna start for seems like a decent place to park conversation because otherwise I think we're going to start off with a whole other thing. We're going to do a whole other second podcast in time. Yeah, which we don't have time for today. That's true. But yeah, I mean, I think that's a great analogy. Yeah, the whole idea of helping one set of people helps everybody in the context, both in the real world and, you know, like screen And I think that's a great point. And I think that's a great point. And I think that's a great point. And I think that's a great point. And I think that's a great point. And I think that's a great point.

And I think that's a great point. And I think that's a great point. And I think that's a great point. And I think that's a great point. And I think that's a great point. And I think that's a great point. And I think that's a great point. And I think that's a great point.

And I think that's a great point. And I think that's a great point. And I think that's a great point. And I think that's a great point. And I think that's a great point. And I think that's a great point. And I think that's a great point. And I think that's a great point.

And I think that's a great point. And I think that's a great point. And I think that's a great point. And I think that's a great point. And I think that's a great point. And I think that's a great point. And I think that's a great point. probably leave it there for this week. Wonderful as always. I suppose. Yeah, true. You know, you and I talk about this, but we, yeah, the timing these things come out on is different from the time we record them, which confuses both you and me and now the listeners as well. So, right. Nevermind.

But yeah, have yourself a great summer if I don't, if we don't talk before then, as I think that will be the case. And until next time www.hackyderm.io