JAMEY:  Hi everyone and welcome to Episode 54 of Greater Than Code. I'm Jamey Hampton and I'm very excited to introduce a guest panelist, Jacob Stoebel, from our Slack community. This is one of the benefits of being part of our Slack community, you might get asked to be a guest panelist. Thank you for being on, Jacob.

JACOB:  Thank you very much. I am joined by Rein Henrichs.

REIN:  Hi, thank you Jacob. I am super excited because I get to introduce, Nadia Odunayo.

NADIA:  Yeah, not bad.

REIN:  Not bad working on that name. It's a really interesting name. Nadia runs Ignition Works, a double act, who are currently focused on helping enterprise teams run and maintain cloud platforms. Previously, she was a software engineer at Pivotal and she originally learned the code at Makers Academy. She loves to speak at conferences and help organize them. In her spare time, she runs the Ruby Book Club Podcast and does as many commercial dance classes as she can. That's a pretty full ticket. You're doing a lot of stuff.

NADIA:  Yeah, all fun stuff.

REIN:  Thank you so much for being on the podcast with us, Nadia.

NADIA:  Thank you for having me.

JAMEY:  A lot of times, we like to start out by asking our guests, "What is your superpower and how did you acquire it?"

NADIA:  I guess my superpower is my smile because I'm always smiling. People always comment on it and it means that on the rare occasions I'm not smiling, people always quick to asks, "What's wrong?" I think my smile is special because it always calms situations and makes people feel warm. I guess I just acquired it. Naturally, I've always been smiling. I think I've been smiling since I was born.

JAMEY:  That's so wonderful. I love that you didn't even have to practice it. It just happened.

NADIA:  You see, I can't stop now.

JAMEY:  I wish we're a video podcast so everyone could see. Nadia, I'm really excited to have you on the show today because I know we're going to be talking about the idea of code hospitality, which I'm really interested in. It was a concept that I wasn't familiar with before. Can you give us to start the cliff notes on it, then we can get into it more after?

NADIA:  Sure. The reason why you're probably not familiar with it is because I created it last year myself. You wouldn't have heard about it anywhere, unless you were watching the talk for it. Code hospitality was born when I was working with my business partner on a Rails project and I was really struggling with whatever we happen to be working on at that time. I just felt like I was hitting a brick wall and I was beating myself up a lot about it.

To put it in perspective, Theo, the guy that I work with, he has got 10 years of experience in Rails. At the time, I had two to three years of experience so there was a big experience gap. He could see that I was beating myself up and he said, "It's like Rails is my city and I've lived here all of my life," and what he was trying to say -- and it did work, it did calm me down -- was that, "It makes sense that I'm getting this and you’re not because I live here. I'm so used to the streets and the way this works. I know this like the back of my hand, whereas it's an unfamiliar place to you so it's fine that you're struggling."

When he said that, that got me thinking about this idea of seeing our codebases and the tools that we use as places where we live. If I thought about it like, Theo is this person who's lived in the City of Rails for a long time and I've just arrived, I haven't just arrived but just to put it in perspective, I've just arrived and I want to get to know this place too so it was, when you're a new person visiting the city and perhaps you've got someone who has lived there for a long time, what's the best way for you to quickly start to find your way around, for you to learn about the quirks of the place but also for you to feel at home.

There were two roles that came to mind: the role of the host, the person who has lived there for a long time, what can they do to help make you feel welcome and to put you on your own two feet and then the role of the guest as in what can you be proactive in doing and what should you expect or not expect to happen if you are in an unfamiliar place. That's just the quick high-level overview of what the code hospitality concept is.

JACOB:  If a codebase as a city, does that mean there can be codebases that are unfriendly or might seem unfriendly or that might seem in your face or they could have cultures that are off-putting to a newcomer?

NADIA:  It's funny because when I first heard the proposal for the talk, it focused a lot more on the code itself and the codebase itself and how that code was written and whether it was welcoming or not. But when I started writing the talk, I found the ideas that I wanted to talk about were more around the people working on the codebase and how they interacted. Partly also, I found that was quite hard to stipulate what is welcoming and what is not welcoming because everyone has different views and ideas on what welcoming or good code is and I didn't want to go there. Also because I think it is more important to focus on how the people are interacting around the codebase.

But sure, I think there are some practices that are unwelcoming and in fact, one of the things that I talked about in the talk are READMEs as an orientation tool and how I think a lot of READMEs today are, I wouldn't say misguided. Maybe they could be doing a better job of guiding a contributor to a codebase beyond just the initial set up, for example. There are practices and things that I talked about that touch on the codebase so I do think that there are some things in the codebase that could be done to make it more welcoming or less welcoming but I do think that the important thing to focus on is the interactions between the people working on the codebase.

REIN:  I love just the metaphor of the codebase as a place because it lets you bring to bear all of your experience with traveling or with having guests in your home and your understanding of what makes that a pleasant experience or not and it just lets you transport all of that knowledge and reuse it when you look at what makes this codebase a pleasant experience to learn or what makes a person a good host to a new developer on the codebase. When I think about what do I do when I want to be a good host, I feel like I can apply a lot of the principles behind that directly, not even having fully experienced your talk but just thinking it through in my brain. I think that's what makes it such a powerful analogy.

NADIA:  That's great that you should say that because that's pretty much how I start my talk. I start my talk with this story about how I leased my spare room on Airbnb or something like that and this woman gets in touch and says that she's thinking of coming to live in London and do I have any time to help her to show her around. I tell this little story at the beginning of how I tidy up my flat, I go and pick her up at the airport, I plan things for her to do initially but I also make sure there's space for her to do her own thing. Then at the end, we have a meal and it's almost like, "How was that for you? What did you like? What didn't you like?"

Then I also tell a couple of anecdotes at the talk when she's trying to find a particular place that she went to before and I took her there but I didn't give her any tools to help her remember how to get back there. Little anecdotes like that at the talk, which I then tied back to, "What does this mean when we're coding with somebody or trying to introduce somebody to a codebase?" Things like if you're pairing with someone and you're just going ahead and doing things how you normally do it, then they're not really going to learn and know how to do it themselves the next times. Not much of the story of when the character of my story, Alex is trying to find somewhere that I've really taken her.

Then I also asked, at the beginning of my talk, the people to put up their hands if they've been a guest, if they've been a host, think of what makes a good guest, what makes a bad guest. Sometimes I asked people in the audience, "What did you do last time before you received a guest?" I start to prime people to think in terms of the things that you spoke about just now and then that gets them in the right mindset, when we start talking about the codebase, they start making those connections themselves.

REIN:  I love when you can find analogies that are so fittingly like this one that they explain so much just on themselves. Daniel Dennett uses the term 'Intuition Pump' to talk about things that when you think about them, they help you build your intuition just by thinking through and understanding that thing. In this case, just thinking more about how I would apply being a good host to onboarding new engineers onto my team and things like that, something I'm working on right now, is really interesting for me.

NADIA:  What's interesting is when I was giving the talk at different conferences, different people would come up to me afterwards and apply the analogy to a particular problem they had or a particular thing that happened. For example, I had someone come up to me and say, "I'm trying to explain this concept to somebody," and before I was just trying to say it how I would do it but I realized that's not very helpful now so I'm going to extend it this way so I'm equipping them to be able to do it themselves.

I did have one more moving encounter after one of my talks, where I had this man came up to me, he looked quite sad and he said, "You know, we just recently hired a junior developer and they recently left because it wasn't a good fit but listening to your talk, I realized that I did a lot wrong at the manager and I wasn't a proper host and really the problem was more on my side than on their side."

On one hand I was really glad that that person has come to a realization but also quite sad to think that what if he hadn't come to my talk and going forward, if there were more junior developers in that situations. I guess the positive is that that person realized but it was also quite moving that they looked genuinely sad and as if it they had a realization of, "I've been thinking about it incorrectly."

JACOB:  That's really interesting. I live in a town that's very different from where I grew up right now. It's a small rural town in the south in the United States. I feel like I've more or less become a person who lives here, not the person who visits. When I first moved here, I was very much a visitor and I was sort of thinking very consciously about why people do things this or at that way or why they drive certain ways, why, why, why, why, why and I think for the most part of it is I sort of stop thinking about why that is and it's making me think like when a family visits or when friends from out of town come and visit, me and my wife are talking to them about these are some of the quirks of our town, we find ourselves sort of re-investigating why those particular eccentricities that we normally don't think about on a daily basis. I feel like having guests to your codebase can have the same positive effects.

NADIA:  Yes, so you touched on an idea that I originally had when I was mapping out this talk but that didn't make it into the talk and that's the whole piece around you said, why people drive in a certain way or take a certain route or things like that. When I was first thinking about the idea of code hospitality, one of the key things was people getting to habits. They get into their habits and they do things in a certain way. Sometimes it's because they don't even think about it. They just go and used to doing it. They just get up at this time. They take the train just because or sometimes, people do certain things because they're optimizing for something that's important to them so it could be cost, it could be fresh air, it could be whatever.

There were two sides for that. One as a host, when you're getting ready to welcome another person, you can take time yourself to think about, "Now, what do I do things like this?" because for example, one of the ideas I had was the person coming to stay with you, messages you and says, "How do I get from the airport to your place?" Now, your instinct might be to just say the way that you always get from the airport to your place. You might just get a taxi, for example. But the real question is what is the guest's parameters? What they need? Is it that they want to get there as quickly as possible? Do they have a budget?

Thinking about codebases, when it comes to writing a test in a certain way or delivering a feature, you take certain steps and particularly when you're an experienced developer, you start questioning it. But when you're working with a less experienced developer and you have to start explaining things, now it can come down to, "I don't really know why I do it like that," or, "I don't like this because I don't have this pain before and this is a way to avoid it."

But if you do uncover the reason why you do something, one, the other person you're working with, particularly if you have a particular reason, they might be able to show you a way that's better so you might say, "Oh, I do this because it's cheaper," or because it's a safe way to maintain quality. The other person might say, "Oh, have you thought about this?" The stuff is within your parameters but it's a new way. Alternatively, if there is no real reason and it's just habit, then once you recognize that, you're probably more open minded to try things differently anyway because you realize, "It has been done in that way for 10 years and no one's really told me otherwise. Of course, I'll try something else.

I think it's very valuable starting to question, "Do I do this out of habit? Or do I do this because there's a real pain or there's a real need and I want to protect for that?" and being of either way, can help you explain it to others, explain it to yourself, particularly be open to finding new opportunities when you work with different people. One thing I want to mention, though is I just use the comparison between a more experienced developer and a less experienced developer. Something I said at the beginning of my talk is, although the examples I'm using, because I'm talking about myself and Theo or they'd map to a senior developer versus a more junior one, but I'll say that the difference between a guest and a host is not equal to junior versus senior because it's more about expertise in a particular realm and that realm could be anything as broad as a whole codebase or to the team you're working on, down to something particular line of code.

In some versions of the talk, I give a particular example where I was working with an iOS developer who'd been doing iOS work for five years but they'd never done test driven development. He had five years more experience than me in the iOS side or the Objective-C side but he'd never done TDD and I'd had two years of experience in that, for example. When we were paring, he was the host, when it came to writing the code and I was the guest but in the same session, I was the host when it was like, "Here's how we think about test driven development," and he was the guest so I try and pitch it that. It's a malleable thing and it says more of a frame of mind that you'll always be a guest and a host at the same time, most of the time.

JAMEY:  I really, really like that because I think it can be really easy to get very caught up in the junior versus senior. This is actually helpful for me right now because I work at a very small startup and we recently hired a new CTO. I was the only developer at our company that had expertise in the codebase but then we hired someone that's much more senior to me, to come in and be my superior. I felt very uncomfortable teaching him about code because he has more experience in this and he's a senior level person and he knows all these things but he was coming to me with all these questions because it was about things that I was familiar with.

I also really like what you said about reconsidering why we're doing things in a certain way because when he would ask me, "Why is it like this here?" I felt very uncomfortable being like, "I don't know. It just is." Because I felt like he was going to be like, "But why? Explain your decisions to me," and some of this was from before I even started at the company and I'm like, "I don't know, because someone did it that way," and I felt like he was going to come in and be like, "Well, you don't know anything about what you're doing at all." It wasn't like that. It was more of like, "Let's discuss this," and I think putting that frame around like 'this is a good time to discuss these things' is very helpful.

NADIA:  That's another thing I mentioned in my talk. When you said this idea of you were concerned that this new person would come in and start saying, "Why have you done this? Why have you done that?" At this talk, I talked to either the host or the guest and for the guests, I make this point of when you go into someone's house you don't go around saying, "This is messy. Why did you put this there? Why did you put that there?" You're often quite polite and I say it's almost the same thing in a codebase, which is be patient and wait to hear why things are in a certain way.

If you see a lack of tests or maybe a messy bit of code, ask questions about it but don't cast a judgement immediately like, "Why you didn't go test it?" or, "This is awful. You don't know what you're doing," because in the same way that you would go into someone else's house and say that, it’s a [inaudible] thing, this context in history that you don't know. It could be that indeed was an oversight or was negligence and it's a bad way and you're going to help them see a better way but just like how you wouldn't just start commenting on someone's things... Well, I think you shouldn't do the same thing in a codebase but I think people do feel that it's easier to [inaudible] a new codebase and start grumbling about the code and say, "This is not to my standards."

This is why it's particularly important that the whole guest/host thing is not mapped to junior/senior because you can be a much more senior developer going into a codebase that you've never seen before so you're the guest. But you think, "This is not the standard," or, "This is all wrong," but really, you need to take time with the team and hear the story. When you go to someone's house and you see stuff all of the floor, wait to hear the story about why the stuff all of the floor. Was there some works done and there wasn't time to finish it and the person had to go and do something else but they're aware of it. Hear the story as well, so be patient as well.

JACOB:  It would probably be harder to learn about the place when your mindset is looking for things to go... I mean, using the analogy of host and guest and not host and cop or host and invader. It's like, you're trying to learn more and then eventually, you can live there and eventually, you can say, "Now, that I'm your roommate and not a guest, the clothes on the floor are messing up my ability to live here."

NADIA:  Exactly. I like the thing what you said: a host and a cop, like an inspector for example. You're not an inspector going to say, "Yep, check, check, check. This is all good." You're trying to move in as well so it's a compromise and it does relationship building and it takes time.

JACOB:  Right.

JAMEY:  I think there might also be a call for empathy here because if I went into someone's house and it was a mess and they said, "There was some sort of natural disaster that costs our house to be a mess," I would be like, "I'm so sorry. That's so horrible. How can I help you fix it?" Whereas if I went into a codebase and I thought it was crap or whatever, you might be more likely to be like, "Why is this like this?" Even the reason is there were problems and there were issues and we've had a natural disaster, in a way or things out of her control, maybe it's a call for empathy to be like, "Oh, I'm sorry that your codebase has gotten messy because of these things out of your control. How can we fix it?"

NADIA:  This interview is a good sign. I think I had a little bit of bright ideas tied up because my main conclusion is that when we do code hospitality, it enables us to empathize and I talked about how it's really difficult to work out what empathy means and what it is and how you practice it. If we have a framework that we can use that's very common to all of us, it's very rare that we are never in a situation, even if it's very temporarily, like if we enter a new building or a meeting that we haven't been a guest or host, then even when you're the guest, you understand what it means to be a host and you can put yourself in the other person's shoes and understand where they might be coming from.

Like you said this idea of natural disaster, there are so many things happening around a codebase that could lead to a poor codebase. It could be people leaving all of a sudden, difficulties in team communication, all that sort of stuff so that's why you need to understand and empathize with those sorts of issues. If you're a host and you think about, "Oh, yeah. What would it be like to be a CTO or a developer on this team when three people have left in the last two weeks?" or when they're suddenly bought by another company and there's a lot of flux or they have so many remote developers and they're all in different time zones. If you start to think about those things, then you can say, "Oh, I understand how we got here."

JACOB:  Cities have histories that are living in there, on their streets and buildings. I guess codebases can too. When people are visiting wherever I happen to be living, I love sharing those stories that are embedded inside the physical place, like there was a fire here 10 years ago in this neighborhood and it's never been the same since. You can say the same thing as just like you say, what's the story behind the lack of tests. Is there a trauma behind that? Is there a story of people that are overworked or burned out? There can be some real human stories attached to certain parts of the codebase.

NADIA:  Definitely and one of the bits of the talk where I talked about orientation and I talked about the README, I talked about that is a good place to explain the history or context or the narrative, if you can or if there is something around the current state of the codebase, how it got to be where it is or anything that would help someone who's coming in just to set the scene in their head. I use it, particularly I say, even for open source projects where everyone is remote essentially, really it's like you're going into an office but they could have be a lot of history on an open source project that understand, this is how this project came to be, this is why the states come like this, this is the history of the maintainers. The story behind it, then that can help someone come in and understand, even if it's a specific feature they're going to deliver, they can have the scene set in their head of this is all the history, whether it's a political one or a social one or maybe there's nothing but that can help them start to feel at home in that repository, for example.

REIN:  The more you think about it, the more it just strikes me as such a fitting analogy. Code is written by people. Code is a manifestation of the culture of the people that wrote it, the problems that they have, the constraints that they have. Cities are the same thing. Cities are manifestation of the cultures that built the buildings and the geography and the access to resource and all of these constraints, all these parameters that cost the city to be the way it is but the city is also evolving and changing all the time: old buildings get removed, new buildings get built and a codebase is the same too. One of things I love about the city analogy is it captures this idea of change as being normal and necessary.

NADIA:  Yeah, definitely. The fact is just like a home, every day that you live in it and you walk around, things are changing. It's the same as codebase. It's constantly changing. That's why I think it's quite important that one provide the tools to help people get set up but also know where to go next so that's why I talked about READMEs often get you to, "Now, you have it running locally," but they don't mean to guide you in terms of this is what this home is about, this is the history here. But also, that's why it's important when as a host, to not only help you guest out initially but also give them the tools or the set up that they can help themselves because you can't be holding their hand forever.

While I'm a big proponent of pairing all the time or pairing whenever you can, even within a pairing situation, the other person needs to feel confident and know that they could do this by themselves, if needs be. I talked about the fish versus fishing. An old colleague of mine, he said to me, "You know, that phrase, 'Give a person a fish, feed them for a day, teach them to fish, feed them for a year or a lifetime.' Well, I think that phrase is bullshit because if the person is starving while you're teaching them to fish, they're going to die."

I love this and I thought, "I could put this in my talk," because it is important to find that balance between giving someone some fish or maybe some vegetables if they don't eat fish, and teaching them how to fend for themselves. If someone new comes into your company or joins your team, you should assume, not that they're starving but assume that they need a bit of sustenance and support just to get them going, then they can focus on starting to ramp up and be independent by themselves, I think it is important you find that balance because, like you said Rein, things are always evolving so if you suddenly throw someone in the deep end, it's likely that they might not be able to keep up.

Also if you do that, they might not also know that it's okay to ask questions and say that, "No, I'm not fine," because they think, "I just got to keep up." Before you know it, it might be too late like that story I told you earlier about the person who said the junior developer that didn't work out and they were gone very quickly. That could be the case of someone thrown into the deep end and they weren't given enough support. But then, because things are always changing, you can't rely on always having someone with you so you also need to be at the same time equipping this person to be able to deal with that change and handle it by themselves. That concept of being primed for continual change is very important.

JACOB:  Maybe instead of teaching someone to fish, just fishing with them?

NADIA:  Yeah, probably -- pair fishing. Then if one day you don't turn up, the person realizes, "Oh, I know what to do because I've been doing this by myself with my pair for a while."

JAMEY:  I love that too because with fishing, I think a big benefit of pair fishing or just be that it's more enjoyable to fish for someone else, than to do it by yourself. Maybe, that could be the same with code as well.

REIN:  Yeah, another one I think is that it's actually really hard to tell someone how to fish versus showing someone how to fish.

NADIA:  Yeah, I think it is more effective to show somebody, not to tell them because even through the act of telling them, that adds another layer of communication like a potential miscommunication. I think it's a combination of showing and then also communicating what you're doing. One of the things in the talk that I mentioned is to say [inaudible] diagrams whilst you're coding because it's one thing to show somebody something but when you're approaching a problem together, you probably have different mental models of the starting point.

To get this point across, imagine that the next story in your backlog is as a user, I want to get into the Tower of London. The Tower of London has start [inaudible] in London, over on the Thames and I say, "You're looking at it and you see this," and I showed this aerial view of the Tower of London. Then I say, "But the person you're working with is seeing this," and I show this view straight on to the door so on the ground looking at the doors. I say, "Obviously, both of your respective heads, you're going to have a completely different solution to how you get into the Tower of London.

I say that it's the same when coding. You might pick up user story and again, particularly someone who lived there for a long time and you just joined, you probably have a different starting point in your head just from understanding, "I know that the codebase behaves like this, it has this quirk or we typically tend to approach this kind of feature like this," and the other person probably bringing a perspective from different codebases or how they used to do things. I say something that's useful that it's just always before diving into the code, talk about it, get out, even if it's just boxes and lines or whatever sort of thing works for you. I talked about how when I was working with Theo on a particular problem, we weren't going anywhere but there was this perception of, "This is easy," and I was thinking, "No, this is hard."

Theo said, "Draw how you think these objects are interacting," and I drew this jumbled up diagram, which showed that I had this jumbled up concept of how the object were behaving or interacting and that's why I found it difficult but we drew a more streamlined diagram together, I can't remember what they called. It's the kind of diagram that Sandi Metz has a lot of them and her POODR book with the boxes and then shows how the messages being sent. Is there a particular name for this? Is it role activity? No, I can't remember.

Anyway, I drew a different style of diagram with Theo that was a much more straightforward diagram. As soon as we do that diagram, it was immediately like, "Ah, I know what test we need to write now. Okay, I know about implementation," and it was just so powerful, just drawing that diagram and to think if we draw in a half an hour early, that would have been half an hour of, "Don't know where I'm going," that we just wouldn't have had.

One of the things I talked about in the talk is pair but whilst pairing, have scraps of paper around just you can jot things down, check you on the same page and one of the other things I say is that it's important that, even if you're the host -- you're the person who is more experiences -- you don't assume that it's the other person that's lost and that they need to get to where you are. Instead you're both at different places, how do you get to the same place that then stop going because if you always assume that it's the other person that's lost and you're in the right place, then we get back to all of those things that we spoke earlier around your habits and you just do things the way you do and open to different ideas. There might be a better way to do things. It's also not a helpful learning setup if it's like teacher/student. It's very important that it's guest/host as opposed to teacher/student and, "I'm right and I'm going to tell you how you're going to pass the test or find the right answer," because that can also just not be a helpful or empowering learning set up.

REIN:  I am reminded a little bit of and this was also mentioned in Daniel Dennett’s book Intuition Pump, Rapoport's Rules for holding an argument in a kind way. The first is that you should attempt to re-express your targets position so clearly, vividly and fairly that your target says, "Thanks. I wish I thought of putting it that way." What I've actually found a lot in working through problems or conflicts is that a lot of the times, if you can see the issue from the same perspective or if you can share the same perspective, the issue actually just goes away and the issue actually was a mismatched set of understandings or perspectives.

JACOB:  Or sometimes, it's like we agree and we just choose to tell the story of how we see it differently but when we get right down to it. We prefer to argue about how to get to a place in the city, rather than just about where to go. It's like someone will find, "Oh, it doesn't actually matter which way we take."

JAMEY:  I feel like when an argument ends with, "No, actually, we agree," we agree the whole time. It's good. It can be frustrating because you'll like, "We just wasted time arguing for no reason," but I usually feel like, "No, it's good. We are on the same page."

REIN:  I would say that the activity of getting on the same page is probably the most valuable thing you could have done in that time so it was time well spent.

NADIA:  Yeah and it always feels really relieving afterwards. You're like, "Oh, okay. I feel good now." Even if you're like, "What did it take so long if we were on the same page?" But this things always happen.

REIN:  This gets back a little bit when you have a guest come into a codebase to be polite and to be understanding of the situation and how it arose and not just assume that don't mistake your lack of context for all of your ideas have to be right because you can't see why they could be wrong. One tactical thing that I try to do is I try to always say, "What if?" instead of, "You should do this." I always just say, "What if we change this to be like that?" because that gives them an opportunity to say, "It's like this because of this that you didn't know about."

NADIA:  Right. When you say 'what if,' is that a place where you know the answer but you are trying to use it as a learning tool or you go --?

REIN:  It's usually when I want to suggest a thing that I think would be an improvement but I don't know if I'm right or not because I don't have all the context to know why that could actually not work.

NADIA:  Yeah, I think that's a great tool that anyone could use actually. Another thing I found, actually when working with most experienced developers is that if you say, "Let's do," I'm not for one trying to shut you down or whatever. The other developer might say, "No, because..." and they're not trying to just prevent you from doing things but if they foresee, "Ah, that's not going work because I've had experience of this before. I didn't know you're going to come into that pain." I think that's a disadvantage because often, less experienced developers need the chance to fail to understand why things have failed, in order to help them to learn and make better decisions in the future.

However, when you phrase it like, "What if we did," perhaps in some cases, we'll force the other person to think about why. If they haven't got a good reason, then they're more likely, I think to say, "Actually, let's try to see why." Even if they say, "I have a hunch that it won't work," but they'll say, "Let's try because I'm not sure." I like that tool of 'what if' other than, "Let's do this," but I think that makes it easy to say, "Oh, no. I don't think that will work." But if you go, 'what if' and then why, I think other developers, especially those open-mind to learning will want to see for themselves, "Why not?" if indeed they can come up with a good answer. But if they can, then that's also a better learning tool as well.

REIN:  Yeah generally, I get one of two things out of it. I either get more understanding of the thing and why my idea what more or we try it and it either works or it doesn't work. But I will say that on the flip side, I think that the host has a responsibility to value and encourage the new perspectives that a guest has, because a lot of times when you're living in a situation, you can't see it with fresh eyes, you can't adopt a beginner's mind, you can gain a lot by being open to suggestions from a guest, even if they're not phrased in the most polite way and to try to work through what can be superficial communication issues, to get at the actual insight that they might have.

NADIA:  Yeah and that's why, I think the analogy is really important on both sides because it's not just, "I'm a guest so it's fine. I'm unfamiliar. It makes sense that I don't stand this." It's also, "I'm a host so I have to be a bit careful, a bit more reserved just because this person is vulnerable and uncertain so they may say things or do things, which don't typically fit what I'm used to but that's not because they're wrong. That's just because they know differently." If thinking about it, they come from a different culture or a different way of living or a different environment so it's not wrong. It's just different. I think that's very important, this idea of right versus wrong/different and maybe, I could learn from different as well as teaching my way.

REIN:  Actually, at least for me, it's really difficult in the host role and the guest says, "That looks bad. You should do with this other way instead." Even if they're right, I find myself less likely to agree with them and it takes a lot of self-assessment on my part and self-regulation to be able to say, "You know what? Despite how that came off, I should actually think about whether there's something there or not," and maybe talk with them about how we could exchange this information in a nicer way in the future.

NADIA:  Yes, definitely and that gets into another part of my talk, which is a little about feedback. The talk is split into three parts. The first part is about setting tone. It's all around the, "This is not teacher/student, senior/junior. You might want to do some cleaning, think about how you're going to show someone around, find that balance," and then there's the whole bit about pairing and delivering values. That's the whole sketch the diagrams and workout where you're both at and then get on the same page.

Then the third part is about feedback because I say that things are inevitably going to go wrong we're not 100% so you need to be able to talk about that on the both sides. But I also say that even if things have gone amazingly well, you should talk about it and say, "Why things have gone well?" because that can just help more of the same in future. That's when I touched on the whole nonviolent communication style of talking: How would you talk about feelings? How do you talk about what you need? How do you make requests to other people?

When you said, that's a perfect example of you're the host and the burden is on you in the moment to not flip out or to not just discount because you didn't like how it was said but you also need to have the space to give that feedback because there's a lot of burden on you to just keep excusing things because you're like, "I'm the host. They're the guest. I should excuse them," that's not going to end well because they'll be a lot of tension and one day, you might let go or one day, you might just ignore because you're fed up or you might shut the person down and that could get even worse so I talked about on how it's very important.

Even on a daily basis, just to have a quick check in on how is today for you, what should we change next time. That 'what should we change next time,' I felt frustrated when you said specific word here so it's not just casting a judgement or generalization because I need support or confidence or trust or whatever it is that you need. Next time, perhaps you could face it this way so that hasn't go, "I see why that came across this way." I talked about a better framework for giving and receiving feedback in a nonviolent way that will help these one-on-one interactions, pairing sessions, guest/host relationships get stronger each day.

REIN:  You said there were some things that you couldn't make fit in your talk. Was there anything else that you really wanted to talk about in the talk that didn't make it in?

NADIA:  When I was thinking about more on the code way, there was a time when -- this is a very specific. Do you all use Rails?

JACOB:  Yeah.

NADIA:  Typically, there's a standard way of writing an endpoint and we had to deliver a certain video format. We need to do a video format in m3u8 and I didn't realize you could just do '.m3u8' to change the endpoint. I'd written this note about how that was like if you go to a city and everyone's dressing the same, it's the one-time you went to the town center and you see everyone wearing like purple dresses so you assume, "I had wear purple dress." You don't know because you haven't been there for a long time. Actually, you don't have to wear a purple dress. You could wear red trousers. I talk about how's the hosts responsibility to always think about what you'll seeing and to highlight those cases like what's acceptable and what's not acceptable. Do you see what I mean? Because other people have all gotten into habit.

JACOB:  That's really cool. I really appreciate it when visiting somewhere and a host tells me, "This is where the tourists go," or, "When people are here for just a day, this is what they do. But what we like to do for fun on a day-to-day..." you know, for people who like live here, "we can do all these other things." It's like, "We don't all just go to the Statue of Liberty every single day." This is everything that's available to you in the city.

NADIA:  Yeah, similar to that kind of thing and I guess taking someone somewhere, I talked about three different ways that you could do if someone says, "I want to get somewhere," you can either just take them there and go back. You could give them a map and say, "Here you go. Go," or you could do something in between where you go with them but you point out things in a way and when you're coding, if you're pairing someone, you can just do so then they would really learn or you could just let them do it by themselves and the other things was like, "Do they need the balance?" Or you can pair with them but suggest different things along the way and explain why. I don't talk about it because it's not made into my talk but still, how that's probably a better... Oh, I do actually talked about that in my talk.

REIN:  One thing I wanted to ask you about are what are some specific things that hosts can do to make their codebases more welcoming? We talked a little bit about READMEs. What are the things that you can add to a README or how can you structure a README? When I think about making a guest in a city more hospitable, I think about maps and travel guides and things like that. What are the things in the codebase that are equivalent or offer the same value?

NADIA:  I actually made a little example code hospitable README. I think it's a gist. I don't know if I can find the link. Can you add that to the show notes? But in my talk, I have a little video clicking through [inaudible] this code hospitable README. I do start with installation, users contributing, the kind of normal things that you see in a codebase because it's useful. It's like opening, "Here are the keys to get into the front door." Then I have four more sections. One is history. It's the story, where did this idea come from, how did we get there, where we are now. Then I talked about approaches: What are the philosophies or the patents within this codebases? Is there a certain pattern you used to write your tests or is there a certain overall approach?

I give a specific example of the philosophy because in the Active Record README, there is a philosophy section and it talks about how it is actually an implementation of object-relational mapping and here's a link to a blog post by Martin Fowler and here are some of the general principles. It's like, "We have this thing called 'conventional reconfiguration,' or something else called the metadatabase." That's just the high level, "This is how we generally approach things in this codebase," and I thought that was really useful.

Then I have a reading material section, which might be external things like the Active Record README that lead to the Martin Fowler blog post or it might be internal things that you or someone else in a team has written about anything that's relevant to the codebase. Then I have the section called walkthrough. This is meant to be the equivalent of a guided walking tour and I thought it was the case of walking through a particular feature so I thought you could start with, "Here was the feature," and maybe it's a commit by commits sort of, "Here's the first test that we wrote. Here's how we then implemented it." It's just a short thing so that someone could say, "Now when I go to the [inaudible], I see this feature," or, "When I look in the issue tracker, I see this issue."

I can see how someone who has lived here for a while and did it and that can get me started by how I should approach it. I think that's particularly important even with open source, maybe you're contributing a feature to an open source codebase for the first time and you want your work to be accepted and merged in. It's a good way to understand, "Here's how people typically do it." We got to be careful that we don't end up saying, "This is how we do it here and you do it like this or good bye."

But it should be in the frame of mind of, "If you're stuck or if you're not sure, here's how we've done it." But I would hope that open source maintainers and even within your day-to-day job, people are always open to new approaches. It's very important that you keep that side of things as well. It's not just, didn't even need the guide. We don't do things like that here. At least not without a good explanation of why not. I've made all of this up, by the way. At the end of the talk, I do say that this is something that I've made up. The main thing is the frame of mind of the guest/host but you should take that and apply that to however you do things, if you need to make things better as opposed to, "This is how you do code hospitality."

REIN:  I feel like the reason that you've been so successful with this and been able to build up so much material around how to think about code hospitality is because it's such a good metaphor. I really think it is.

NADIA:  You love it.

REIN:  I do. I like it.

JAMEY:  I really love it too.

REIN:  I love everything that gets me to think about my relationships with other people in a different way and to sort of reexamine how I interact with people based on power dynamics or things like that. Host/guest is a form of power dynamic, in a way. I'm always on the market for cool metaphors analogies in that space and I think this is one of them so I'm really happy.

NADIA:  Yay! Thank you. I'm glad you all like it. Actually, that's one of the scary things. I got really excited by the idea initially when I first thought about it with Theo and then I sketched out so many ideas and then I wrote a proposal. Then when it got accepted and I was [inaudible] of the talk, it felt really silly to me. I thought everyone's going to bit say, "What is this silly analogy? It doesn't really mapped well." Or, "This is just really obvious. Why you even mentioning this?" I was really worried about it. It was actually after the first talk I did that the reception was great and then I did a few more and each time, people really could relate to it and that was really good.

But every time if someone else says, "Oh, I love this analogy. It makes sense," it makes me really happy because I remember when I went through that whole fear period of, "Ah, this is really silly. No one is going to get it. Everyone is going to think this is really obvious or just not worth exploring."

JACOB:  It's a super rich analogy. It really just invites you to think about so many things inside of a contained story.

NADIA:  Yeah.

JAMEY:  I think this is about the time in our show where we all take a couple of minutes to reflect on something that we talked about that really resonated with us. I think I'll go first. For me, I really liked the way that we talked about learning over the course of the show. I started thinking about it right at the beginning, actually when Nadia, you told a story about someone who had learned a little bit of a harsh lesson a little too late with this junior developer that left and how he reassessed how he had handled that situation because I had someone come to me after I talk I had once and said, "I found your talk really challenging to listen to," and I was like, "Oh, I don't know if that's a good thing to hear from someone," and they're like, "No," I think that's a really good sign that learning was occurring during it because it was challenging.

I already was in this mindset thinking about that person that you mentioned and having a challenging learning experience. But it also was on my mind a lot as we talked about the guest/host relationship. I really like this idea that when one person is training another person at work in tech or whatever they're doing, both of those people should be learning and both of those people are getting something out of it. To me, that really breaks down the power dynamic in ways that are really helpful. I have trouble, sometimes going into power dynamic relationships because I'm nervous. On either side, like here's someone who has a power dynamic over me and I'm nervous about how I'm going to make an impression, what they're going to think of me.

Also, if I'm going into a situation where I have a power dynamic over this person, do I deserve to be here? Maybe impostor syndrome stuff, am I going to actually be able to teach them anything? This idea that it doesn't matter which way that dynamic is going, either way both people should be learning, I think is a really healthy way to look at it. I think that's going to change the way I try to go into those situations in those dynamics.

JACOB:  I guess I have two threads that I wrote down. I was thinking about how there is a sort of reputation that New Yorkers are really rude. I'm not from New York but that was always something that troubled me a little bit when I would visit. Then someone who had been living there for a little bit told me, "You know, what it really is, is that most New Yorkers, unless they're incredibly privileged, they're surrounded by people all the time. There's just so many people. They probably have roommates, the streets are really crowded, every time they get into an elevator, there's a bunch of people they don't know. What it is this person said was, there's this kind of unspoken rule that has developed, which we're really going to just sort of keep to ourselves because the setting is important. That's how we're all going to get through our day. We're going to survive by just not being in everyone's business all the time as [inaudible].

When someone told me that, everything just clicked for me. It's like, "This isn't some kind of act of aggression. This is just how we survived." The fact that when that was made explicit, it really helps me feel a little bit more welcome in New York City whenever I visit now. The other thought I had, which Nadia just said was, I can just hand someone a subway map and say, "Here you go. This is how you get to everywhere you need to go," and objectively speaking, I could get to where I need to go.

But really the objective isn't to just get from Point A to Point B. As a visitor of a city, I would really love to know the story, I would really love to feel like this is my home, even if I'm only visiting for a weekend. When someone is able to walk me through a codebase and sort of tell me the story of what this codebase is, tell me its history, I'm going to feel a lot more at home when I'm going to start working on it. Hopefully, I can feel like a resident of that codebase eventually.

NADIA:  Great. Your point about New York got me thinking about London. I think it's exactly the same. There's this unspoken rule of we're busy, there's so much stuff going on, you just don't talk to people, especially on the Tube. It's like this unspoken rule of, "We just don't talk to one another and it's not that Londoners are unfriendly. We just don't do it." Your story about New York reminded me of that.

JACOB:  Yeah, head on.

REIN:  I was thinking about, Jacob what you just talked about New York and then I was thinking about sometimes when you invite people over for board games or something and then it starts getting a little late so you say you're tired to get them to leave but you're not really tired. What it is, is you are tired, you're just not physically tired. It's an emotional labor to be a host or a guest. I think it's important to acknowledge that and to be realistic about the amount of emotional labor you're willing to put into it. If it's something you can do great and if it's not something you can do, it may be worse for you to try it and be grumpy or feel bad afterwards.

NADIA:  Yeah, definitely. I definitely relate to the, "I'm tired now. I'm going to go to bed," and maybe I'm not. Maybe I'm going to read a book for another few hours or watch something but you are tired, just not in the way that you're communicating to other people.

I guess the main thing to takeaway and I hope people takeaway from this is this idea of the mindset and those safe spaces. When I say the mindset, I think coming off of Jamey's reflections and thinking about how do we advance learning, it's so key that those more experienced in the industry or those who are experts or managing don't see themselves as a teacher but rather, "I just happen to be more experienced. I've just been here longer but it doesn't mean I'm a teacher and I'm going to quiz the other person or give them challenges to help him get better." It's more of, "We're going to do this together and I'm not right." One of my favorite points in the talk is the whole assume you're both lost and you're trying to find each other than, "I'm in the right place. They need to get to me." I think that's a really valuable takeaway.

The other thing is that, I think all of the code hospitality stuff and I've even gone on and done another talk now about nonviolent communication, the thing at the nub of it is vulnerability and making safe spaces for people to be vulnerable because if you don't feel safe to be vulnerable, you therefore don't feel free to speak your mind and talk about your feelings. You therefore hold onto things, therefore their attentions, therefore your team can't be as productive, therefore likely to lead to messy, difficult to work on codebases. The foundation is it's safe for me to be vulnerable. It's safe for me to say I don't know. It's safe for me to ask questions.

I think with the host, it's meaningful that the host takes on a bit more responsibility to set the scene and to make it a safe space. One, by stating that this is a safe space, ask me any questions, don't be afraid to make mistakes, don't be afraid to fail but two, by leading by example, uncover your own flaws, talk about your own uncertainties, things that you don't know.

I always found it really valuable when I went to coding bootcamp and then started working at Pivotal and everyone was way better than me, of course. It was always great when the person I was working with said, "You know, I don't really know what's going on here." Just exposing their own vulnerabilities and I thought, "Okay, me too but you've been doing this five more years than me and you still don't know. Okay, I feel great." The key takeaways for me are a call to all of the senior developers out there working with junior developers, the junior developer is not wrong. They're just in a different place and to make it safe to be vulnerable and be vulnerable yourself.

REIN:  I love that. We do company demos weekly and last week, one of my demos was a commit that fixed a bug that I had just written, where I wrote the wrong variable name and the variable name that I wrote was actually the name of a method that caused an infinite recursive loop but the two variable names were off by three characters so my commit message was, "I literally can't believe I did this," and I just demoed that commit for the company. What I was trying to get out was like, "Look, it's okay if you make mistakes. You don't have to feel awful about it. Everyone's going to make mistakes."

NADIA:  That's great. It's reminding me of every time there's a failure, they stand up and clap or cheer about it. I don't know where that came from but that sort of thing, it makes failing fun and funny but also a learning experience.

REIN:  That reminds me of Karl Popper's approach to change, which is basically that you don't have to make the right decision all the time. You just have to be able to recover from bad decisions.

NADIA:  Yeah, I love that.

REIN:  That's how evolution works. Most of the decisions that evolution makes are terrible but a few of them are good. Well, Nadia this has been awesome. I'm so glad you came on the show and thank you for talking to us. Also Jacob, thank you for joining us as our special guest panelist. This has been great. Thanks everyone.