The Guest: A Guide To Code Hospitality
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 70 | |
| Number of Parts | 89 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/31567 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Multiplication signState of matterComputer animation
00:44
Message passing1 (number)Expected valueIdentity managementBitDifferent (Kate Ryan album)Computer animation
01:18
NumberMatching (graph theory)Charge carrierAreaBitComputer animationEngineering drawing
02:05
Data miningForceBookmark (World Wide Web)1 (number)Video gameNumberState of matterCASE <Informatik>Table
02:44
WordPhysical systemDecision theoryExecution unitPerspective (visual)Uniqueness quantificationLiquidGroup actionFrustrationMoment (mathematics)Data managementComputer animation
03:17
Machine codeRuby on RailsFood energyWhiteboardMilitary baseDemosceneComputer animation
04:07
Social classMachine codeMachine codeQuicksortGroup actionDomain nameSoftwareSoftware frameworkCollaborationismSoftware developerFeedbackSound effectComputer animation
04:52
Machine codeElectronic program guideDirection (geometry)Right angleProjective planeData management2 (number)1 (number)Formal languageHypermediaComputer animation
05:52
Form (programming)Complex (psychology)BitMultiplication signState of matterMachine codeGoodness of fitObject (grammar)Presentation of a groupStructural loadDecision theoryDependent and independent variablesNetwork topologyCognitionArithmetic meanVideo gameComputer animation
07:36
HypermediaPlanningWater vaporSpacetimeCASE <Informatik>Code refactoringMultiplication signMachine codeForm (programming)Wren, ChristopheroutputComputer animation
09:06
Standard deviationDependent and independent variablesMachine codeMultiplication signReading (process)Ocean currentSoftware testingMobile appProjective planeElectronic program guidePattern languagePresentation of a groupBitBlogOpen sourceObject-relational mappingMappingQuicksortLink (knot theory)Type theoryCoefficient of determinationRow (database)CASE <Informatik>Point (geometry)Service (economics)Lattice (order)MeasurementDatabase1 (number)Term (mathematics)Right angleTrailDescriptive statisticsInformation technology consultingWhiteboardArithmetic meanComputer animation
11:34
Mobile appReading (process)Multiplication signMachine codeComputer fileSpacetimeChemical equationIntegrated development environmentLattice (order)Decision theoryCASE <Informatik>Sound effectDisk read-and-write headState of matterExterior algebraComputer animation
13:33
Multiplication signVideo gameRight anglePersonal digital assistantDemosceneComputer-assisted translationContext awarenessQuicksortMachine codeState of matterObject (grammar)CASE <Informatik>Form (programming)Different (Kate Ryan album)Projective planeBuildingDiagramConnectivity (graph theory)Software testingComputer fileTwitterEndliche ModelltheorieSummierbarkeitMoment (mathematics)FamilyTheoryAxiom of choiceContent (media)Computer animation
15:30
Machine codeDifferent (Kate Ryan album)NeuroinformatikProjective planePoint (geometry)Key (cryptography)Domain nameLevel (video gaming)MappingIdentity managementSelectivity (electronic)Network topologyComputer animation
17:11
PlanningPower (physics)View (database)Arithmetic progressionMultiplication signPoint (geometry)Different (Kate Ryan album)Graph coloring
17:49
Order (biology)DiagramQuicksortData conversionMultiplication signDirection (geometry)Disk read-and-write headPoint (geometry)Machine codeCASE <Informatik>Term (mathematics)Software testingMachine codeEngineering drawing
19:17
Multiplication signData conversionTelecommunicationQuicksortOnline helpDiagramSurvival analysisPoint (geometry)Computer animation
20:03
QuicksortMultiplication signData conversionProcess (computing)Pattern languageInfotainmentGroup actionDecision theoryMassEngineering drawing
21:32
Data conversionImplementationMultiplication signCumulantWhiteboardProcess (computing)FeedbackCollaborationismProjective planeComputer animation
22:33
Confidence intervalMultiplication signData conversionSoftware testingPoint (geometry)WritingFile formatKeyboard shortcutState observerChainDivisorTerm (mathematics)Computer animation
24:23
Electronic program guideState observerFocus (optics)Machine codeGroup actionFeedbackNormal (geometry)Data conversionView (database)Multiplication signLevel (video gaming)Lattice (order)Office suiteLimit (category theory)Computer animation
25:09
Stress (mechanics)Integrated development environmentBoolean algebraMachine codeObject (grammar)Computer fileDiagramOrientation (vector space)Computer animation
25:37
DiagramPoint (geometry)Drill commandsIntegrated development environmentSet (mathematics)Level (video gaming)Computer animation
26:08
Software frameworkMultiplication signMachine codeSpacetimeFeedbackState observerArithmetic meanPerspective (visual)Computer animation
26:48
Point (geometry)DiagramFrame problemMachine codeTelecommunicationDivisorTerm (mathematics)Multiplication signData structureVirtual machineCode refactoringDecision theoryComputer animation
27:56
Field (computer science)NeuroinformatikTelecommunicationDiagram3 (number)Right angleDigital photographyMultiplication signEmailMachine codeLevel (video gaming)Software frameworkMoment (mathematics)QuicksortTwitterHookingSlide ruleBlogLogistic distributionRevision controlComputer animation
29:49
PlanningPressureProcess (computing)Software frameworkTelecommunicationData conversionTerm (mathematics)Goodness of fitSpacetimeDifferential (mechanical device)Type theoryDifferent (Kate Ryan album)Power (physics)BitMachine codeMereologyOnline helpMappingExecution unitForceQuicksortField (computer science)Graph coloringSocial classInternetworkingCASE <Informatik>Information technology consultingNegative numberFeedbackLecture/Conference
34:41
Computer animation
Transcript: English(auto-generated)
00:03
A question for all of you. When was the last time you had a guest? Anyone had someone stay with them recently?
00:21
Hands up. Anyone? What did you do to make their stay pleasant? Shout some stuff out. Clean the toilet. You cleaned the toilet, great. Anyone else? Made them breakfast. Made them breakfast, lovely. You guys are all lovely people. Gave them a tent, so they slept in your garden. Wonderful.
00:41
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,
01:00
but I'm thinking I might want to move to London. I want something different. Cool. 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.
01:22
I put together a little welcome pack. It had a tube map, a tourist book in London. And I put together a little sheet that had some tips and tricks for getting around London, like don't smile at anyone in public, and always carry an umbrella.
01:40
Even if it looks sunny and the weather person says there's a 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 out 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,
02:01
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 stay, I took her for dinner. And I got to ask her, what were your first impressions of London?
02:20
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 stay, eventually Alex did move to London. So that was pretty cool. I'm great at a host. OK, so that's story number one.
02:42
Story number two. It's like rails is my city, and I've lived here all of my life, said Thea to me one day. So Thea is my business partner. We run a company called Ignition Works. And at the moment, we're working on a system that helps businesses make sense of their unit economics
03:01
and decide on next best steps. And so we're working away, and I'm struggling to pick up this concept. And I am 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,
03:22
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 Thea 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.
03:42
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
04:00
bases in a way that's fun and where we continue being productive. And so what do 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,
04:21
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 guest versus host, 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.
04:40
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
05:02
and keep it up. And if one or more apply for me, you put up your second hand, nod your head, whatever. So you've recently started a new, oops, I'm back. That went too quickly. 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
05:21
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, anyone? 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, yes. You regularly collaborate with other people.
05:40
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. Oh, great. Right. So you're all in the right place. This is good. This is good. Okay. So with every visit, there's some form of preparation.
06:04
So 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 bases? Right, so just like a house, we know we should try and keep our code
06:21
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.
06:41
But also if you never have a guest, it's not great to be working with all 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. What does clean mean? Everyone has different ideas. So for Thea and I, some things that we like
07:01
to ask ourselves are, have we named things consistently? Or is there something in there that's gonna be a bit confusing? Do our objects have clear responsibilities? Like this 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?
07:21
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, and I just realized I've got a spelling error, has anyone else seen it? Right, got it, good. Okay, so you know, keep your code base in a state ready to receive unexpected guests.
07:41
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 fight of London in September 1666 and it destroyed seven eighths of a city. And architect Sir Christopher Wren submitted these plans for the rebuilding of London.
08:02
So you might not be able to see it here, but they're wider streets, they're more geometrically arranged, 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.
08:21
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
08:40
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. Does that convey respect to that person, for yourself or for your home, for your space?
09:00
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 to 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,
09:21
but give your host the benefit of the doubt that they are aware of these things and that they've tried. What type of guest are we talking about here? 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
09:41
or a letter or something like that? So this, if you go and 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,
10:01
even when you have been there to do the original onboarding. But what sort of code guests 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?
10:22
So think about the kind of current read me's that we see today. You know, they've got things like the 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?
10:42
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 know, think about the projects that you're currently working on now. Are there particular patterns or approaches that you use
11:02
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.
11:20
And there's some reading material, links to external and internal blog posts and also a walkthrough. 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
11:43
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,
12:00
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 it got me thinking, 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,
12:22
it is good to be super jealous with your time and attention. So you want your guests to be as self-sufficient as quickly possible, but they probably need 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 and workshop on that thing? You may think it's obvious,
12:41
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, it's the only thing you'd like to see
13:00
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. But what does that look like to your guests? You might have a question. So you can say, I'm putting on my headphones, but I am an interruptible.
13:21
And if it is the case that you're not interruptible, say so and say when you might be next free and gives them some alternative. 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.
13:40
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 off right 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 or getting used to a place. So how do you give tools of your code base?
14:03
So 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 all the objects linked to that. And then I had some really interesting tweets that kept mentioning this word, diagram.
14:23
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?
14:40
You might draw diagrams about the objects in 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 how does, 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
15:01
how we were gonna build certain things. And then you can string that narrative together. You can say, hey, here is 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
15:21
you might see, oh, that mark on the wall, that's from when the cat went crazy or something like that. 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 the visit, whether you're doing them with your guest or whether they're going at it alone.
15:42
So let's look at working with your guests 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 asked you to draw a map of Rails, like think in your head, what would it look like?
16:02
Would it look something like this? Maybe something like this? Keeps working. Or something like this. So notice how all of those maps look pretty different.
16:22
And they're all from people who have been programming in Rails for years. And the key point I'm trying to make here is 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.
16:43
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. 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.
17:02
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.
17:20
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.
17:41
And you won't progress unless you can start, unless you can see this and work this out. And it reminds me of this time that Alex was with me. And I was at home, over there, and she called me. 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.
18:02
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 and said, I've 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
18:22
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
18:42
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
19:01
like a role 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.
19:21
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. And 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 readme. These are like instantaneous communication scribbles
19:40
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 that we went to the other night.
20:02
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. So nothing had to meant it. 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
20:20
because it's a lot to take in. And so this time I thought, hey, I grabbed a map. I 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?
20:43
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 answers that you didn't consider because you do things the same way all the time.
21:01
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?
21:20
And then say, let's look at the pros and cons about these different methods. And 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.
21:41
Eventually, it's gonna be time to say goodbye. So whether that's your guest 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, 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
22:02
in their teams? And that's, you get together with your team once a week and you're able to reflect on the past week, 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
22:21
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.
22:41
And so a useful way to think about giving feedback, both positive and critical, is to frame it in terms of feelings. So what, 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
23:01
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
23:21
and you're drawing attention to the ways that your needs are not being met. So what are some examples? You honk 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.
23:40
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, yeah, 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,
24:02
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?
24:23
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.
24:41
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 views 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 guest in that way.
25:01
When you're first meeting your guest, 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,
25:21
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 tool through your code base. Don't just list the files and list 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 it. They help you illustrate and they help you think about what you're saying
25:42
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.
26:04
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.
26:21
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
26:41
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, woo! Okay, so what are you gonna need? You're gonna need a colleague. This can be someone new, 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.
27:01
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. 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?
27:22
What are 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 might be coding. Sit together, ideally work from the same machine
27:41
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 the thing. You've got three days to do it. And if you do it within three days, then you can win a special prize.
28:02
And I wanna hear all about it. So, tweet code hospitality. I wanna see diagrams, code 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.
28:20
And 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 100% of the time. So, we can answer all those sort of questions. If you want to dig more into the communication stuff
28:40
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 taught 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
29:02
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.
29:22
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, 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
29:41
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 was your stay? Thank you.
30:01
So, 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.
30:22
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 a bit sad, that's because you can work out,
30:40
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
31:01
how these reactions are, like where they're coming from. And so once you hear 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,
31:20
having trouble using non-violent 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 think about non-violent communication and obviously most people haven't read
31:41
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 non-violent communication. So, what I found really helpful is to try and ask questions of the other person that teases out that need that they have.
32:05
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
32:21
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.
32:44
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 bought into it, how do I convince them? And so one thing in the talk, I do start from this starting point of we're assuming that the host wants to be helpful.
33:01
So, 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,
33:22
you've got a nice clean house, you've got a nice clean code base. When they get there, they're happier, 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
33:41
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 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,
34:01
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, 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?
34:21
Like what do you need out of this job? And so then you can say, well, here's how we do things. Will that meet, 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.