 What an honor to have finally what Cunningham with this, you know, I tweeted the other day saying this is for me a dream come true to have what Cunningham finally speak at agile India. What has been someone who has deeply deeply influenced, you know, my thinking. So this is this is such an honor to have him present and hear from him for folks who may not be aware of all the awesome work that what is done let me. I won't be able to do justice to it honestly, but I'll give it a shot I will I will try. Then I think of what the first thing that comes to my mind of course is extreme programming I think you've been extremely influential in the extreme programming that's my first exposure to your great work. So later I realized that you were the, you know, one of the key players behind object orientation design patterns you brought Alexander's book and and you and Kent had discussions around patterns and then popularize that to a broader community so the whole thinking around patterns design patterns. What has to be the person who gets credit for that. And of course, you know, wikis, I mean how can I forget wiki. That's such a revolution in terms of I think people credit you to be the man behind web 2.0. You know, wikipedia encyclopedia everything that's kind of grown out of it. What a fantastic way to, you know, basically bring people together and get them to collaborate at a global scale. So, again, and of course, you know, fit which was your original thought process. For me, executable specification you know when I saw fit because like this makes sense like this is this is absolutely what it is so thanks a lot. What such a such an amazing amount of contributions and of course now in your daytime job you're with New Relic if I'm not wrong. And again doing some awesome work you guys folks at New Relic are really helping lots of companies so it's amazing. So again, I don't want to take too much time, you know, appreciate everything that you've done what and thanks for coming joining us today. It is a pleasure to have this chance to talk and and the fact that it's going all the way around the world's pretty neat to you know I like that and and I didn't have to get on airplane to do it so thank you very much for remembering me and inviting me this time so it's, it's pretty sweet. I, I've done a lot of talks. I've been working on this wiki thing federated wiki for for a number of years and I have an awful lot of content that's a few things I want to demo. So I'm just going to start in it. And I want to show you that this, this stuff is all available to you. This is a site called ward that fed that wiki. There are some important things there. And if I go here I end up at this site featured pages. This is the talk I did last week and this is what I'm doing right now. And so this is, this is where my talk will be and then we'll, we'll zoom to the right and get a little further into this as we go along but this is a little conversation we had I'd like to have the conversation that we had about what we're going to do so that while I'm working up the talk. I'm looking at it and say can I deliver on what I promised and I hope so. The, the thing that that that I can do that. A lot of other people are actually much better at agile than I am because they've explored so many ways to apply it to so many different things. But I was then I was there when there was only a few of us and I like to think about what we were thinking when we were looking for a new way to think about programming. And of course it's it's no accident that computers were changing dramatically this was the dawn of the desktop era. But I'd like to think more about learning about what computers do or I like to think what computers want to do versus what what you want them to do. And and that you get into a loop and that learning loop is really important so so in some of my notes I call this the age of agile versus the age of other things. And I want to just look at that at the three of them, because if we take each one apart and say, how does the learning happen how do we get better for having this. Then we won't forget that that stuff doesn't go away. You know, there's lots of ways to get better at things and so forth. This kind of answers the question is, are we done with agile or not and of course we're not done with agile. We're not even done with the redevelopment loop. And, and, and you may not realize there was a time where there wasn't a redevelopment loop. The computer programs could read interactively from the teletype or something and could print something. And, and it was the read process right loop or input process output they call it and the processing is what the computer did. And it was fixed it did what it was programmed to do. But it was really kind of while I was in college even that that people got good enough at compiling a language or understanding statements evaluating the, the process that became in the val step, where you could sit at terminal and type an expression and hit carries return. And that computer would do something it had never done before, it would evaluate your expression. And, and of course it usually say syntax error or something like that and then you say okay let me just try another time and another time. And that redevelopment loop. And it, it really started the list people got it. You know before anybody else because it was so easy to parse their language because of all those parentheses. But it was also a powerful language so the people would sit at that and have a conversation with the computer. And, you know, teach it to do a few things and then have a conversation with a higher level, and so forth that that redevelopment loop was fabulous. And, you know, the fact that it might take two seconds to compile and execute you, you were ready to wait those two seconds consistent very long to wait. And notice that it hasn't gone away. I am in a redevelopment loop pretty much all day long every day, and it might be in the, the JavaScript inspector or something, trying out does this, does this crazy, you know, JavaScript command really do what I think it does, or, or, or or unix the unix command line is the classic, you know, and, and, you know, that goes back to the 70s or something and who would have thought that it lasts that long. But, you know, to type something into that redevelopment loop and get a result and compose up the next thing is, is magical. Now, that changed. I mean as powerful as that is it wasn't enough to handle the desktop and with the desktop was a graphics display and the mouse or pointing device or whatever. All of that just changed the way we thought about interacting with a computer. And it was not an easy transformation the programming style changed so forth. But more importantly, you know, people could buy those computers and they put them on their desk and say I could do my work with this computer. If this computer were only a little smarter. And then they pull together a team of people to make it smarter and it would be, we called it the developers and the customer. You know, it wasn't really, I mean it was the person who got the authorization to have your time to work on their problem. And so they own the problem, and we own the solution. And we just had to get it to go together. And the most important thing that happened there is that we could take a guess about what they were wanting. Show it to him a week later. And they say, Oh my God, that is so close but you have to do this and this and this to in that that iterative thing. And, and to do it in a week. I mean, you know, going from a few seconds to a week is actually a big but but it was magical what you could put on a screen and people would just poke at and kind of figure out what they thought they wanted isn't what they thought they wanted and what they wanted but what they wanted is something like you showed them only a little better. And that iterative loop was at the heart of extreme programming. A lot of people thought we were crazy because we, you can't, you can't jump in and start writing code until you understand the whole problem. Well nobody understood the whole problem so we understood a little bit of the problem, and then we had a little more and so forth and I don't think there's anybody that doesn't understand that now. And that was, that was revolutionary. And it was, I mean, we like to think that we were all brilliant but it was really just the desktop demanded it. When the desktop showed up we had to do it. And so I want to talk a little more about that in a minute, because of what I thought were the most important ideas, but I'd like to finish this idea of thinking about how technology progresses and drags us along. The, the thing and and I don't know how many people are doing this but the, the big data center and the software as a service. Sign up a million users and serve them all at once out of the, you know, data centers around the world all this stuff is is fabulously complex if you have from time sharing the desktop was a big step from desktop to software services and even bigger and I think there's a lot a lot of people that are still kind of figuring out how to do that be relaxed about it. So, and I think what's really going on there when I talk to people of course they're still using the, the, they call it the Apple now the redeveloped print loop, repel every day iterative development every day and incidents, hopefully not every day. But you know you don't go very many days until something goes wrong that you simply can't explain that it's something that you've never seen before you may never see again. But you have to figure out what it does to get the, you know, the application running again, and this. I'll call it the incident recovery group. Something goes wrong. People have to fix it in the moment. When it's fixed, then you have to go back and say, how do we prevent that from ever happen again and what were the details of that and why did we make the decisions we did in the 10 minutes that we were trying to fix it that in retrospect, you know, maybe wasn't making the decisions to me but it was what happened. And that kind of analysis, after the fact in an incident. And this is just because of the nature of the thing when you get hundreds or thousands of computers working together. You know everything's kind of a little failing here and there and that you know and, and you can't, you can't. I mean things about a reboot themselves you can't be out there rebooting everything because, you know it just has to take care of itself but when it's taking care of itself it's, it's all these system things start to can't be anticipated. So, I wish, I wish I were a genius about that. You know I've always liked to get the computer to tell me what it's doing. And that helps we'll call that observability now, but the real thing is how do you organize your stuff, your code your teams your company, so that when the completely unexpected thing happens that you can move ahead orderly and muster the resources and so forth. And, and I look to this guy David Woods, and, and his, his cohort john all spa Richard cook or names and, and, and he has this thing he calls graceful extensibility. And, and this is, this is something when I say we had four things you know this agile manifesto do this and this and this and this is better than what we were doing. Well, this is, this is the manifesto to Trump the agile manifesto to my mind, and, and, and there's a document by this name and it's a pretty, it's a pretty difficult read I had to print it out with a marker and mark things and, you know, because, because Woods is an academic and he, and he's very careful in how he uses language. But what's really important is there's a table in about page two or three of this document says, here are the things. And there's 10 of them. And so we call S one to assist statement one two three four whatever, and they're organized into kind of categories managing, managing the risk of saturation, how is it that you make sure that your computer always has enough headroom to keep doing the work that it needs to do, and, and that you and your team have enough headroom to pay attention when you need to pay attention, and so forth and and what are you going to do to keep that balance. And he's got three things I'll just call mess one two and three. And, and, you know, you'll have to go hunt this up yourself to find out what they are but they're all about managing risk of things getting choked up in fall. The other thing I see I can even magnify this a little bit there we go that understanding that you're operating in a network of adaptive units, units might be people units might be servers. You know, it's everything's trying to get along to keep things going. And that adaptive behavior. It solves some problems and creates problems at a different level and woods refers to the tangled layered network, and that, you know, the layers well of course there's layers because you have a lot of different layers in a computer you have a lot of different layers in an organization, and they all think they relate this way, but it's tangled because when things are going wrong there's all kinds of interaction, and three more points on that. That's what I love. All these things have constraints. But part of resilience is in the moment, figuring out some way to outmaneuver whatever constraint is holding you back and that outmaneuvering is is is is really where humans are exceptional you know whatever is going on, you know, I'm thinking. There's that guy who lost the tail of his airplane and he's flying along and he figured out how to fly without a tail, and he got everybody home, you know, unhurt. You know, on the radio they say okay we've cleared the area you're free to land on this runway, and he says what do you think you think we can make it to a runway. Well and wherever the thing comes down but but that was outmaneuvering constraints and being prepared to do that is is what the woods is all about. Now, I, I want to, I'll get back to this in a minute, but I just wanted to mention this. So this is old school, our stuff, and the next generation. And of course there's so much going on in computers that that there'll be other versions of this having to do with big data and machine learning and stuff like that that are related, but a little different but this is this is the big data center stuff. Now, now what I want to really get at is what I think is kind of a misunderstanding. Sometimes of how agile works when it's at its best. And, and I want to say that, you know, our computer work there's a lot of rote work, you know, you've done it before you got to do it again, you know, you got to type this same commands, you know how to check them out. It's predictable and it's manageable. And if you tell your boss you're going to be done in a week you'll probably be done in a week you might finish early, because you know what you're going to do, and that rote work is not this stuff that woods is talking about. But, you know, in all of our work there's what I call unexpected solutions are required where where you set out to do something, and you think you know how to do it and it doesn't work. There's no way to say why doesn't this work what assumption am I making that doesn't apply. How is the computer different or the system of computers different. And, and, and this isn't just because some power supply went out this is just because we write code that has sufficient levels of behavior that it surprises. Managers start getting nervous because they said, gee, you were just clicking things off day after day and now, now I can't tell what you're doing. Well, you're groping for a new idea. And, you know, it's actually a pretty scary time because you don't know when you're going to find that idea you're waiting for a light bulb moment and you can't predict when that light bulb moments going to happen. But I like to remind people that this is actually the most leveraged thinking you're going to do in your computer careers when when the unexpected solution has to be delivered. And, and this is creative work and just like, you know, outmaneuvering constraints how do how do you overcome the fear that you're not prepared to do the job that you're being asked to do, and say, let me just sit here and look around and hope I get an idea. And after that happens about three years of that you realize, you know, ideas will come to you, you know you can do that. Now, this gets into the notion of, I want to mention velocity and technical that are two things that are are are misunderstood. One is what is good velocity and if you ask a manager, he says more velocity is always good faster how can we go faster faster, and that's not true at all that there is. You don't want to go real slow, but you don't want to go real fast you want to find that point where when something pops up, you're prepared to look for the unexpected solution. And that you're not trembling. While you're doing that saying oh my god you know this is supposed to be done at five o'clock and it's already 430. And that you can you can do that. And I wrote a pattern language about this which was kind of a leading into what we now call extreme programming and then agile after that that I called episodes, because because I felt that there was, you know, you're going to get along and then something presents itself. And this is like a new chapter. Okay, this programming isn't like it was just a half an hour ago, we're on to something new and and there's this build up you know you're looking what is it this what is it this. And it's kind of like climbing a hill. And this is where you're getting kind of nervous when we ever get to the top. But you get to the top and the light bulb goes on you say oh my god, I've got it this is going to work. And it's really a pretty exciting time. And then there's the kind of coming down the hill where now that you've got a solution you have to put that solution into the code in such a way that when you come back to it a month from now, you can in your mind recreate that state that time going up the hill. That's the episode. Recognizing that you got some hard work in front of you, doing the work, waiting, groping, what is what is this concept that I'm missing. You find it, and then you have to make that obvious in the code. And, and that is what we'd call a relentless refactoring you know the variable names were throwing you off so you change the variable names you you make it clear you put a function this really belongs over there, because now that we know the answer, we can say that. But we don't know every answer. What we're doing is we're saying, we just did two hours of hard work, and we want to save that hard work in the code, because we know we're going to be back here. You know, in three weeks with something that we never anticipated before but we have to pick it up so that that that getting into it getting out of it is something. And what you do is you just say, you know, on the average week. This happens two or three times a day and it usually takes about an hour and it's pretty scary when it happens, but we're seeing an average rate of production and the only reason you do this is because people want to know they can't tell what you're doing. So you have to tell them, well, we're, we're getting this work done at about this rate, and we have every reason to believe that it'll continue at that rate. And that is the right rate. If we try to work faster than that, we won't get the good answers. And if we work slower than that, we'll be a little bored and we'll put a bunch of stuff in there that we don't need. So finding, finding that right. And what I'm telling you here is this is a function that the computer programmers can feel when it's right. The manager simply can't tell. So a manager cannot tell you what the right velocity is. You can only tell them when you're doing the best job you can. This is the velocity we see. And with that is this notion of technical debt. And I just want to say that technical debt is, in my mind, a strategy. How can we work at a nice clip? And when we find a problem, we find a solution, we say, well, this is really a partial solution. This isn't the whole solution. But it'll allow us to deliver something to our customer this week. And then we can learn some more. And that is admitting that you haven't found everything, but you found enough that you can put it in front of a customer. It also means that you have to do this episode right so that you clean things up so that when you do get back into that, you can pick up where you left off. And that is the right velocity and that is managing the incomplete work as things you know you could have done if you took more time. But you didn't because you're racing something to the market and you want to have that interaction with your customer. And that is technical debt as a strategy. It's a strategy for optimizing velocity so you're making the most good decisions every day. Good decisions, not just crazy decisions. And that's where we want to really get technical. What does it mean to be good? And so here let me poke at something. This is my explanation for a manager where I was telling him that no, you as a manager don't get to choose velocity. This is where velocity comes from. And I coined this phrase normative, but this means that we all agree about what good is. And a manager will say, well, every developer has a different opinion of what good is. And if you let them know just argue. Well, yeah, if that's if that's what you let them do that's what they'll do but that's not what a good developer will do, because they discuss good with each other. This is this is a social process where it's easy to do if you're pair programming you say, you think that's the right answer why did you think that's the right answer because I thought we were going to go over here. Oh, you did. Oh, that's interesting. Well, I saw that yesterday when I was working with the other guy, you know, this this socialization of what good is and good is always dependent upon what you're working in who you're trying to please what rate do you need to go, and so forth. There is no universal good. There's just, you know, let's call it fit for purpose. And, and there's some process here so this is this basically says this is what we're trying to accomplish. And here's how we do it this is this is extreme programming explains some of the things that you happen. And, and, and how we get a working velocity out of that. So just a little bit of how to, how to code yourself out of incomplete understanding. And, and this came out of object during a programming well, you know in every message send there's kind of an if statement and you kind of set the objects right so you can have it both ways. Oh, this is what we thought it is and this is what we think it will be. And we're just going to have both in there in the system until we find out what's really right. And this is, you know, I wrote this to be read very carefully. So, I recommend you take some time and read this sentence by sentence by sentence and figure out what it means. But now we get to the good stuff whose job is it to decide what good is, and it's the people with the fingers on the keyboard the people who are feeling what the code wants to do what they want to do or reconciling wants versus needs and all that. And, and this, this is if you don't do this if you say I'm only doing this because my boss said to, I think it's the wrong thing but I'm doing it, you're shirking your responsibility have every responsibility to put good decisions into the code. And it's in good decisions every day, put it in front of customers every week, whatever. And more importantly, it's important that you in your colleagues agree on what good is. This is where test driven network and pair programming just creates a decision, a point where you can talk again and again and again about what good is and establish what are what are really the norms of the project. So how are we going to get this thing done. If we're going to work in it for the next 18 months or three years where we're happy on year two and a half as we are now, and that that is that is the key. Now, there's, there's something that happens here. I was going to go here. Let's let's do this. If I click on this. This is the same thing process technique, whatever. What I did is I just rewrote this and this is what you can do in this wiki because it's federated and I have multiple accounts and so over here I said, let's take this apart what I just said, I believe it. I believe it strongly it's something this often misunderstood I just went my, I said let's take it apart the process the technique the responsibility whatever. And let me line that up with woods. Thanks. Now we remember woods is managing risk saturation out maneuvering constraints, networks of adaptive units. And I'm over here XP in the norm of goods that's processed and so, and I started lining up on, you know, okay this process that's to an s3 little s1 in there but s1 is also responsibility which was made down here. And, and one of the interesting things is when I was done. I didn't have, you know, woods has 10 things and I think I only have nine here. You know, and so it was into what, what did agile leave out of all the things that woods knew we needed to do. And, and I'm just going to leave that as an exercise for you to try to figure out, but you know, they're, they're all numbered and and it and it and it'll be something that we simply didn't face when we're doing desktop computing, but we do face now so so so there's more. It is described in a different language but it's a language worth learning if you're if you're working at this level. Now, the, the other thing I've done with this is I've used woods graceful extensibility and we had a little checklist, it's more than a checklist it's a survey. You know, here's 50 things that we just asked you do this a lot a little as a team, and we go to all our teams, and we all here says 73 indicators of agile fluency and in our process and so forth. And so what I did well. I took some of our best engineers and I said, Okay, let me explain what would says, and let me say what we're asking our engineers. And how do they line up. So what I just did there before I showed how they line up. I just asked people for each indicator and here's, here's a list of the indicators. I squeeze it in my neuro column but if I spread out a little bit. Here's, this is 73 different things agile teams have one top priority. And then we have a team with two top priorities which you work on on Monday, you know, all these things everyone participates in meetings, potential security incidents reported block you all stress. Anyway, this is a nice list. And it was a little scrambled, but then we sorted it out after we pulled people and then we would discuss the team agrees or doesn't agree on these things if they don't agree that they do or don't then that's a conversation. And then we would bring it up with woods 10 thing 12345678910. And I would ask people, is this thing really about one or two or three or from this one's mostly about four, you can see the people so this is number four. So what you, you can do is see how well what we were asking of our engineers, and we would do this annually. How does that compare to what would thought was important. And where do we have good coverage and where do we know this is a good chance to try to figure out what we could do that we're not doing. I also, I'm calling them s's there are statements, they're also sometimes called theorems by theorem here, here, here is one person I asked subject one. He happened to be one of the team health survey, assessors, and another one was a reliability engineer and a team another, you know, another reliability engineer. And what do I ask six people here or something. And, and I said well how many s ones are there how many s twos how many s threes for and these are the reminding what all those things are. And the cool thing is I can pop this up on a radar chart and see these the and this is why I say this guy's blue so over here in blue this is this this person and so forth. And this, this gives us an indication of things that were good at and things that were maybe not so good as I scroll through this it's sort of, that's a little cool thing that you can do if you got JavaScript. Manage the risk. Everybody thought, well that's what agile does it manages the risk. But what about this stuff over here that are, you know, what is that s seven to fundamental forms. And gosh, I'm embarrassed that I'm having a little trouble remembering what that is because, because clearly we don't do a lot of it, you know, and, and so this is, this is how I've learned by comparing woods recommendation to to to to what we do in practice. Here's a little bit about we got started on this team structure and so forth. This a lot of good reading here. And it's the kind of things we can really dig into. Now, now, I see that the time is is slipping by. This is this is the heart of the what I wanted to do because this is the stuff that really I should be saying kind of natural conference. I do want to mention a little bit about wiki because I got some more going on in wiki. And, and, you know, the original wiki. We set out we said we want to understand we need a new literature of computer programming, something that recognizes the kind of challenges that we face every day. And it's not like mathematical proof stuff it's it's it's really more like, how do we get through the day. And, and that became a pattern language Alexander had a real lot of touchy feely stuff and in what he described. So it made sense. It was neat that that works so well. And in fact, as I walk around offices and I'll hear people talking about what they're going to do. And, and probably, you know, a subject doesn't go through until they, they mentioned to maybe three words that were coined in that wiki, you know, it was very active for five years, still pretty active for another five, kind of getting old for another 10 years. And finally, all the, all the brilliant people had moved on, and we're doing their own blogs and so forth so it's, it's now frozen but it's it really had an impact. Of course the wiki stuff got picked up by the encyclopedia people and, and people freaked out what do you mean, you know, my high school kid is writing encyclopedia articles that can't be good. It was good and and they try very hard. And so that's pretty amazing what they did. And it's amazing in this time full of misinformation that Wikipedia recognized as the quality source that is the thing that I wanted to show you is this had a creative element, this less creative here the creativity and how do we run a process where we don't kill each other and still end up with an article in the end of the day. So that's kind of creative in the process. Here, I'm looking for a way to go back to the wiki that isn't like we're all in one wiki and we have to agree we all get our own wiki, but there's a process of storytelling that can work there and it's based on the creative commons attribution share alike. And, and if we're all just put stuff up there and say you're welcome to take my stuff as your own. But don't forget where you got it. This is, this is what we do. And in fact, this whole site is really been built around that kind of thing and I say well here's something I did this the same page I just wrote this morning. So over here because I started over here and I decided I wanted to be here and so forth so the page gets around, and I can say show me that version of the page. And I can go through here and say well what what happened to this page, you know, and so I can, you know, it has all this kind of scrolling stuff. And, and this is this is so that you can have a variety of opinions and still make sense of what's going on. And, and I started hitting my back button. I see where did I want to be I wanted to be. Yeah, I wanted it to here's an example let me just tell you an example. Here is something that happened during the pandemic. I started just riding my bicycle around, and I didn't have a daily commute so I just went down dead end streets. And I discovered at the end of there's no reason to go down a dead end when I'm on the commute, but I go down a dead end and I would find that there's a little trail at the end of the day and I go down that trail dirt trail. You know the kids cut through and I could run my bike on and down at the bottom was a little creek and a bridge across the creek and I could go up the other side and I said well where the heck am I. And I'd use my phone I take a picture and I got the GPS coordinates, and I'd drawn a map. So here's what the map is looking like now. Now, now I actually have to like target well here's here, here's some trails marked here let's go there and here I mark some trails. I haven't been there yet, but this this. This is where I live. I've been. Let's see it's right down here in the corner 289 trails in a year and a half a pandemic. And what this means when I think five years from now when I think back to the pandemic. Yeah, I know that's when I really understood what water did as it carved up the terrain where I lived, you know it's water that makes these trails and dead end streets and so forth, 839 image and it'll be more this weekend. But the interesting thing is people were watching me do this, and they say well gee I'd like to do that too. So I had some friends in Seattle so I whipped one up. So let's do this for Seattle as places we visit in Seattle, and whoops, not from there we're not going to see it. But anyway, then a friend of mine said well I'd like to do this with seventh graders as a different kind of writing so so he numpy named it photo telling. And we wrote a vision. And what does it mean a place experience it's it's not. It's not that I got there, and I wrote this trail and I came home. And then while I was writing the trail it was it was an episode. Remember I'm talking about it has a beginning and then I get down to the creek and do I turn around or keep going. And I decide to keep going, and I get to the other side and now I'm someplace else. And it's an episode. And by the way, that's what I was drawing here. I was drawing episodes. Here's where I took a picture in another picture another picture. Here's where I intend to go are these blue things but the red things are all the episodes that I've had for a year and a half. Usually following around some trail or something. Sometimes I just find something that's not even on the map. So this is this is pretty important. Here we're talking about how to set this up as a as an assignment for seventh graders. So I said oh okay well just do a do do it experience your block by looking at the houses and taking a picture of the main entrances and I pulled up a little. This is Chris Alexander talking about how important the entrance to houses and transitions and so so here I'm elevating I say right there in your own street. You have some interesting stuff going on and and why not pull that up. And if I pop over here to this site where I actually have the images. Here's where I here's where I did some examples I said, here's an example of my street. And this is this. There's a little workflow here that you can upload some pictures and then get this little map and it reads the XIF and you're right a little bit about that. There's my doorway, but this was neat. There's these people have this, you know, we in our neighborhood we have a lot of front porch, gathering spaces, and once they did it was so much fun that we end up having a little place in our front porch to. And here's the next straight over is a little different. And this is, this is a wiki that now has a process model, and we can apply that process model to do work. Now maybe just documenting doorways isn't very complicated but work but here we're thinking about how that could go beyond that. And this is this, let's see, I think I'm right on time. This is, am I right on time. No, I used all my time. Oh, darn. It's so fascinating seeing you show through the wiki and you know just shows how passionate about this whole thing and you know, that's amazing. All right, so I think I can stop here. But if you go look this up this is pretty interesting. This is what is evolving as a way to program this stuff that not surprisingly is simple. And I want to make a pitch. I'd hope to make that pitch but I made too many other pitches at this point, I think that I would be pleased. Do we have time for one question. What's the best question that people have been asking. So I have one question. He says, why are you going to shut up because, no. I think everyone's just so enamored and kind of just lost with you in going. Well good because that's what I want to do and I was a little lost to but it that there's passion there let's say and there's as much passion as there ever was. And computers are more interesting than they've ever been. The damn things. Absolutely and that was that was very evident from from your talk so that was pretty awesome. I have one question here from Narayan for you and then maybe we will take the remaining questions, you know, at the hang out. So, I'll go ahead and read out Narayan's question it's a little long so I'll try and pause. So with with respect to waiting for ideas to basically come right. Narayan says with all due respect to the theory. This is what I have learned, waiting for ideas is probably not optimal. Doing something instead with what you do and have which produces mistakes and leads to learning is how he believes instead of waiting for ideas probably a better way and wants to know what are your thoughts. I agree completely and and if I say waiting for an idea. You know if you got a computer, you're going to sit there and poke at things or type things, or Google things, or if you're working together. Well how did you ever did you ever see this before no I never saw then it's not just me we're both stumped oh what a relief it's not just me, but whatever you do. When you're successful, take a moment and think about it and figure out how to do more of that. And, and there is a saying that, you know, good luck comes to the prepared mind. You know, this is, this is what really being a professional is is being consciously curious about everything that happens in the work you do, and how it might be better, or faster, or more thoroughly understood. And that's actually a very personal thing. But when you have the experience of the computer with somebody sitting right next to you this pair programming. Then you could say remember when we did this, then what happened and then then then that's when you put words to that experience, and that will be with you for a long time. So, so yeah, you don't turn your mind off and go to sleep although sometimes that helps, but no you're, you're, you, you, you stop and you say whatever I thought I'm doing is not what I'm doing I have to do something else, and, and experience as shown here's some things that work for me. Yes, thank you for that question is a good clarification. Awesome. Just want to add on to that is one of the phrases that I've often heard and use myself is action precedes clarity. And sometimes I think just, you know, studying to play around and doing things kind of helps you reinforce, or, you know, basically understand what is going on a little better before you can make a decision or jump to a conclusion. So there's this guy Friston, who's developed that to an algebra. And he talks about all living things probe to learn you have this model what's going on. It doesn't match with reality, you reach in and touch something. And, and that tests your theory against what's there. Carl Friston is, you know, if you really want to read some Bayesian something or other this and the other, but it's it's it's the good stuff and that that explains why it works. It's really so much like that right you have an idea you put it out there you, you know it's it's a way to probe the world and see what other people feel and I think that that's such a powerful way of collaboration so again just wanted to thank you for creating the wiki and everything else you've done a fantastic session as you're welcome so all you guys have to do is be creative to repay me. There's something wonderful. Yes, absolutely. All right, we'll see we'll see you around. Thanks so much. All right, thanks everyone. Bye bye.