 Our next speaker gave one of the most visually horrifying talks I've ever seen. Do you know which one I'm thinking of? Well, I'm glad you're about to share in that legacy. At Codemash, a silly conference at a water park in northern Ohio, the only one and only time I've ever been or will likely go to northern Ohio, Chad gave a talk that was color schemed in the style of McDonald's. And everything was neon yellow and red. And there was just, it was a visual assault. And so I asked Chad if he could bring that. Does my 35 minutes start now? Bad news for you is it started already. So a personal, you don't have to really start it. One, somebody who has given me some indispensable advice over the years provided me with some of the opportunities that changed my career and allowed me to change other people's careers. So I hope you get to soak in some of the knowledge and expertise that he shares with us. So thanks, Chad. Now I'll start it. Thank you. You started my timer for me, too. I would like to formally reject Jeff's clapping thing, because I don't clap for me. But I just wanted to really clap for all the talks today. It was really great. Last year, so I was part of a company that was venture backed last year. And then we were sold to Microsoft. And Sequoia was one of our investors. So I follow various Sequoia partners on Twitter. And last year, I saw this tweet from one of the partners who said microservices is the next big step. Sequoia is a big deal, by the way. They're like investors in Google and Apple, stuff like that. And it was a link to this Wall Street. Oh, I've got to be able to click the slides, don't I? This Wall Street Journal article about microservices being this huge business thing. And I thought, OK, this thing is over now, right? He doesn't know what that means at all. But if you read the infographic, I'm sorry, this is recorded, isn't it? If you read the infographic that he links to, it's just like this isn't microservices. So I thought, OK, that's over. This year in Berlin, though, I'm caching on the next big wave, small methods. So you're like, mark my words. In a couple of years, it's going to be on the Wall Street Journal, small methods. We're going to have small method comp. And this is to say, we should stop saying this word microservices. Do you have heard this word before? Yeah, OK. It's actually not even pronounced like this. It's pronounced microservice. This is that lazy thing where you just take a picture of your own blog post and say, read this. I think we've ruined the concept of microservices by giving it a name and then spreading it around. I work at Microsoft now. I hope those of you who know me are thinking this is the least likely Microsoft employee ever. But Microsoft is a good place. But I worked there because they bought our company. I worked at Wunderlist. I was CTO. And I came into the company and people heard that we did this microservices thing. So I've been talking to people who want to know how they can do microservices, too. And they really don't understand what it means. It's just a word. They've heard it's good. And they're really smart people. So we've already destroyed this concept. As I've walked around the company and talked to these people, these really smart people, like the guy who opened a text editor and started writing Microsoft Word. It wasn't in Word. It was in a text editor. But he was the one that wrote the first .c file or whatever it was at the time. People like that wanting to learn about microservices. I've learned that the real problem that plagues us all and these people especially, at least in this context, is coupling. Because we want to be able to change software. That's really the thing. We want to be able to bring things forward and make them better and better and respond to changing business requirements and whatever. So we really want to reduce coupling and software. That's what we're trying to do. Ruby is the worst language to use for that. So I wanted to mention Ruby because it's a Ruby conference. I've been using Ruby for 16 years now. And when we started using it, there were very few of us. And they would laugh at us. And they would say, this is a toy language. And we would talk about why it turns out it is a toy language. But it's OK because you can use it for creating toy software. And that's fun. Toys are good for playing with. And it's all about trying to have fun. Anyway, Ruby is really bad, though, about coupling. Why are you scowling at me? Ruby, Jeff gave me a list of things I should talk about. And I'm not talking about any of them. Anyway, so you all have a code fetish. All the speakers today have a code fetish. Most of them, anyway. We're always talking about code. I was up there playing the ukulele with Jim Weirich about code. You know, this crazy thing about, has anyone seen my code? By the way, apologies for my ukulele solo. I was not on my game that day. But code is actually not a thing that we like to have. As soon as you have code, you have legacy code. It's difficult to maintain. I say that it is a liability to have code. But what you really want to build is a system. That's the asset that we create. When I started my, oh, I forgot. This is the title of my talk, impermanence. I did have a title slide. Impermanence, the ironic key to systems that survive. So why am I talking about this? I have this sort of weird quest that I started in Colorado several years ago, driving around with Corey Haines. I was talking about the word legacy with him. And I was saying, why do we use the word legacy as a bad word? Should be a good word. I was a musician. And as a musician, the idea of leaving a legacy is really appealing. John Coltrane left a legacy, for example, Beethoven, et cetera. So I've been thinking about how do we create systems that can survive longer than five years or whatever the typical amount is. And I've been thinking and talking about this for years. I was then recruited to become CTO at Wonder List in Berlin three and a half, four years ago. And when I came in, we had an architecture that looked something like this. So here's my architecture diagram for the Wonder List II system. We had a circle on the top and a cylinder on the bottom and then some arrows. And how many of you have an architecture like this in your system? How many of you are trying to refactor away from that architecture? How many of you are trying to refactor to that architecture? Really? Really? OK. So we went kind of crazy. And we built this. I'm not going to explain everything here, but this was me with my crazy ideas from my legacy code thing and the stuff I've been talking about for years. I'm probably almost out of time already, aren't I? I had this point of view coming in that I wanted to build something that could survive. And I should remind you or tell you this is a to-do app. It's embarrassing. But it really is. You see these dots here, ellipses, or however you pronounce that? These represent tens of other services. So just imagine each one of these things as a separate service that's really deployed separately, talks via HTTP. We had 100-something independent services to make this thing go. And they were all really tiny. We launched this thing in 2014. And when we told our investor that we were going to do it, it wasn't the guy from Sequoia, it was someone else. You could hear him on the other line. You could almost hear him about the scream and squelching the scream. And finally, he said, please tell me you're never going to tell me you're rewriting this system again, because he'd been through this pain over and over with this company. And I said, we won't do it. I promise this is the last time. If we don't, if you find out that we're rewriting a system, you can publicly shame me. I will leave the industry. You can fire me from this job. That'll be it. So he felt pretty good about that, because I honestly told him, you can just embarrass me publicly. And I'll just leave in shame. I'll be done. Since we released this in 2014, we've rewritten almost every single piece of code here. But this has not changed. And that's the great thing. So the fact that we rewrote the code was very, very good. A little bit of where I was coming from, when I was starting to think about legacy code and how you can create systems that survive, I went through this really kind of superficial tour through how systems that survive work. So for example, you could have a car that's older than most software systems can be alive. And how is it that a car can survive that long in a software system camp? But the most remarkable one to me is I'm now 42 years old. I don't do any maintenance on myself. I don't deserve to be alive. But somehow here I am. So I started thinking a lot about this. And I first got kind of fixated on this idea from biology. And I will tell you the wrong, like the stupid, all I can understand version, because I really don't care about science, to be honest. But homeostasis is the process that an organic system goes through that will balance itself out basically. So you have all these, Marty says I'm right, he knows science. You have all these like competing things going on in your body. And if one was left unchecked and not balanced by another one, it would overrun the system and it would die. And I thought this is really interesting from the perspective of systems because you have like back pressure and all these concepts for keeping systems alive under stress. I thought this was gonna be the key, but I took a little detour and just kind of the most obvious thing. When you talk about biology with people and the human body, you learn early on in life that we're not made up of the same exact cells that we were previously. They're always dying and it's like trillions per second, I think. I mean, on one body. So imagine the death happening in this room right now. It's amazing. And we are, everyone in this room will die eventually, by the way. This is about impermanence. We'll all be dead. I'll die sooner than most of you, I'm sure. So why was, what was I doing? Oh, yeah, yeah, yeah. Regeneration. So this is how it works. The system of my body, somehow I'm still me and I'm walking around on the stage and I'm telling the same stupid jokes I've been telling for five years, but a lot of the matter here is gone and it's replenished. And that happens by the fact that my body can do that and it's a natural, necessary part of living because the individual cells, you wouldn't wanna try and build a thing like me where the cells just survive forever. That's kind of unrealistic. So I started thinking about this in terms of software and I got really sort of fixated on the concept of everything being tiny, as did Fred George when he came up with the concept of micro-servej. Microservices, for those of you who still don't speak the language. So tiny components, you think about it, if you're looking at code, when you come across a huge long thing like the pseudo code with all of the comments in it from earlier, sometimes it takes some time to figure it out because it's really complicated, but when you come across something really tiny, you understand it immediately, usually, unless it's obfuscated on purpose. So there's something really nice about small things and I got so into it that I did this whole talk, it was at CodeMesh in London a few years ago which is an excellent conference and it was in front of all these people that are way smarter than I am, just saying like tiny, keeping things tiny is the secret to great software, to teams that work well, to projects that work well, et cetera. And there probably is a lot of stuff that's true there and some of the things that stood out there is like think about some of these phrases and see, they don't roll off the tongue very well, like massive elite team, huge efficient code base, long successful project, enormous agile company. These days, if you put a capital A on that, it actually does sort of fit, doesn't it? I also did all sorts of superficial research for this one, like I did with the biology stuff and I found all these references to proof, of course you can prove anything if you just research it, but all these references to proof that humans are better at dealing with small amounts of information and it just makes sense. So this one is the magic number seven, plus or minus two, I think it is. Okay, good, wow. Plus or minus two, it's about the human capacity to retain information and then you start learning about chunking in different ways that humans take small amounts of stuff and when they get too big, they convert it into small amounts of stuff and, of course, they're grain chunks. There's also like Dunbar's number, if you've ever read the tipping point about sizes of teams as a certain size where you can't really actually grasp and maintain connections with people anymore so there's a cohesion thing. All of this stuff though, it leads to, I skipped a slide somehow, this is amazing, okay, it leads to the ability to do some other stuff and this is what I started figuring out after I gave this talk, so I'm kind of embarrassed because I went on the stage and I said, this is it guys, I'm done, I figured it out, but it actually, if you think about it, like tiny components, one of the best things about, say, a tiny method when you look at it or a tiny microservice is it allows you to consider replacing it, like you can change it, you can understand it really quickly, but even if you can't, if it's small enough and it's named well enough and it's decoupled well enough, which microservices tend to be, you can throw it away and just restart if you have to. So, also at Wunderlist, in the attempt to do this like biology kind of thing, we were using Chef, I think, yeah, Chef when I started, so any of you do that sort of stuff, Chef, Puppet, Ops stuff, the idea behind that is that you have a system, you need to keep it in a understood state, a consistent state and it runs for a long time, like I used to be a system administrator in the 90s, I remember having systems that were up for two years and being really proud of that. Now I realize though that's terrifying, like if a system is up for two years, it's very difficult to know actually how to recreate it, what the state might be. So tools like Chef and Puppet, they're obsolete of course, but they're all about maintaining a system that can stay alive for a long time. What we figured out is you should just throw away the systems, that's the best way to do it, don't change the systems because then you get rid of all of the issues of these weird, unchangeable, scary things, throw them away and start over. So we established this immutable infrastructure system, where if you wanted to upgrade anything on a given server, and of course they're not physical servers anymore, they're images or VMs, then you would throw away the entire thing and just rebuild a new one and replace it. The beautiful thing there is that you know exactly what's there, you know you can recreate it, you're doing it all the time, so the thing is changing, which proves its ability to change and it makes you have a system that is able to change. And so this has worked out very well for us. Then we started thinking about it in a little bit of a more radical way. Of course, you know, the several years ago we were doing that, that was already pretty strange. The more radical thing was, how do you change your software? Well, maybe you should just plan to throw it away. And this is where I start talking about the code fetish thing, you know. At Microsoft we have code that's 20 years old and it's reusable, it's shared all over the place and people will both love it and feel tied to it. So, and if you've worked in a big company you probably know this thing where you have these reusable libraries and you're kind of stuck to what they can do and they follow you around. They give you stuff, but you're stuck. So we started saying, well let's just plan to throw our software away. So when we write it, there's a little bit less stress. We can also try out new things because there's less stress about trying out the new things. And not only can we throw them away, throw away the pieces of code, but we should because think about it, if you need to be able to change your software that is the thing that we all sort of struggle with. That's the only reason we have conferences and talk about code maintainability. If you never had to change it, who cares? But if you need to be able to change it, if you do it all the time and you plan to do it then it becomes easy, throw stuff away. So, here we go talking about system versus code. Again, the mutability of the system is enhanced by the immutability of its components. And so what I mean here is if I need to be able to change an entire app system or software system, if I declare that you cannot change anything inside a component, you can only replace it. Then it makes the entire thing easier to understand and easier to actually change. So this is sort of a core thing that we figured out together on our to-do app. And as a reminder, the point here is that the system is the thing we care about. So I didn't lie to our investor. We rewrote all these pieces of code. We did not rewrite the system. It still exists. And I forgot to mention the reason we did that. I think it was within a year we rewrote 80% of the code. And there was no project where someone said I'm going to now work on rewriting a piece of code. There was nothing in a backlog. It was just maintenance work. So while I do this feature change, I'm just going to replace the whole thing. Why do I do that? One, because it's healthy to be able to change code so I'm going to prove I can. Two, the more important one, we were able to go from, let's say, 30 servers running a Ruby process to three servers running a Scala process because we had to replace the toy. People were using it. We had to use a real language for it. Sorry, Rubyists. I love Ruby. I'm just joking. So where was I? Yes, speaking of not being on Ruby, in the original version of this picture back here, I shouldn't be jumping back. It's really not worth it, but. The original version of this, pretty much everything was Ruby, except some things that just obviously wouldn't scale and work with Ruby without way too much work. And in the new version, there is still Ruby in here for some things that were just the pain in the ass to change we didn't want to. But now it's like, as I said, there are hundreds of services up here. When Sarah showed a slide with all these different languages on it earlier, we have all of them, actually. And my rule for the team is, you can use any language you want, even if you're an intern, I don't care. And for production, hopefully you can deploy it very soon to production, but it has to fit with our deployment system, our metric system, a few other things, but just a small rule set. And the reason I wanted to do that is because I actually wanted this radically heterogeneous code base. Because I've been in environments so many times over the years where you're on a specific version of the JVM or of Java or of .NET or of Ruby or Rails or whatever, and you get scared, you get stuck. Or you're on a specific platform. Everyone on the team only knows that platform. Like my team only knew Ruby when I came and chuckled when I talked about doing something other than Ruby. When you're on a specific platform or language and you're stuck there, you can't change the team. And that's bad. So I wanted to just fix this from the beginning and say, there is no such thing. On any given day, someone who would work on our backend might work in five or six different languages just to get their normal job done without trying to. Which means switching from Haskell to Closure to Ruby to Go to JavaScript, et cetera, Rust. The beautiful thing about that though is if the Ruby VM or runtime gets upgraded and we need to roll out a fix, we're not afraid to do that sort of thing because we do that all the time. Everything is already different. If we want to try a new language, trivial, we do it all the time. So you just try it. There's no big deal. If it doesn't work, the things are really tiny, which is the benefit of microservices. So anyone could just read it. Like if you don't know Haskell and you're on call and my Haskell service is messed up, rewrite an elixir and deploy it. That's your fix. Fine. But serious, like we've done this quite a bit. By the way, I just came from Berlin, so I'm asleep in my brain right now, but my mouth is going. And another rule that I had for the team is no shared code. And this is the one really freaks people out because sometimes when I talk about the service-based approach, they say, well, what do you do about shared code? We don't allow shared code. Even if we're in the same language, like one of the benefits of being heterogeneous is it's hard to have shared code because shared code creates coupling. I don't want that. Shared code is also permanent code sort of by definition because if I create a library and distribute it to a bunch of services, now it's like really hard to change. I don't want that. So we would do shared services and we did some things to make that not as stupid as it sounds, but even like logging, things like that. We didn't do shared code, we did shared services, all running on local host on the box, irrelevant because you all do Docker now or whatever, but then the way the parts of the system worked, we thought really hard about this. We thought like we could do Thrift or whatever the modern thing is that people would do. What is it called? Someone would know. I'm old and I would say Thrift. We just have HTTP and JSON. That's how our services interact. Even though we have hundreds of services for this to-do app, it's dumb and it's inefficient. You can read it on the wire if you can get into the SSL traffic, of course, but you can totally understand, as Dave was talking about, exactly what's happening on these services if you can somehow see them. And since the system is the asset, we thought if you have an obfuscated language that you can't understand for the way all the pieces talk, then you're screwing up the system and you're making it hard to understand. So it was more important to me that the system was easy to understand than efficient. Now the thing is this system actually ended up being way more efficient than anything we built before, even in a monolith, but that's for another talk. So the goal of all this, though, was decoupling. That's what we were focused on. And yeah, we were just making it to-do app but then we created this big crazy thing. Mike Feathers spoke at RailsConf about five or six years ago, and this is a paraphrase, but he showed this long Java method and it was a keynote and the first thing he did was bring up a Java method at RailsConf, which was funny. And he asked the audience, who here thinks this is good code? And it looked terrible. It was just like ifs and lots of indentation. It was terrible. And no one thought it was good code. Then he said, what if I told you that this code was created, it was committed once, it's been in production for five years and it works perfectly, it's never been changed. Now is it good code? You're looking at this terrible piece of shit code and everyone's saying, yeah, it's good code, isn't it? Like, you didn't have to change it. And Mike's all into analyzing source code history and trying to figure out a lot of interesting stuff about code metrics versus churn. And it was a really great point that made me think a lot. And for a while I carried this around and repeated it because I think I've always looked for an excuse for code to be bad and for that to be okay. I don't know, but recently I've had an experience that reminded me that he's not quite right. And the experience was last week we had this hellish outage. And the system that was the hardest to change in our big collection of dots was my Haskell service. And the reason is it's the best code we have. It's perfect, it performs better than anything else. It has never had to be changed because Haskell, if you write Haskell and it compiles it works, that's just how it works. I'm only partially joking there. Haskell's an amazing thing. But it's funny because we were so proud of this thing, but the fact that we had never changed it, even though we didn't need to change it, made it a liability. And it bit us and I spent all day last Saturday in my hotel in Berlin fixing a problem that was caused by the fact that this Haskell code had never had to be changed. So even there when your code is great, perfect, things change around it. That's the scary thing. So you really do have to keep changing things. You have to keep deploying servers even though you don't need to. You have to keep rewriting code to make sure that your assumptions were right and the libraries and dependencies were right or maybe that you really could accomplish this in another language. So immutable is the same as disposable in my world. Meaning, if you can't change something, then you have to be able to replace it at least because things do change whether you like it or not. We also sort of gave up on testing. So I thought about changing the title and direction of this talk to heresies. So here would be one of them in the list. Unit tests are a design smell. So unit tests are a design smell. Do not write unit tests, they are a design smell. Instead, what we do, I'll tell you why. I should probably, I'm just going next. Unit tests are a design smell. Like I said, my brain's asleep, but my mouth keeps going. Somehow this thing keeps getting clicked too. Tests optimize for permanence. They create more coupling because there's like necessarily another file you have to change when you wanna change this and that. But the idea is that when you're thinking about tests as validation, and by the way, I don't think that test-driven development is a design smell. I think that's a really good productive way to work. But thinking of tests as validation, it just bakes all these assumptions about your system into a file that you run all the time. So it creates stasis. So what we decided to do was focus more on metrics in real time and production. This is also based on my belief that we cannot avoid errors, but we need to be able to recover from errors very quickly. So mean time to resolution versus mean time between failure for you systems nerds. So we got really into measuring everything in real time at a granular level from a technical perspective. So like performance errors, those sorts of things, but even more importantly, a domain perspective. What are the things that happen in the system that we care about from a business perspective? In my case, it would be like users signing up, tasks created, synchronization's happening, the stuff that proves people are really using and getting something out of the application. And then we put alerting around all that and aberration detection around all that. And that's how we know we've screwed up our code. We do testing, of course, of certain types before we deploy, but after we deploy and we do it in small waves, we can see, whoa, we're screwing things up. We back it off and we can fix it. And that's really the kind of true test of the system of what the users are experiencing and how it impacts the things you actually care about. So I tend to take things too far when it comes to impermanence. I mean, I've already talked about my own demise. So maybe I already went too far there, but I think this also applies to management and organizations. You know, I'm the manager. I'm the general manager of, which I keep wanting to make like dungeon master, but it doesn't work, I'm the general manager of Wunderlist and I've done a couple of org change announcements since I started, reorgs. And whenever you do this, people kind of go like, ugh, you're doing it again. Why can't you figure out an organizational structure that will work? I believe there actually isn't one and there never will be one ever. And the fact that organizations change means they're healthy, just like a body. So organizations should also be impermanent and all of these things apply. I mean, you think about the teams that have existed for a long time, they're never the best teams. They always sort of decay or get stuck or, you know, they only have one way of doing things and they can't update their thinking. So I have baked into my management strategy that when things get too comfortable and it looks like they're gonna get stuck in a certain structure, I should change it. I will use some bullshit data to back that up. This is, the reason I say bullshit is because this is from the Standish Chaos Report, which is a survey that goes out to big enterprises talking to them about their software projects and determining whether the projects were successful. And a lot of people take issue with the way they run the thing, whatever. I don't care because I look at it and I think qualitatively it's obviously true what the results they're getting. It doesn't matter if it's like scientifically correct. Here's what it looks like. Successful and failed are probably pretty clear in terms of the percentage of projects they surveyed. Challenged means significantly over time or over budget. To me that's also failure. I don't feel like that's even close to success. So basically most software projects suck and fail, yeah? But if you dig in a little deeper they have some other breakdowns and there it starts to get interesting. Small projects, most of them succeed. And very few of them literally fail. That's pretty interesting. Why don't we learn from that? Small versus, and then look at large, geez, wow. Like just look at this, never make the mistake again. There it is, don't do it, right? Small projects are impermanent projects. Small project teams are impermanent teams. They will build, they will create a thing, they will disband and they will reform in some other image somewhere else. So this heterogeneous thing just kind of looping back on how stuff has happened at Wunderlist. People sometimes ask me, like once you let people do any kind of language they want, are there favorite ones they sort of stick to and the answer is yes. Most people don't like changing languages six times a day. I don't know why. But in our team, it's like there are go people and then there are like Scala and Clojure people. And some of it is can you tolerate the JVM? And some of it is are you like a UNIX nerd troll that likes procedural languages or functional brilliant person, you know? And so there have been some things coming up from the team where they're like, maybe we should just standardize on like, let's have it be Scala, Clojure, and Go and eventually work out all the other stuff. If I were a manager experimenting with my team, I would think that's pretty cool because one of the things I wanted to avoid, I didn't want to be that manager that tells the team, you know, these are your standards, you will do this because then they're going to be complaining, like I don't get to use Elixir at work and you've all been there probably if you're a software developer where you're just bummed because you can't do the thing you want to do because it's not the standard for the company. So I wanted to get rid of that. I wanted people to feel empowered and actually be empowered. And it should be a success now that my crazy stupid idea, the team, is now reaching their own conservative grown-up conclusions that, you know, maybe this is crazy, but I'm actually disappointed. I've been thinking pretty hard about it because what I think will happen is they will make the decision and it'll still result in the same mess where they get stuck, like you're on the JVM, you can't upgrade or whatever. You get to where you're not used to change and you get to where you're just a scholar shop and you can't deal with C-Sharp because whoa, we work at Microsoft all of a sudden. Ah. So a few closing points, did I do it on time? I did. Microservices, just to be very clear, in case any of you were thinking about moving to microservices, and I said that phrase moving to microservices, it is not a thing you can move to. It's not an architecture. It's just the concept of tiny stuff, but think more about why you would do it. People don't do that. You do it so that you can change things. You can do it so that you can reduce coupling. Maybe you do it for fun and then it doesn't matter. Small is not actually the goal here. Healthy longevity is the goal. And fun, of course. And at least in the cursory glance that I've given the landscape, systems that survive are made of components that can change. As Martin Fowler likes to say, if it hurts, do it more often. This is a mantra I took from my extreme programming days and apply to everything. If you need to be able to change stuff, change it all the time. Then it won't hurt that bad because you'll figure out systems for dealing with change. And finally, impermanence leads to decoupling longevity and agility. Now I might answer questions and then you might clap once awkwardly. Awesome way to be. In your face. Oh yeah. All of you will be replaced like microservices. Microserviche. Microserviche. I think we could do two questions. It's a quick one in the back right corner there. Back right. Hi. I worked in a place once when the managers said that you can use a new language only if you can convince another team member to use it as well. So this way, you know, one leaves, at least you have support from another team member. But I wanted to ask if you have so many languages in the team and everybody's like doing all those languages, isn't it like the sentence about massive none, whatever, you know, know everything but really don't know anything well. Yeah. Yeah, jack of all trades massive none. Yeah, I mean that describes me pretty perfectly. So you're right though. You're right that you might not have, you might not all be experts deeply in one of the things that you have in production. And we were worried about that a bit. What's happened usually is there's one passionate advocate that is that person or two or whatever, which sort of mitigates it. The other thing that mitigates it is that you can just replace it if it ends up being a problem. So, you know, we have two people that are really good at Haskell and one of them is the general manager and doesn't code anymore. So that's a bit risky, but we can throw it away. In the last one. Throw the general manager away. Yeah, I mean, we're working on that. Yeah. And the last thing is, oh yeah, my time is up. That's what it's telling me. And the last thing is that you kind of get used to patterns of how things work. So, you know, whether it be at the language level or even deeper, when you expose yourself to a world of having to change all the time, change technologies, at least in my experience, I've found that my pattern matching skill applies at a different level of abstraction that it did in the past. And that doesn't end up being an issue too much. And also, just use Linux and learn how to use S-trace and everything will be okay. I really want to know what Dave wants to ask. I'm sorry. So I'm 100% on board with everything you've said always have been. Obviously. Good. I learned it all from you. And I make a habit of impermanence in many different ways. And what I've discovered over the years is that many people I work with do not share my passion for throwing things away and starting again or doing something new. And there have been many instances of, should we say, stress that are introduced by all those changes. So, although what you're saying here makes a whole bunch of technical sense, to what extent do you see it also causing social pressures or stresses or, you know, nervousness on many people? Yeah, it definitely doesn't. And it doesn't, I have the advantage of being the visionary CTO who was brought in from the United States to Germany to change everything. And I created this articulated grand vision of craziness that included all this stuff that they all got. At least they heard it over and over. So it was kind of baked into the expectations of the new system we created, which I honestly think helps a lot because they know this is just how we do things. But then there is an emotional aspect to having your code replaced. Like I've had my code replaced in this system and felt yucky about it, you know, even though it is part of the way it works. And so we have had to sort of celebrate those things audibly, even when it's our own code, to get people used to it and to get people understanding it's part of our culture and that it's a healthy thing and that we need to, you know, give up our attachments. This is a talk about Buddhism, by the way, attachment is the root of all suffering and all that sort of thing. So we talk about it like that, but I think if you just waltzed into some other company and started doing it without a method behind it, you would probably not make friends. Can we give Chad a micro or perhaps tiny clap? Three, two, one. Thank you.