 I have a question for all of you. When was the last time you had a guest? Anyone had someone stay with them recently? Hands up? Anyone? What did you do to make their stay pleasant to tell some stuff out? You cleaned the toilet. Great. Anyone else? Made on breakfast. Lovely. You guys are all lovely people. Gave them a tent. So they slept in your garden, wonderful. So I've got two stories for you about guests and hosts. So here's story number one. So some months ago, I decided to put my spare room on Airbnb and pretty quickly, a woman named Alex booked into the room. And she sent me a message. She said, hey, I've actually never been in the UK before, but I'm thinking I might want to move to London. I want something different. I said, that sounds good. And then she said, will you help me? I don't know if you've got any time, but if you could show me around, show me things that you like, that would be wonderful. Sure, I said. So when she was coming, I made sure the flat was tidy. I put together a little welcome pack. It had a tube map, a tourist book in London. And I put together a little sheet, but had some tips and tricks for getting around London. Like, don't smile at anyone in public. And always carry an umbrella. There we go. Even if it looks sunny and the weather person says there's 0% chance of rain. And so on the day that she arrived, I went to go pick her up at the airport. It was a bit of my way, but it wasn't too bad. And when we arrived home, I took her on a quick tour around the house. I gave her the welcome pack. She really liked that. And then after she'd rested a little bit, I took her around my area. And then over the next week, we went to some popular tourist attractions. I took her around the city and also to some quirks that were favorites of mine that people wouldn't maybe typically go to. And at the end of the day, I took her for dinner. And I got to ask her, you know, what were your first impressions of London? What do you think? What did you like? What didn't you like? And it was really fascinating for me because I got to hear from someone who'd never even been in England before. And I was born in London and lived in London all of my life. And at the end of the day, eventually Alex did move to London. So that was pretty cool. I'm great as a host. Okay. So that's story number one. Story number two. It's like rails is my city and I've lived here all of my life. Said Theo to me one day. So Theo is my business partner. We run a company called IgnitionWorks and at the moment we're working on a system that helps businesses make sense of their unit economics and decide on next best steps. And so we're working away and I'm struggling to pick up this concept and I'm frustrated and anxious that he was disappointed in me. And these words actually made me feel better because they put my struggle in perspective. I was a welcome visitor in his hometown of Ruby on Rails. And I was hoping to make Ruby on Rails my home too. And I had a friendly local by my side. So how could I make the most of this and what could Theo do to help me? And so thinking of these questions made me think of when Alex came to stay with me. We both wanted her stay to be as enjoyable as possible. And this is where code hospitality comes from. So by setting the scene of a guest and a host and how we might be effective in those different roles, I think we can learn more about how we can treat and respect our teammates, how we can onboard new people quickly, and how we can work with people on our code bases in a way that's fun and where we continue being productive. And so what I hope you'll leave this talk with, I hope you'll leave it with a new way to think about problem solving, particularly when you're coding and picking up the next feature, and a new way to think about communicating, particularly when giving and receiving feedback. And the gist is that with code hospitality, hopefully we can improve collaboration and long-term learning across software teams. And one distinction I want to make that when I'm talking about guests versus hosts, I'm not, that doesn't necessarily mean junior developer, senior developer. It's more about familiarity in whatever domain that might be. It could be the group of people you're working with. It could be the code base. It could be a particular class. And this is more a sort of framework to just think about when you're approaching these problems, and hopefully it's helpful to you. So code hospitality, the guide. Who is this guide for? So we're going to try something. I'm going to throw out some phrases, and I want you to put your hand up if it applies to you and keep it up. And if one or more apply for you, put up your second hand, nod your head, whatever. So you've recently started a new... Oops, come back. I want to agree. You've recently started a new job. Anyone? You have got a new team member recently. Keep your hands up. Keep your hands up. You've rotated onto a new team recently within your company. You've recently started a new Rails project. Anyone? You're on a project right now and you're using an unfamiliar language. Maybe you're a manager. You've got people looking to you for direction. Yes, this is great. You've got people with their feet up. You regularly collaborate with other people. Come on. You want your team to be productive. Anyone? Come on, come on. You want your team to be happy. Right. Put your hand up if your hands are not up yet. OK. Right. So you're all in the right place. This is good. This is good. OK. So with every visit, there's some form of preparation. When you're receiving somebody, do you ever tidy up beforehand? We had some people say, yep, they always clean. When you're going to somebody else's house, how do you feel if you turn up and it's a mess? And what about when we're talking about code basis? Right. So just like a house, we know we should try and keep our code as presentable as you go along. But you know, why is this? You know, guests can be, you might think that you're the only one who's in your home or who's working on that code, but guests can be unexpected, just like when Alex booked into my house very quickly. And so it's not great if you've had to spend a lot of time doing this upfront cleaning just because another person's arriving. But also if you never have a guest, it's not great to be working with this upfront complexity. You've got this cognitive load, it's hard to make decisions and actually working on your own code becomes less fun. So, you know, it's good to keep your code base in a decent, clean state. And what does clean mean? Everyone has different ideas. So for Thea and I, some things that we like to ask ourselves are, have we named things consistently? Or is there something in there that's going to be a bit confusing? Do our objects have clear responsibilities? Like the sweet dispenser, I mean, who doesn't want a sweet dispenser that gives you sweets, but also tells you how much it ripped you off by? We look through our code and we say, can we read this easily? Does it make sense? Or are there some improvements to make? Oh, I just realized I've got a spelling error. Has anyone else seen it? All right, got it. Good, cool. Okay, so, you know, keep your code base in a state ready to receive unexpected guests. Who has been to London here? Anyone who has been to London? So, you know, we have a lot of streets that look like this. They're narrow, they're windy, but London may not have been this way. So, there was a great fire of London in September 1666 and it destroyed seven eighths of the city. And architect Sir Christopher Wren submitted these plans for the rebuilding of London. So, you might not be able to see it here, but they're wider streets, they're more geometrically arranged and more structured. And so, this was his refactoring of London. But, unfortunately, these plans never came to fruition because there was no money to input these plans and there was no buy-in from the politicians and from the royals. They all wanted to just return to normalcy. They didn't want to have to deal with this. And so, that could happen with code too, where maybe there are times when you've attempted to do things, but there are some things that got in the way, whether there's some form of technical debt and you don't quite have the time to do it then, or there's not buy-in from other people. But it's really important that when you're thinking about this, you understand the reasons for why something is not how it should be. So again, if someone turns up to your messy house, how does it sound if you say, I attempted to tidy up, but I couldn't be bothered. Like, does that convey respect to that person for yourself or for your home, for your space? So, I mean, in most cases, you probably do have a legitimate reason, but it's important to know the reasons as to why your code base isn't up for the standard you want it to be. And be prepared to talk your guests through them. So, take responsibility for these things and think about how you might do better next time. And for guests, be prepared to ask questions, but give your host the benefit of the doubt that they are aware of these things and that they've tried. What type of guests are we talking about here? Like, are you gonna be there to meet them or are they going to turn up to your house alone? So, have you ever gone to stay at somebody's house and they're not there and they've left you some instructions or a letter or something like that? So, this, if you're gonna stay at my friend Pete Holiday's house when he's not there, you're gonna find these instructions for how to look after his dogs and how to feed them, because they will be there. And it got me thinking about, in terms of code, what does this relate to? Is it perhaps a read me? So, read me's can be good for consolidation, even when you have been there to do the original onboarding, but what sort of code guest perhaps maps to the case when you're not around? Open source, if someone's coming into your home, you're not necessarily there, they're in their own home and they're trying to access your home. So, what if we had read me's that were more like guidebooks or tour guides around the general concepts present in our code base? So, think about the kind of current read me's that we see today. You know, they've got things like Ruby version, how you create the database, how you run the tests. So, all these things are really helpful for getting set up and running the app, but is it helpful for people to continue to progress productively and confidently if they're by themselves? Here's a snapshot of a read me from Active Record and it talks about how it implements the object relational mapping pattern and there's a description, a link to a blog post and some other points about the philosophies behind it. And so, you think about the projects that you're currently working on now. Are there particular patterns or approaches that you use that would be helpful to explain to someone when they're starting to contribute? So, here's the read me for the Code Hospitality Guide app. You know, we've got the usual things, we've got installation, usage, how you contribute. But there's also a bit of history there, so, you know, how did it come to be how it is now? You know, there's some approaches about the patterns inside the code base. And there's some reading material linked to external and internal blog posts and also a walk through. So, you know, you might be wondering how do I get to a service object? Well, here's one way that I approached it in this code. And so, it might be interesting to explore this idea of a read me that keeps you running. So, it goes beyond this idea of just getting set up and running the app. It helps you to keep producing features and being self-sufficient, particularly when your host is not there with you. So, every visit always has a first meeting. Here's a question, fish or fishing? So, I was talking to a colleague the other day and he said, oh, you know that phrase, you give someone a fish and you feed them for a day, teach them to fish and you feed them for a lifetime. What about if that person is starving? Should you give them some fish first because you might not get a chance to teach them? And so, I got me thinking, hmm, maybe it's good in this idea of a learning environment, we should try and find that balance between giving a helping hand and making someone self-sufficient. So, when somebody turns up to work on your code base, it is good to be super generous with your time and attention. So, you want your guest to be as self-sufficient as quickly possible, but they probably need that, you know, that helping hand to get them started. So, is there something that you know a lot about that other people don't? Can you give a lunch and learn a workshop on that thing? You may think it's obvious, but make it clear that they can ask you anything at any time. And guess it's always good to ask questions and it could be about anything, about something you've seen, about a decision someone's made and why they've made that decision, or it could just be an acronym someone keeps saying and you don't know what it stands for, just ask. And it's also good to say, is there anything you'd like to see that I haven't shown you yet? Maybe you want to see a particular file or you want to go over a particular concept again. So, make that space for them to make that request. And also, think about the impression that you're giving off. So, you might be like, it's time for me to get back in the zone and do my work. So, but what does that look like to your guest? You might have a question. So, you can say, I'm putting on my headphones, but I am in interruptible. And if it is the case that you're not interruptible, say so, and say when you might be next free and give them some alternatives. So, maybe, hey, write down anything you have to ask while I'm just doing this thing and then we can go over them afterwards. So, make sure you set the scene. Demonstrate to your new teammates that you want them to feel at home as soon as possible. It's just like that time when I went to pick Alex up from the airport. I went a bit out of my way, but it was that helpful first gesture that set the tone of fright and made her relaxed and made her life a bit easier. And so, it was a really good way to start her visit. So, every visit has some form of showing around getting used to a place. So, how do you give tools of your code base? If I tweeted out, I said, do you give tools of your code base? Where do you start? And I had some people say, oh, I start with the tests. I had one woman who worked in an insurance company say, I start with the insurance policy object and then I branch out to all the objects linked to that. And then I had some really interesting tweets that kept on mentioning this word, diagram. And these people were telling me how the most effective way for them was to draw diagrams and to tell a story around the current state of their code base. What's the context? How did it get to be there rather than just listing the files and the objects that you see? So, what might make up a component of such a story? You might draw diagrams about the objects and your code and the methods and how they link together. You might also look at business concepts. So, for example, Theo and I were recently working on a nutrition project. And we learned a lot about what are the theories behind nutrition? What are the different diets that people do? How do people's bodies work? And that helped us to think about how we were gonna build certain things. And then you can string that narrative together. You can say, hey, here's the sort of business case. This is the business concepts that we're dealing with. And here's how they map to these objects that you see, this code that you see. And so you're giving people that extra context. And you're giving them sort of cues as well to help them remember. So, you know, when you're showing someone around your house, you might see, oh, that mark on the wall, that's from when, you know, the cat went crazy or something like that. You know, they have those visual cues and they can remember. So, try and tell new teammates the story of your code base. And then there's always gonna be some activities in a visit whether you're doing them with your guest or whether they're going at it alone. So, let's look at working with your guest on different problems. So, what are truths about how rails is and what are no more than truths about the way you choose to do things? So, if I'd asked you to draw a map of rails, like think in your head, what would it look like? Would it look something like this? Maybe something like this? Oh, it keeps working. Or something like this. So, you notice how all of those maps look pretty different and they're all from people who have been programming in rails for years. And the key point I'm trying to make here that it's not about whether you understand rails or not, it's about how you see the domain. So, and why you've come to see it that way. So, I want you to think of the next feature or user story you're gonna pick up in your project. So, you're sitting down with your guest to tackle it. And how do you work out what your starting point is? If you're familiar with that code base, you probably have a clear idea of how you're gonna do it. You know, straightforward, we're gonna do it like this. But does your guest also see it that way? So, let's take this user story. As a user, I want to get inside the Tower of London. So, this is a historic castle in London by the River Thames. And so, you're sitting down at your computer with the person you're working with. And you're seeing this, this great aerial view of the Tower of London. So, you're thinking, I don't know, I'm gonna need a plane or something or a parachute. You're thinking about how you're gonna solve this problem. What you don't know is that the person you're sitting next to is seeing this. And so, they're like, oh, okay, this is gonna be pretty straightforward. I just need to walk through the doors. And so, when you're both sitting there seeing these two things, but you don't know that's what you're seeing, problem-solving is gonna be quite difficult and could be quite painful because you're just talking from totally different vantage points. And you won't progress unless you can start, unless you can see this and work this out. And it reminds you of this time that Alex was with me. And I was at home, over there, and she called me. Oh, I don't actually live by the River Thames, by the way. And she called me. And she said, hey, I'm at Tesco. This is like a UK supermarket chain. I'm struggling to find my way back home. So I said, oh, that's easy. You just go right and left and you're gonna be back. She said, cool. She called me back a few minutes later instead of done that, but I'm still not home. So I said, okay, go back to Tesco, I'll come and pick you up. But of course, when I got there, she wasn't there because if only I'd asked her which Tesco she was talking about, instead of assuming that she went to the one that I always went to. And it's the same when coding. We need to work out where each of us is standing, what we're each seeing and then start moving to the same start point. So some time ago I was working on this problem with Theo and we were having this conversation and we just weren't getting anywhere. And so he said, well, why don't you draw a diagram? Like, show me what you see and this is what I drew. And we can see from this diagram that it's a bit confused. And as soon as I drew this, I was able to see that my problem was that I was trying to understand the order with which things were happening because I had this sort of thing in my head. And so Theo said, well, why don't we draw like a roll activity diagram? And as soon as we drew that, everything suddenly became a lot clearer and it became very obvious. We were able to go, okay, right, and start coding confidently because we knew we were both heading in the same direction. So when working on problems with people, it's really useful to assume that you and your teammate are both lost. It's not that one of you is right, the other is wrong, you're just in different places and you need to find each other. But so to do that, scribble down these diagrams, work out what you're both seeing and then see how you can get to the same starting point. And these diagrams, they're not like the sort of documentation I was talking about before the read meets. These are like instantaneous communications, scribbles, just to get that conversation going. And now questions are gonna crop up either way when you're working with people. So how does the way that we've been talking about concepts help us here? So one time, Alex came to me and she said, I need to go to the pharmacy, I need to get some drugs. And I said, I didn't have time to take her there. So I said, oh, it's right by that restaurant where we went to the other night. And then she said, I don't remember how to get to that restaurant. And that's when it hit me that I had just sort of taken her there and brought her back. And I hadn't discussed how we were getting there. I hadn't, so nothing had to mention, she'd just been a passive follower. And even if I had been describing it to her, she may not have remembered it. She may not have kept that in mind because it's a lot to take in. And so this time I thought, hey, I grabbed a map and said, okay, here's where our home is. And here's where the restaurant is that we went to yesterday. And I said, here are the different ways that we got to the restaurant. And then I showed her where the pharmacy was. And I said, given the ways that we discussed, how do you think you wanna get to the pharmacy? And so we were able to have this discussion where she could contribute some ideas about how she wanted to get there. And I could check that I'd been understood based on how I'd explained things. And what's cool about this is when you're the one that's familiar, you can also end up exploring where answers that you didn't consider because you do things the same way all the time. And so when you're looking at coding problems, start the conversation by saying, okay, we've got a problem now. Here are some ways that we've approached this in the past. Here's how someone else may approach it, particularly when you're the one that's familiar and you've got this way that you wanna do it. It's useful for you to go, wait, how would someone else do this? And then say, let's look at the pros and cons about these different methods. Say, which way shall we go? So bring in the less familiar person to that decision-making process. And it's really helpful to just move that conversation away from the implementation detail, particularly when you're looking at these coding problems to the broader concepts. Eventually, it's gonna be time to say goodbye. So whether that's your guests leaving your home or someone going home at the end of the day at work. So remember I took Alex to dinner and I got to ask her in a relaxed setting. You know, what did you think? What worked? What didn't work for you? Well, in a workplace, we have things called retrospectives. So how many people have regular retrospectives in their teams? Right, so. And that's, you know, you get together with your team once a week and you're able to reflect on the past week, what, think about the process and think about what you can do better next week. But I'm not talking about a team retrospective. I'm talking about one-on-one retrospectives. We don't do enough of these. So it's useful when you've been pairing with someone for a day or even if you're just collaborating with them on a particular project for an hour to talk about how did it go and what could we do better? But here's the thing. Feedback is very hard. And how can we make it easier? It's really hard sometimes to say what you think or to get at what it is that you wanna say. And so a useful way to think about giving feedback, both positive and critical, is to frame it in terms of feelings. So how are you feeling? What's your emotion there? And reference those feelings back to observations of particular things that have happened. And then think about the needs behind those feelings that have the needs that you have that have led to you feeling in that way. And then make a request for something to happen next time to help meet those needs. And the point here is that we don't pass judgment on the person you're working with. Instead, you're creating a no-judgment safe zone and you're drawing attention to the ways that your needs are not being met. So what are some examples? You hog the keyboard. So that's difficult to say, right? We don't wanna say that. How about something like, I feel disappointed because I was hoping to assimilate what I'd learned on writing aspect tests. Would it be possible for me to drive more next time when we're writing tests? So that's an easy way for someone to say, hey, guys, I see what you're saying. You need to learn how to write tests more. So when it comes to tests, they can say, hey, do you wanna do this? And rather than saying, yeah, it was great. That's easy to say. What does that mean? How about, I'm feeling pleased because when I would explain things to you, you would stop typing, you would turn your body towards me and I had confidence that you were hearing everything I was saying. And it'd be great if you continued to do that and I'll try and do the same. And a useful format to start the conversation is to say next time we pair, next time we work together, what should we keep doing and what should we change? And so when giving feedback, focus on expressing your feelings based on observations and needs and not on passing judgment on the actions of others. So that was Code Hospitality, the guide. Let's do a quick recap. So when you're preparing, clean your code base as best as you can. And for things that you can't fix, have an explanation. Why are things not quite right? And think about the concepts that you're using, that higher level view. It doesn't have to be long. It doesn't have to be reasons of documentation. These things can get out of date. But even if it's just a paragraph, it's helpful and interesting for you to think about that and to start the conversation with your guests in that way. When you're first meeting your guests, be patient and generous with your time. Show that you're keen for questions. And for people coming into a new place, ask those questions. Show that you're keen to teach. And again, ask questions. I can't stress this enough. I know it's really hard sometimes. But if you're in the right environment, a good environment, then any question that you ask will be regarded positively and you'll get a good answer. When you're giving your orientation, give a story tour through your code base. Don't just list the files and these are the objects. How did you start and how did it get to be here? And where do you think you're going? And drawing diagrams helps here. They help you illustrate and they help you think about what you're saying and also for the other person to show that they've understood what you said. When you're working together, when you're doing user stories, when you're doing certain activities, start at that high level and drill down together. When you're familiar, it's very easy for you to just plow through the way you're used to doing it and that doesn't allow the other person to get that buy in and to contribute. And make sure that don't take it for granted that you're starting from the same vantage point. And so again, drill diagrams, check that you're looking at the same thing. And if not, now you've got a framework to start working there. And again, with the goodbye, you have your team retrospectives but have those one-on-one retrospectives. Talk to one another about what worked and what didn't. And make sure that you keep communicating with feelings, observations, and needs. And most importantly, stick together. Try and work with people closely as much as you can. If you're coding, try and pair. It takes time to get to know a place and you need that space to improve and iterate on the feedback that you get from the retrospectives. So based on what I've said, do you want to take the Code Hospitality Challenge? Yes. Okay, so what are you gonna need? You're gonna need a colleague. This can be someone new. This can be someone who's just started. It can be someone that you've worked with for years and find three hours in the day. Find a well-defined feature in your backlog. It's not important that you can finish it in the three hours. It's more important to have a clear starting point. So things like this, no, not good. We want something like this, you know. Something that we can read and say, okay, I know what we're doing here. And then in terms of structuring the three hours, spend some time thinking about preparation. Is there some refactoring you can do? What of some roadblocks you might have and discuss those? Discuss the problem, draw the diagrams. Are you starting, what are you both seeing? Are you on the same frame of mind with what this problem is asking for? And then when it comes to the implementation, so mainly this would might be coding, sit together, ideally work from the same machine and pair on it, take turns driving and writing the code and be communicating all the time about what you're doing and why you've made certain decisions. And then take 15 minutes at the end to have that retrospective, how did it go, what worked, what didn't. Here's a thing, you've got three days to do it and if you do it within three days, then you can win a special prize. And I want to hear all about it. So tweet code hospitality, I want to see diagrams, codes snippets, things that came up in retro maybe, or just general commentary on how you found it. And also things that maybe, ideas that you have about code hospitality and things that will work in this setting. If you have any question about the pairing side of things, particularly with logistics getting set up, maybe you're working remotely or maybe you don't know how to hook up computers to work together, come and speak to me or speak to Theo, he's at the back there, I work with him, we pair like 100% of the time, so we can answer all those sort of questions. If you want to dig more into the communication stuff that I spoke about, then this book is amazing, Nonviolent Communication by Marshall Rosenberg, it's all about how we can communicate in a way that brings harmony. So the way we're sort of talk to talk, it's all around competition, judgments, demands, things that something's right or it's wrong. And actually we struggle to think about expressing what we need, particularly in the heat of the moment, and how to effectively ask for what we want without miscommunicating or making unhelpful demands or thinly veiled threats. And so this book helps us get to that level of communication which avoids conflict and makes sure that everyone's needs are being met. And so everyone should read this book, I think. And if you read it and you don't find it helpful, then I really want to hear from you. Here's a blog post that the slides will go up so you can access this, which gives you a framework for doing the retrospective by writing an email with your pair together about how the day went. And shout out to these awesome people who've been so amazing as I've written this talk. I'm really grateful for their time and I'm so grateful to have their support. And one last question, how is your stay? Thank you. The question was, with the feedback, the framework says start with feelings and that brings emotion into it and it's quite personal and you want to work with the other person to get to a solution. So is there any reason why you start with feelings? Actually yes, because without starting with feelings you can't work out what's wrong. So it's by, so you need to individually think about you have a reaction to something. You have a reaction to something and it's because it's easy, first of all, to think someone did something and so you react to that and that can create tension. But really, if you think about why do I feel a bit down or why do I feel about sad? That's because you can work out, did I miss an opportunity or did I, or was there something that I really, that surprised me that made me happy? And the important, the why you start with feelings is because then you can go into the needs. And once you start talking to other people in terms of the needs, that's when they go, ah, this is how I can help you. So if you don't go there, you can't come to a solution because really you don't know deep down what is, how these reactions are, like where they're coming from. And so once you've heard someone, actually this is what I need, they can go, oh okay, now I can think about ways that I can help you and the other person can also share their needs. So it's still collaborative, it comes from a personal place but it's still ultimately collaborative. Yes, so the question was having trouble using nonviolent communication where there's power differentials and how can you make it such that everyone's feelings are on the same playing field? Well, I think it comes back to the questions thing. So I've, I think about nonviolent communication and obviously most people haven't read or don't know about it. And the hard thing is when you're in a situation with, like you said, different types of people is that you spot a lot of things that can make you feel tense because that's precisely why we have nonviolent communication. So what I found really helpful is to try and ask questions of the other person that teases out that need that need that they have and so say, oh, why did you say that because you feel, so you can make suggestions, you can say is it because you feel and so you get everyone and so they're forced to respond in a way that says, well, actually, yes, I do feel that way or no, I feel like this. And so before you know it, you've moved the conversation onto that framework without them knowing about it or without them needing to know exactly that this is a communication framework. So there's a lot of pressure on the person who knows about it to try and frame that discussion but I think making suggestions with those feelings and needs and asking questions can help before you know it, shift the conversation so that everyone is talking on that same plane. So the question was, as a guest, it's clear that I see the benefits and so it's good for me but if the host is not brought into it, how do I convince them? And so one thing, yeah, in the talk, I do start from this starting point of, we're assuming that the host wants to be helpful. So I think, I do think a lot of people, I think it's a valid starting point, a lot of people do want to help people around them who if it's a new hire, a new developer, that sort of thing, but they're just not sure how but I think what I tried to do in this talk and maybe I didn't do so well was to try and show that the host has, it's ultimately beneficial for the host too. So if you're being hospitable before your guest arrives, you've got a nice clean house, you've got a nice clean code base. When they get there, they're happiest, it's easier to communicate and work with them. Actually, you've got a new hire or a new teammate, they're gonna be able to be learning at a really rapid pace and contribute very productively. And so that's what you want. So really it's more about saying, if you foster this atmosphere, this is gonna work for your product, for your team and so it's beneficial for everyone. So the question was how can you apply this stuff when you're interviewing job candidates? And I guess it's similar to like if you're, it might be if you think about it in the terms of if someone may be coming to stay at your house but you both don't know yet whether it's gonna work and so you say, hey, come on in like an open house or a little tour. And so I guess it's again making sure, so you explain how maybe you do things or you ask questions to see would they be a good fit but it's also important to let it's their space as well to see will I be happy here? And so it's a similar thing of what are your needs? Like what do you need out of this job? And so then you can say, well, here's how we do things. Will those meet your needs? So it's like a two-way conversation and I'm inviting you to stay but will this work for both of us? Cool. Thank you.