Code with Jason
Code with Jason
324 - Renaissance Code 2026 Speaker Dave Thomas: Fundamentals of Software Development
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
In this episode I talk with Dave Thomas about the rapid changes in technology and the importance of returning to software development fundamentals. We discuss the pitfalls of relying solely on AI-generated code and the value of elegance, simplicity, and deep understanding in software design.
Links:
- Renaissance Code
- RubyConf
- Nonsense Monthly
Hey, it's Jason, host of the Code with Jason podcast. You're a developer. You like to listen to podcasts. You're listening to one right now. Maybe you like to read blogs and subscribe to email newsletters and stuff like that. Keep in touch. Um, email newsletters are a really nice way to keep on top of what's going on in the programming world. Um, except they're actually not. I don't know about you, but the last thing that I want to do after a long day of staring at the screen is sit there and stare at the screen some more. That's why I started a different kind of newsletter. It's a snail mail programming newsletter. That's right, I send an actual envelope in the mail containing a paper newsletter that you can hold in your hands. You can read it on your living room couch, at your kitchen table, in your bed, or in someone else's bed. And when they say, What are you doing in my bed? You can say, I'm reading Jason's newsletter. What does it look like? You might wonder what you might find in this snail mail programming newsletter. You can read about all kinds of programming topics like object-oriented programming, testing, DevOps, AI. Most of it's pretty technology agnostic. You can also read about other non-programming topics like philosophy, evolutionary theory, business, marketing, economics, psychology, music, cooking, history, geology, language, culture, robotics, and farming. The name of the newsletter is Nonsense Monthly. Here's what some of my readers are saying about it. Helmut Kobler from Los Angeles says, Thanks much for sending the newsletter. I got it about a week ago and read it on my sofa. It was a totally different experience than reading it on my computer or iPad. It felt more relaxed, more meaningful, something special and out of the ordinary. I'm sure that's what you were going for, so just wanted to let you know that you succeeded. Looking forward to more. Drew Bragg from Philadelphia says, Nonsense Monthly is the only newsletter I deliberately set aside time to read. I read a lot of great newsletters, but there's just something about receiving a piece of mail, physically opening it, and sitting down to read it on paper that is just so awesome. Feels like a lost luxury. Chris Sonnier from Dickinson, Texas says, just finished reading my first nonsense monthly snail mail newsletter and truly enjoyed it. Something about holding a physical piece of paper that just feels good. Thank you for this. Can't wait for the next one. Dear listener, if you would like to get letters in the mail from yours truly every month, you can go sign up at nonsense monthly dot com. That's nonsensemonthly.com. I'll say it one more time nonsense monthly dot com. And now without further ado, here is today's episode.
SPEAKER_00Hey Jason, how's it going?
SPEAKER_01I'm doing great. How about yourself?
SPEAKER_00Um, about the same. Uh just my normal level of confusion, really.
SPEAKER_01Yeah, it's a perplexing time.
SPEAKER_00Yeah, it certainly is. It's um I uh yeah, it's it's funny. I've only just managed to convince myself uh to stop reacting at the kind of day level and go back to something more sane, uh which has actually made my life a lot less stressful. So hopefully I can keep that up.
SPEAKER_01Like reacting on a day-to-day basis to what kind of stuff?
SPEAKER_00Uh it's uh fundamentally I'm trying to keep off the socials, um, but it's uh just reacting to the kind of bright shiny stuff that's going on, the the you know, the latest Claude, the you know, the the the new agent that will cure your world and and you know run your life for you, the latest techniques, uh all of this stuff is changing just so ridiculously rapidly. And 90% of it, to be honest, is just irrelevant. Um so um I've been thinking a lot about what it is that I actually need to focus on, and more and more I am convinced that uh I need to get back to fundamentals and uh just keep that as my kind of guiding star.
SPEAKER_01Um that is so that is so the right idea. And that is something that I've been trying to steer people toward when I've been talking with them. Um, and it's interesting that you and I have have apparently converged on the same idea, and I'm curious what that means to you, you know, when focusing on the fundamentals instead of the new shiny stuff. What what does that mean, the fundamentals?
SPEAKER_00Um well, if just look at it, uh the only area where I can really talk with any kind of authority, I guess, is software development. So let me talk about that uh rather than look at the the massive big picture. Um but I I I have this um theory that in software development we repeat our own mistakes once every seven or so years. And you know, it's just a very, very cyclic world in which we we know keep reinventing the past. And uh if you look back to that past, if you look back to the um the lessons we learned in the sixties and seventies and eighties, um those lessons are still true today. Um the uh uh the the values of the um manifesto for agile software development are still true today. Um what's changed today is that we now have these you know amazing new technologies that uh turn us all into godlike beings, you know. Uh and it's very easy to forget our training and forget our common sense uh because we're empowered just to be able to wish for something and it happens. Um but the actual underlying uh issues of you know how do I know what I'm creating is what I want and how do I steer myself towards something better, those have not changed. And you just need to be able to to use uh these new powers within that kind of framework, within that kind of value system. Um and you need to be able to curb uh this natural idea of hey, let's try and do this, let's add this feature, let's go and do that and that. Uh curbing that is just it requires a lot of discipline. And when you do um things get better, in my opinion.
SPEAKER_01Mm-hmm. Totally agree. Um there are okay, so I can share some of the like bedrock truths that I that I have been thinking about. And there's this quote from Stephen Covey. He said something like, when it's not really a quote, just a passage from a book. He said, when um things are rapidly changing, it's very helpful to have principles that will never change. Um and there in in software development, we have a lot of principles that will never change. And in this time of rapid change, I think it's very helpful to distinguish between what has been invalidated by AI and what hasn't, and in principle can't ever be. Um and I think a lot of people are um they they haven't paused and thought about these things, and so maybe they are allowing themselves to be confused and thinking that the the existence of AI invalidates things that it doesn't invalidate. Um I was talking the other day with my friend Leo, who is a really smart guy and a really good programmer, um, and he was sharing that he was feeling overwhelmed because the agents were creating so much work for him. There were all these, there's all this code that he that he had to review and stuff like that. There's all this automation, but now he's the bottleneck because he has to do all this work now. And I told him that I felt like his workflow was really upside down. Um and and his situation's not unique. I've I've heard that from other places. People feel like they're overwhelmed, they feel like they're the bottleneck now because AI is generating so much code that they now have to review. And I I I feel like there's I haven't quite articulated it yet, but there's something there that's that's a little bit off with regard to understanding the the fundamental principles of of how that kind of stuff works.
SPEAKER_00Yeah, absolutely there is, and I think the the problem there is that Leo is becoming the tail and not the dog and the so one of the one of the um tenets of the waterfall method is that uh you put effort up front to stop yourself wasting effort down the road. So you you get the requirements nailed before you well, not before, but you get the requirements nailed, and then you go and work on architecture and then design. And if any of those things reveal problems, you go back up the ladder and and modify. But in general, you try to do that, and the reason for that has always been that the cost of each stage is higher than the stage before. And the the assumption was always that the cost of the implementation was always the dominant factor, and therefore that's what you were trying to reduce. Um so in that respect, the fundamentals to me is not uh that you design up front, but the fundamental is you try to uh leverage the um ways of reducing the dominant cost. Now, in the AI world, sorry, in the in in the world like four years ago, three years ago, the dominant cost was still the cost of developers writing code. Um, you know, it'd be very easy to say, write me a system that does this, then that costs you like nothing. And then, you know, two months later a system arrives, and that's just cost you $100,000 or whatever it is. So now that's not true anymore. And now the dominant cost is not necessarily the cost of actually creating the code, the dominant cost is is the ceremonies that surround that, and that's not we what we've adjusted to. Um because as you say, Leo is the bottleneck, and so Leo has still become is still the dominant cost, but the activity that's making him that is not the activity of writing code. Um, and then we gotta work out, okay, so how do we deal with that? One of the ways we deal with it, I think, is that um if you just let AI write code and then your job is to look at the PR, um, then what you're doing is you're inviting that AI to produce typical AI code, which is, I don't know, maybe five times larger than the code that a human would write. Um it's not necessarily, you know, wrong, but it's still ridiculously complicated. It's overembellished, it has too many features, um, it tends to have experiments in it that are then ignored but not deleted. Um and all of those things make these these PRs, you know, something that you really don't want to do because they're so tedious. Um and also so soul destroying because you look at this and say, this is really crap code. But at the same time, it works. You know, what am I gonna do? I'm gonna go say to the AR, no, go back and try again. No, I'm not gonna do that because it's gonna get me in trouble, you know. Um, and so we are now becoming these kind of like yes men and yes women to this this you know this beast. Um I think that the the reason I think that the tail is is wagging the dog here is because if we actually invest if we say, okay, so the most m the most expensive part here is the PR, effectively. I mean, I mean there's more to it than that, but let's just take that as being a a base case. Then what are we going to do to reduce the cost of that? And I think what we do to reduce the cost of that is way better supervision of what the AI is doing and the injection of what you already know and the the principles and values that you already have into the AI's work. Um I am forever hitting control C and saying, you know, what are you doing? Why are you doing that? You know. Um the the the classic case is when you're you're coding away, or sorry, you're not coding away, it's coding away, and it comes across this this problem, a test that fails, whatever it might be. And rather than stopping and saying, well, okay, why is this test failing? It immediately tries to apply a band-aid. And that maybe works, maybe doesn't work, and then there'll be another one, and it will just disappear down these black holes of um, you know, almost like panic, as as it adds things and adds things until it finally gets this test to pass. And what it's done is it's generated I don't know how much code with lots of flags and oh, you know, I have to say this condition and this condition, then do this, otherwise do the it hasn't looked at the big picture. All it's looked at is I need to get this test to pass. And so your code has just exploded uh for all the wrong reasons. And that's that kind of desperation is you know, the second you see that starting, you control C and you say, okay, let's go back to the commit and let's work out, you know, what actually is happening here. Maybe what we've got is an architectural issue or a design issue. I mean, it's possibly an implementation bug as well, but you know, it could be something different. I mean, normally, for me at least, when code does unexpected things, that's the code's way of telling you to set back and think, why is it doing that? Right? It's not an imperative to fix the code. It's a nudge to say, yeah, there may be something bigger wrong here. And my experience is if I work more closely during that, during the implementation phase, and during the design phase too, when it's planning, if I work more closely and you know, don't just sit there and say, yes, continue, yes, continue, yes, continue the whole time. Um that I find results in better code and code that I would be more proud of when it comes out.
SPEAKER_01Okay, so I want to share the the this is this is rustling up in my mind some like deep fundamental truths that I've learned recently, and they apply definitely to programming big time and to other areas as well. Um, so I've talked on the podcast a million times about David Deutsch and his two books, although I haven't mentioned him for a while, but his two books are um The Fabric of Reality and The Beginning of Infinity. And the Fabric of Reality, it stitches together like four uh different areas. I don't know if I'll remember them all, but they're biological evolution, um, computation, epistemology, and yeah, I don't remember the fourth one, but it it strings together these things and draws parallels uh between them because they all have that they share certain important things in common, and I think uh software development absolutely has this in common too. So the the thing that they have in common is the idea of conjecture and refutation. So with with epistemology, knowledge creation, the idea, of course, isn't to get the right answer right from the start. We have to make guesses, and then we we start with a relatively large number of guesses, most of which we know are not going to be correct, but we don't know from the start which one is correct. And so the question isn't how do we be right, the question is how do we detect and eliminate errors. Same thing with biological evolution. Uh evolution blindly stumbles through design space, and the vast majority of mutations are not an improvement. But then every great once in a while a mutation is an improvement, and so it's kept. And the the process isn't one of just starting out with with an improvement, the process is the elimination of the things that aren't an improvement, same exact process. That is there's a certain parallel there in software development because when we are working on a system, we can be virtually guaranteed that many, if not most, of the changes we make to the system will turn out in hindsight to have been the wrong thing, but we can't know in advance which ones. Um, and so the question isn't, you know, going back to your waterfall comment, uh, the question isn't how do we be right right from the start. The question is how do we detect and eliminate uh the things that are wrong, and of course, how do we design our system in such a way that when something inevitably turns out to be wrong, and again, we don't know in advance what thing it will be, but we can design our system such that on average those changes are relatively easy to make. But again, it's that idea of uh conjecture and and refutation. I'll pause there.
SPEAKER_00I would take a little bit of issue with that. Um not wishing to uh argue with um great thinkers, but uh it kind of implies to me that there is a correct way that we're trying to stumble towards through experimentation. And that to me feels regressive. Um and it feels to me a bit like the way I AIs are currently um basically narrowing the the solution space constantly through statistics. Um I I it's kind of trite, but there's that um Shaw George Bernard Shaw quote from what is it, Man and Superman, I guess. Um it says something like the reasonable man adapts himself to the world, um the unreasonable man is constantly trying to change the world, therefore all progress depends on unreasonable men. Um and I think there's actually uh there's an element of truth to that in that the things that you talk about with like evolution, the the real change that comes through evolutionary um growth is not that constant refinement. It's the every now and then there is some ridiculous change that you would never want, you'd never think of, and yet suddenly it turns out it works. Um and I think the same thing is true in in just about every aspect, that we are constantly making minor adjustments and fixing things, but the the real the real progress is made when someone says, what if we dot dot dot and we tried something just totally different. And that I think is the weakness of AI and the strength of humans, uh, in that uh one of one of the things I get a lot of pleasure from when I'm coding with AI is when I hit control C and say, what if we think about it this way? And suddenly what was a block just opens up and we can just move forward.
SPEAKER_01Um to be clear, there's a there I want to distinguish between two things. Um, you know, in science, there's the scientific method, and then there are the fruits of science, and then like all the outstanding hypotheses and stuff like that. Um and with evolution, there's the process of evolution, and then there are the actual designs of organisms that exist, and then of course, in software development, there is the process of software development, and then the the fruits, the the actual systems that we create. And AI, I think you would probably agree with this, AI is terrible at the process. Um, it will, it if if you don't give it guardrails, it will just behave chaotically and and use a cowboy coding kind of behavior, and the results will be fairly poor as a result. Um if we have okay, if if we have in science um a lot of not even just science, but like philosophy or any area of knowledge creation, we have a bunch of ideas uh of of indeterminate value or validity or whatever, and how do we know which ones to keep and which ones to discard? And the answer is we subject them to arguments with a hypothesis. The question is, does this hypothesis adequately explain the phenomena that we observe? And if it doesn't, then it's no good. And the equivalent in software to me is does this code satisfy a test? And if it doesn't, if if it's too much code, you know, beyond what's needed to pass the test, then we toss it out because it is um it we we haven't said that we needed it, or if it makes a test fail, then we toss it out. And so that's that's part of um my way of harnessing the AI so that even though by default it behaves badly, we can s subject it through this to this process of um refutation or whatever you want to call it to keep the to keep the outputs bounded so that the fruits are more likely to be good.
SPEAKER_00Yeah, I think you're I think you're on yeah, I think what you're saying is is true. Um I don't think it's the whole picture though. And I'm trying to put my finger okay, so let's go back to science, right? Um there are there are one and a half tests that you apply to a theory, I think, as a scientist. One is does it meet the observable universe in some way? But the second the I think either explicitly or implicitly most scientists apply is is it elegant? Because there is a very strong feeling, I think, in science, that minimal explanations are better than complex ones. Because it's more likely that the underlying nature of whatever's going on um is is minimal, it doesn't involve you know a hundred random constants, uh, but there is some actual reason that this theory is uh true. And um I mean not everything is like that. There are you know like the four-color theorem proof is anything but but minimal, um, although they have actually got a better one recently. Um but in general, this idea of elegance, of minimalism, um, or expressiveness to put it another way, is I think really important. And I think the same thing applies to software. I mean, the entire history of how you design programs has been a fight to tame complexity and to uh find ways of expressing things that are uh not minimal as much, but it's certainly less less complex, more understandable than they were. Um and what we're doing now is we are um we're turning from being theoreticians and verifying using experiments to being um empiricists, and we're basically doing, you know, coding with AI is like a um you know throwing darts at the board and waiting to see which one hits. Uh and I think that's where we want to, you know, we started off talking about fundamentals, and I think that's where we need to reclaim the high ground. I think that's where we need to put our effort as developers, is coming up with these new uh theories, these new ways of doing things that feel more like the old ways when the old ways worked, you know, have that kind of elegance to them, um, rather than just brute forcing everything.
SPEAKER_01Okay, I want to jump on that idea of elegance, because I think that is extremely important. Um, you know, one one obvious uh property of elegance is things that are elegant are easy to easier to understand than things that aren't. And I guess, you know, what is elegance? Um I tell me if you concur with this definition, but to me, something is elegant to uh uh in proportion with how simple the explanation is for something. It it if if two explanations explain something equally well, but one is simpler than the other, then the simpler one is more elegant. Does that seem like the right idea?
SPEAKER_00Yeah, I think so. I think Yeah. Elegance it's it uh yeah, things are elegant if everything has a purpose. Um that is you know that moves it towards whatever it is you're trying to do. You know, whether that's like you know um fashion or whether that's a mathematical theorem, I think i the there's an essence to things. And elegance is a qu is is an expression of the essence of something.
SPEAKER_01Right. And elegance is economical.
SPEAKER_00Where it has to be.
SPEAKER_01Right.
SPEAKER_00Yeah. I mean you can be flamboyantly elegant, I guess. Uh but yeah, I mean, in general, elegance is is minimal.
SPEAKER_01Right. Um and so one of the ways that elegance has value in software systems is again, it's easier to understand, and things that are easier to understand are easier to change, and systems that are easier to change are less expensive to maintain. Um with regard to elegance, there's an analogy that I've been using a lot lately, which is that of planetary motion and epicycles. The ancient Greeks observed the motion of the planets and they tried to model the motions of the of the planets. They didn't try to, they did it using uh perfect circles, perfectly circular orbits, but the perfectly circular orbits didn't accurately model the movements, and so they added these smaller circles on top of the circles called epicycles, and sometimes they had yet smaller circles on top of those smaller circles, because if you add enough circles on circles, you can approximate anything to uh an arbitrary degree of precision. Um, so their model worked, and it gave you know basically the right values, but it wasn't elegant and it also wasn't correct. Their model didn't match what's really happening in reality.
SPEAKER_00And then um who figured out the well, I don't know, Copernicus or who whoever Newton Newton used calculus to prove, well not to prove, but to derive the motion.
SPEAKER_01Okay. Um and and you know, then we landed on the right model, which is elliptical orbits. Oh yeah, obviously the uh I left out the the the big significant thing, the geocentric model of the solar system versus a heliocentric model of the solar system. Once you switch to a heliocentric model, everything just snaps into place. And it's so much simpler, gives the same answers. Um And it was wrong. Sorry?
SPEAKER_00And it was wrong.
SPEAKER_01Right. The geocentric model was wrong.
SPEAKER_00No, no, no. The the heliocentric, the the the Newtonian model was again only an approximation. It wasn't correct.
SPEAKER_01Oh, right, right, right, right. Okay, let's let's get to that in a second.
SPEAKER_00Um but just I would also say you you dissing dissing the Greeks is uh actually I've never thought this before, and it's probably absolute bullshit, but you could argue that what the Greeks actually did was invented Fourier analysis 1500 years early. And if other people had decided if the Greeks had refined that to a point where um it was uh arbitrarily accurate and they'd come up with the math behind it, think what that would have done to the progress of science and mathematics. Think how much analysis relies on being able to uh manipulate Fourier transforms rather than the actual functions themselves. So one argument would be that the Greeks, we actually missed a major opportunity. Um there are um I may be wrong, but I believe there is no formula for the perimeter of an ellipse. Where would be if you had, or you could have a limiting value if you had Fourier analysis defining that ellipse. So I I think that's actually a really good example of where a local optimization and where elegance actually didn't necessarily do us a favor. And that comes back to that idea of the unreasonable man, the idea that um quite often real progress is made by looking at things wrongly and by doing things that are not obviously optimal.
SPEAKER_01Exactly. Yeah, I think it was David Deutsch who said we go from misconception to misconception, and they're just higher quality misconceptions. Um, and I do want to say for the record that I'm not dissing the Greeks. Their model, flawed as it was, survived for 2,000 years before sorry, 1500 years uh before we we improved upon it. And it's only been 500 years since then, so they uh theirs survived for longer than than ours even has so far. And you know, give me a telescope and say, hey Jason, explain what's going on out here. Uh I'm sure I wouldn't have come up with any model whatsoever. So I think they were pretty smart for coming up with that that model that gave the right answers.
SPEAKER_00Yeah, and also without telescopes.
SPEAKER_01Yeah, yeah. Um, okay, so coming back to programming, um I think a model is an explanation. You know, a model of the solar system is an explanation for how the solar system works. It's just kind of a you know geometric physical pictorial explanation or or whatever rather than an explanation that's just in words, but it's still an explanation. It's an explanation and it's a search for the truth. And so with modeling and software, I look at it as something very similar. Um, a software model is an explanation and it's a search for the truth, but not exactly the truth, because you can contrive arbitrary models in programming, like in Saturn CI, my CI platform, uh the central concept is that of a job run. I could have picked something else, I could have called it a build or a run or a job, but I call it a job run. There's no single objectively correct answer in all cases, but you can have like a um, you know, you you have like an interlocking system of models, and it is objectively the case that all of your models are consistent conceptually with all of your other models, or they aren't. And I've had many cases, and I'm sure you have too, Dave, where I have the equivalent of an epicycle model, an equivalent of a geocentric model, and then there's some small shift that takes place in my mind. You know, I I I rename a model from something to something slightly different, and then a hundred things snap into place, and it's like, oh wow, this is the right answer.
SPEAKER_00Yeah, it's like a crystallization.
SPEAKER_01Mm-hmm.
SPEAKER_00Um yeah, I I I think um one of the techniques I use to to do that is first of all, I think it's really important to have the kind of spidey sense that says this is wrong, or this can't be right, I guess is more accurate. Um things that feel too complex or that are breaking in unexpected ways or that are failing to deal with things they should have dealt with, those kind of indicators that something is wrong is a really important sense. And sometimes you can fix that by just brute forcing it. You can sit there and say, something is wrong, I'm gonna find out what it is, and you try and do some analysis to do that. And that is the the reasonable approach, and that's what um I think m most of the industry is doing now. But one of the techniques I've discovered that that works really well for me at least, is um throwing randomness into it, doing something really stupid, and then seeing how the parts fall. And quite often that kind of disruption gives me a better insight into how things are interacting and how things kind of um want to interact. Um and in a way it's a little bit like um annealing, right? Where you introduce randomness and then let things cool down and see how they settle because they'll tend to settle more compactly than they were initially, right? Initially they were all randomly oriented, then you can you can heat them up and then cool them down, and they're more likely to have settled into a kind of lower energy state. And I think it's the same with code. And so again, I come back to this idea that um one of the ways that people can uh participate better is by lobbing these little hand grenades of randomness into the process and seeing what happens.
SPEAKER_01Yeah. Um Another way I look at that, okay. Half-baked thought in my mind, it's like looking at something from a different angle. There are so many things that we can only observe indirectly. Yeah, I don't know. So I'll abandon it. Um sadly, I have a hard stop at the hour, but I want to make sure that before we go, we um we make sure to touch on this event that is coming up in just a few months here. Um Renaissance Code uh taking place in Potosky, Michigan. And you, my friend, will be there with us speaking.
SPEAKER_00Speaking? I thought I was just participating. I will definitely speak. I can speak if you want me to. I didn't realize there were talks even. But yes, I will I will I'm I'm looking forward to that. I mean, basically, it's gonna be my understanding is it's gonna be a small group of people who really want to be there. And uh that's always gonna be an interesting experience.
SPEAKER_01That's exactly what it is. Um, and it's in an unusual place, like dear listener, you probably have never heard of Potaski, Michigan. Um it's it's not, you know, it's not in a big city because I don't want big city surroundings honking horns and air pollution and buildings and all that stuff. It's in a small, quiet town on Lake Michigan, and a lot of people know this, but a lot of people um are unaware that Lake Michigan is so big that you can't see the other side. It it's it's just like being at the ocean. You look out, and the horizon is just water, so that's that's what it's situated on. Um, so just a very quiet nature setting, and we'll all be staying in this very small hotel. I I did a room block for like I forget 20, 25 people, whatever, and it was almost the entire hotel. So like we will be taking over this entire hotel ourselves, pretty much, and it's just yeah, Dave, it's just you and me speaking. Um, so most of the time we'll be free so we can have these long ranging, wide-ranging conversations like the one you and I are are having today.
SPEAKER_00Which I'm really looking forward to. It's um back in back in the day, um uh I can't remember who it was. Um we used to meet uh a couple of times anyway, we met in a fishing lodge in Oregon. Um and there were like ten of us. And it was the same kind of idea. We would just sit and talk, and in the evening we'd watch a movie. Um I was introduced to the Princess Bride there uh as the official movie of the Agile Movement. Um and uh similarly, uh the other Dave Thomas um has a retreat. He I don't know if he still runs it. Um he has like a a winter home on Anguilla, which is a little island out in the Caribbean, and people will meet up there like once a year and just share ideas. And this is very much in that that vein. And uh it's always stimulating. And you come away having literally it's not just you, it's not just like a friend in that you exchange business cards, it's uh it's someone actually you have spent time talking to and understand and arguing with, and that's always a nice way to meet people.
SPEAKER_01Yeah, and I fully expect that pretty much everybody who comes to this conference will come away with a new, I don't want to necessarily say like a new lifelong friend, that's a big guarantee, but I think there's a good chance that a lot of lasting friendships will be made. This this is the kind of thing where that kind of thing happens.
SPEAKER_00Yep, and you'll find kindred spirit.
SPEAKER_01Oh, yeah. Yeah. Um, okay, so dear listener, if you're interested in joining Dave and I and a small handful of other interesting people such as yourself, um, you can go to RenaissanceCode.com. Um, you might need to look up the spelling as I did for Renaissance. Um, but renaissancecode.com and tickets are on sale now, and the conference is in October uh in um in northern Michigan. Um final thing before we go, Dave, any links or anything like that you want to share with people?
SPEAKER_00Um not directly. Um on the AI front, if you're not currently using superpowers, then uh I would recommend you check out superpowers because it's uh uh it's a good way of throwing the focus back on you, in that it's very much to do with interviewing you. Um an obvious shout out that both you and I will be at uh RubyConf in uh uh what's it called Round Rock, Red Rock, I can't remember. Uh up north of Las Vegas uh in a couple of weeks.
SPEAKER_01Yeah, yeah. That'll be great too. And dear listener, if you're gonna be at RubyConf, uh I would love to meet you in person and hang out. Um and if you're if you don't have a ticket, you should get a ticket. Uh so we can we can hang out. It's a wonderful, wonderful spot out in the desert. I've been there many times.
SPEAKER_00Right. And it's just um it's a throwback, my understanding anyway, is it's a throwback more to the original spirit of the Ruby Conf. So I'm looking forward to that.
SPEAKER_01Yeah, that's uh oh uh dear listener, you may not be aware, I'm co-chairing RubyConf, and part of my desire for this one is to make it fun. Um and and uh inject that uh spirit into the event and uh levity and friendship and all those those things. So I hope to see you there. And Dave, thanks so much for coming on the show.
SPEAKER_00Always a pleasure, Jason.