Hey Ben.
Hey Matt.
How are you doing?
Good!
So I've been thinking, I spend a bunch of time on open source projects, um, reviewing code that people have submitted, uh, by like pull requests, right. And, um, over the years of doing this, and I'm super lucky that, uh, I get so many people sending me pull requests, right? They want to help out with the project, which is fantastic. Um, I've started to sort of pick up some tips and tricks about how to do a good or how to review a pull request well. And, and in my day job, I spent a bunch of time writing code, which I then submit to other people to pull requests. And, you know, you and I have talked a lot about how collaboration fits together and pull requests is just one way of collaborating. And so let's just talk about how we like to do collaboration and the tradeoffs that there are about the different approaches.
Yeah, that sounds great. There's, there's lots of different ways to do it for sure. And, uh, you know, I think we, we actually, the two of us have a slight difference of preference when it comes to that. But, um, and we can maybe, maybe argue both sides. Maybe I'll argue your side, you argue my side, but, um, there's, there's lots of different ways to do it. And I think it, it, it is a really interesting topic. So yeah, that sounds great. I love that plan.
Fantastic. So what is your position then? Because you said you think we might have different positions and now I'm intrigued.
Well, I said preferences and that's it. It's very important to recognize that these are preferences, right? Because it's basically like interacting with other people. How do you like to interact with people? How do you like to interact with people? It depends on the people, right? Some people like to go to the beach and hang out. Some people like to get coffee together. Some people like to go skydiving together. I don't know, it's whatever you want to do. Right. Whatever makes you happy. And it's, it's, you know, we don't have quite that many options when it comes to reviewing source code that other human beings have written, but we have a few options and they are, I think, very dependent on the people. So my personal preference, when I'm working as a software engineer is to do pair programming. That's what I enjoy. That's what I, and that is what I think I am most effective at.
Right. Because, uh, and the philosophy, you know, for maybe we'll like we might ask what is pair programming? I would think that most people would know this, but I'm probably wrong about that. I, what is pair programming? So pair programming is the idea that it's like, oh, code reviews lead to better code. So let's just do them all the time, but without the bad parts. Um, and so when I do pair programming, the way that I do it is I have a special computer set up with two monitors that are mirroring the same display. So you see the same thing on both monitors, uh, two keyboards, two mice, all attached to the same computer and a big enough desk to where two people can sit very comfortably at that desk, usually with like, you know, their notes or their a drink or whatever other desk accoutrement you might want,
But not, you know, like in each other's laps completely, there is room to be, as you say, comfortable. Yeah. Yes. So
We're talking about at least a six foot desk, maybe an eight foot desk, somewhere in that range. Um, so the two people can work at one computer comfortably for an extended period of time. Uh, when I do this, I tend to do it, if so I have worked in jobs where I have worked this way all day, every day for basically the entirety of the job for years on end. Right. So I've done a lot of this, and, uh, I have found in my experience doing that, that you really can't do it. I can't do it other people might be different. I can't really do it for more than about six hours a day. That's my sort of sustainable pace for pair programming.
So, six hours out of a regular day. So, you know, three quarters of the day effectively. So you need at least a couple of hours of not pairing in order to presumably not strangle the person you've been sat next all day, because I know how other people feel about might be being close to me, quite close proximity for so long.
Yeah. I mean, it can be like, I am, you know, people talk about, and I don't know how much of a basis this has an actual, like psychology, but people talk about introverts and extroverts and introverts being, you know, sort of recharged by being alone and extroverts being recharged by being with other people. And I actually do kind of think of myself as a person that leans more introvert in that, like, if I'm around too many people for too long, I feel drained. Right. And I just need to go and sort of relax and be by myself for awhile. And I feel energized. Not that I don't enjoy being around people, I just don't find it energizing.
There's a limit to how, yeah, exactly. It's a net tax on your, your, your soul to, to do, to be, to give out to people, to talk, to spend time with people. Then you're like, I just need to have a little 10 minutes to myself.
Yeah. Yeah. So, so I, I have found that that sort of six hour time limit is, you know, in the context of pair programming, which is sort of a very specific way of working if I do this for six hours with breaks in between. Right. You know, well, well, spaced breaks is an important part of this. Then, um, I can do it for about six hours and I can do that in perpetuity. I can do that for years.
Right. That's a sustainable pace of, of pair programming. Right. So do you wanna go into a little bit more detail about how this works? Cause you mentioned it in the a in a way that I hadn't thought of it before, you know, and obviously I have pair programmed, you and I have paid programmed as well. Um, but you mentioned in the context of like continuous code review, which is not really how I have perceived it before, but it's an interesting one. So perhaps we want to dig into like, what your, I mean, is there like one driver, one backseat driver? Do you switch? Do you take it every other key press? How does that work?
So the, the sort of the, the basic technique. So you remember in the episode, Ooh, how we post this one yet where we talk about Shu-Ha-Ri we did talk about that one, right? Yeah. So Shu-Ha-Ri, so the Shu level technique for pair programming is something that's called ping-pong, right. Oh, the way ping-pong works, and ping-pong is intimately tied into
For the sake of just quickly recap Shu-Ha-Ri in case people don't want to squirrel back and listen to what it is.
So Shu-Ha-Ri is a, uh, technique that I use when I'm mentoring mentors. So teaching people how to teach people. And if you're trying to teach people something, you have a three-phase process where you say, follow these steps. Exactly. And you will get this result. Exactly. If you follow these steps and then the Re.
That's the Shu,
That's the Shu. And then Ri(sic) is, oh, when we do these things, we start to see patterns emerge, and then we can give names to the patterns and we can talk about things in terms of patterns. And we can, we can see all the patterns that are happening as we do all these various things. And then Ri is when you sort of transcend that and you just focus on outcomes. Like these are the outcomes that I want to occur. I know how to make that happen because of all of the things that I've learned. And yes, maybe I think of certain things in terms of patterns, but really move beyond that. Right. So the, Hey, how Ben, how do I do pair programming the Shu level technique for how to get a sense of what true
The prescriptive way is ping pong.
Yeah. Ping pong. And so, and this, this, isn't what I, when I'm working for years on end doing six hours a day of pair programming, I'm not doing ping-pong for six hours a day. Right.
But, but ping pong is taking it in turns, presumably for some amount of time, how long would you say,
Well, so there's a, there's a, the, the technique is this. So, and it's intimately tied in with test driven development. You don't have to do pair test driven development with pair programming, but the way that ping pong works is with test driven development is you have two people at a computer. Like I said before, with the setup, one of them writes the smallest failing test that they think will drive some interesting or useful behavior out of the system. And then the other person writes the smallest amount of code that they can think of to make that test pass, and then that, and then they write a test for the other person. So, right. So it's not that one person is writing tests and one person is writing code. That's not how it works. It's one person writes a test, the other person writes code, and then a test, and then the other person writes code and then a test. And you're trying to write the smallest amount of code that you can to achieve that goal. Right?
Makes sense. And it sort of, I can see how that drives out. Um, a certain amount of adversarial is not the right word here, but you know, like there's a certain, um, like testing where you're like, well, I'm going to try and make it not work. And then you've got to say, well, this is the minimum amount of code that will satisfy your tests. Ha. But like, clearly it's also broken. So you're immediately going to write the test that says well I'll show you how your square root function doesn't work for negative numbers. It doesn't throw an exception. Well, you didn't test that. And so there's kind of a nice collaboration there, but it's, hopefully I presume.
it's very friendly,
Friendly. Yeah. That's the word I'm looking for. Exactly. So that's the, that's, that's that's the starting point is to literally have that obviously, as you say, phrased around TDD as being like the way that you frame, I should say, framed around TDD as the, as the methodology. So then presumably after that, you can migrate to less prescriptive ways of doing things.
Exactly. And, and the, the intent of ping pong in a lot of ways is to give you a sense of some really important attributes of pair programming, um, that it's easy to get lost, especially if you've never done it before, especially if you've never done it effectively. Like any time you find yourself in a situation where you are watching another person code, like sort of passively, it's fallen apart. That's not how it's supposed to work. The intent of pair programming is not to just, I sit here and I watch you code for six hours.
I know this has happened to me before, as though someone leaves back in the chair and starts checking their emails and their phones, that's clearly like, you're not paying, I'm going to start writing, checked out. Yes. You are a smelly person in comments in my code and see if they notice it. Right.
Right, right, right. Um, what you want is that same mentality that you have in a code review, but you have a huge benefit. And the huge benefit is that you have all of the contexts loaded up in your head, right? Like how many times have you, have you been in the middle of a code review and you are looking at a piece of code and you're like, why was this code written? Where, where did this come from? Where like, like you have no sense of the process of creation and like, okay, well I made this function cause I had this other function that needed to call a function that looked like this function. And that function is tied to this thing. And like all of that context when you're in you're statically, looking at a set of code is like,
It's very hard to find, yeah.
You'd have to, it's almost like a detective trying to tease it apart. Whereas when you're pair programming, it's all loaded up in your head. Just like it was for the original programmer who wrote the code, which by the way is you because you're trading off with somebody else. Right. So one person has that sort of review mindset and the other person has the coding mindset and you're switching off back and forth enough to where you never lose it. Right. Again, it's a sort of like if you're leaning back in your chair with your phone, you've switched into code review mode and that's, and then
You've lost that, that ramp up. Yeah. Yeah. So, so
A way to simulate that is with ping-pong. Cause it forces you to do that and then forces you to experience that basically. Then you're like, oh yeah, okay. Now I kind of get this, but that's not how you actually do pair programming when you're doing it for real,
Right. There's a much more organic, presumably as well as you, as a programmer, who's used to pairing and your partner who is in the same situation or, and presumably your partner may slip around depending on your team dynamics and things like that. But within a particular partnership of you and another person who have paired before, there's a familiarity with the process where upon you can start dropping the ping pong. You're like, well, I'm just going to write three tests and then you can write the things, cause these are all related. And we both know that we look each other in the eye or whatever.
Right, right, right. It's a skill like any other skill, you gotta learn how to do it.
You know, from anecdote anecdotal evidence of my own. Right. Or are definitely people that I pair program with where we have learned the kind of trigger responses that we all respond to for the best. Right. So when I'm accidentally copied and I've got air quotes or an accidentally copy pasting some other function and failing to rename the thing that clearly is what I wanted to do. I'm T I'm testing for the person next to me to go like, wait, wait, wait, wait, wait, wait, wait. No, no, no. You realize that you've got a yes, of course. I realized that I'm just want to see if you're paying attention anymore. And with financial service, you know, like buying and selling and the quantities of the things you do, you'd copy it and go buy equals this and buy equals that. And they're like waiting for them to say, don't you mean sell? You're like, yes, yes. You are what you are watching. Yeah. So, right. There's a dynamic that comes from, from that. Sorry, you were going to say,
Oh yeah. And it's like, and as you progress through these things, you start doing stuff. Um, where you, you bend the rules a little bit, like one of the advantages actually of a code review is that you get a more independent opinion, a more formal code review or a pull request, or other things like this, as you get a little bit more independent opinion of what the code is and what it's doing, and you get somebody that hasn't been there for the whole context and like, can I still understand this code without all the context? Right? Like that's, that's kind of an important thing. And so as you get a little bit more mature with this technique, you're able to kind of like intentionally bring that mindset back, right. Where you say like, okay, we were working on this little bit of code. I want to switch back over to this other thing that we were doing 20 minutes ago. Cause I forgot how it works. And if I don't understand it, then we did it wrong, we need to go back and do it again.
I was going to ask about that.
You can kind of trigger the pair of you both back into that mode, um, by, by just being conscious about it and in doing it intentionally. Right. And, and it's not something that you would necessarily do if you were doing it by yourself, you can do it by yourself. But sometimes it's, it's really helpful just in the course of like trying to understand like, oh, I kinda lost it. Like what w what were we doing again? Like, what was this? And your, your pair can either sort of bring you back up to speed, or you can kind of do this thing where it's like, no, no, no, no, let's go back and reread this thing. Right. Right. So, so that can be a really, uh, sort of, um, good balancing it. But again, that's sort of something that you learn how to do effectively
Further down the road. Right? Yeah. So that's interesting because that actually is something that I do or something similar to that approach is what I do when I'm submitting a pull request. So obviously that's a very different way and perhaps, if we talk a little bit about my, I wouldn't say it's my favorite thing, but, you know, naturally that's the way that I work. I, as we've said, if I've paid programmed a fair amount, um, I don't know if I could do six hours sustained. I could probably do four hours. Uh, you know, I haven't, I'm just like finger in the air for, for that kind of thing now. And I have spent a bunch of times, and I've learned so much from people who are substantially better than me at Clojure or Unix scripting, or C++ techniques or whatever, by pairing with them.
And so that irrespective of the, and the bug freeness and the sharing of, uh, of ideas of, of, of like how the systems work, that has been a huge boon to me, has been like spending that quality time with a much more talented developer and going, oh, wow. I never even thought about that. That's amazing. So, you know, I think we're both going to end up with the, you know, there are ways and means where, you know, pull requests. It's good for some things, you know, there's not going to be clear winner from this. Right. I think let's get our cards on the table here. We don't go. There's not going to be a one answer at the end of this, this episode, but pull requests for me have been, first of all, I sort of necessity for open source projects that I'm working on.
So that's obviously. Uh, somewhere where I I've formed some opinions about the best way to do them or best way to receive them and handle them and see like that. But I've also realized that it pretty much in all of my professional career, I have always thought about writing code that way once source control came into, into my life. And it's literally really only now that I've been sort of ruminating when I used to, I have a vivid memory of speaking to a friend who I later founded a business with, um, while we were both working in the games industry, he and I, um, um, were working come together on something. And I said, well, how did you choose this commit message that you're writing is, oh, I always have a, like a notepad open. And I diff my code from beginning to end before I check it in.
This is before any kind of pull request or anything. So it's literally just wild west check your code in, and then he would write a summary of what that change was about. And then very often he said, while doing it, he would discover things like, oh, I hadn't done this thing properly. Or I forgot to take this line out, or this has got some debug code or whatever. And then at the end of it, all, you've kind of reviewed your own code as it were while and while doing so generated the commit message. And then you check that in. And I thought, that sounds great. And I adopted that methodology myself. And basically I haven't looked back. That has been how I've done it since it's always been that. And so nowadays what I tend to do is I make a branch and, you know, I'm committing code all the time and I'm making changes and I'm committing them and locally I'll push a branch up and make sure the CI gives me the all clear as well.
So that's kind of like my secondary, uh, thing. And then I will go and I will create the pull request and I will read it myself. And you'll know if you actually go and look at any of my, uh, uh, PRs, if I've ever sent you, you'll probably find the, the last commit before I sent it to you was self review. I will always go over the code myself and try and pretend to be the reviewer, because I've done enough of the reviews. I'm looking for the kind of telltale signs that the, the end result of all of my commits and changes that constitute, this one atomic change that I would like people to review. Um, you know, I'm looking at it hopefully with a more impartial, take two steps away, uh, mind, and oftentimes, cause I'll be like, oh yeah, I should probably break this into two pull requests.
Or this has not been well explained or I haven't got a test for that. Whoops, let me go and write a test for that. Or I haven't thought about this type of thing. It definitely is a very different, um, thing and of you can diff on your computer, but I actually find pushing to github and using the github tooling, which I'm familiar with. Right. You know, scrolling through means that I can't edit the code. I'm not in my editor. It doesn't look the way I'm expecting. I've actually flipped over into that review mindset. And I find that helpful. So that is an interesting observation I've found in myself is that one looks at it differently. So the overall sense though, is yes, you are expecting somebody to come out of nowhere potentially, and look at your code. Whereas obviously they're, their caches are warm if not actually boiling hot, if you're sat next to them for the half an hour back and forth that you've been doing.
Um, so it is on the pull request submitter, I think, to make sure that your pull request is as small as can meaningfully be done, um, is well-described in the pull request itself so that you can give enough framing and enough context to the person who's reviewing your code, that they hopefully won't have to come back to you and ask, Hey, what about that thing? Why, why are you even doing this meta meta question? Um, then obviously you want the tests to be green. And hopefully again, it minimal. And to your point, actually, what I find when I'm reviewing other people's code, um, is very often though, you'll get to that bit where you can see the diff and you just wish you could see a bit more because you've lost enough of the context. You know, I can't go to definition of that thing.
Why is it you're doing that kind of stuff? So that's definitely an issue. I think that you suffer from, but the benefit is it is asynchronous. It's not as draining, uh, on a sort of social level as it is to be pairing with somebody even very good pals, you know, already good pals. Sure. It can be very draining, but, and, um, it allows you to, with a certain amount of creativity stack and nest check, sorry, my dog is making a great of a racket behind me right now, no longer a puppy now. Well, no longer a tiny puppy. Now he's just, uh, a menace making very loud noises, bumping around. But yeah, the, um, uh, you know, with a certain amount of forethought, you can have a chain of changes each of which can be reviewed and sort of prevent yourself from being totally blocked by waiting for somebody.
Because of course, that is the problem with pull requests as you submit them. And now you're like, oh, now what, you better have more than one thread of execution going. Whereas in a pair, of course, that's, you're getting that approval constantly and continuously. And that's a fantastic, uh, side effect. But I, yeah, I, I wonder though, so here's something to put to you, right? So I've kind of described my pull requesty type thing. Is it not the case that in some cases, if you are pair programming with the particularly, um, what's the word, that's the best word, charismatic programmer. They might be able to carry you along a path where you wouldn't normally go in and not, and not in a good way. Like, Hey, you know, I'm doing these, this isn't this a clever thing. And it requires a certain amount of social dynamic and social capital to sort of say, ah, actually clever Clojure programmer. Sorry, I get my hound is making funny noises, but Hey, it's very clever Clojure programmer. I don't really understand this. And I don't know whether it's just me being not as smart as I need to be. Or are you being overly clever and clever in the sort of pejorative sense?
Yep. Yeah, absolutely. And so this goes back to pair programming, being a skill, like any other skill and as a, as a pair, you need to make sure that you're not, uh, usually the phrase we use for this is chewy seating, someone. As in Chewbacca from Star Wars, right. Where you're Han solo and your, your pair is just sort of there, you know, hanging out, making weird noises.
Like my dog is behind me!
Like your dog, like yeah, exactly. Um, so that's, that's a skill that you need to learn how to recognize in yourself when you're doing that to someone you need to be able to recognize when in other people, when you sort of look over and you're like, oh yeah, he is completely lost right now. I, I have really screwed this up. I need back up about 12, 12 steps.
Right. And that's obviously a huge opportunity in some cases to explain to someone and level them up too, if you are the, the, the person who's left the other person behind. So no, let me sit down and explain it. Let's go to a whiteboard. Let's, let's go through what this is doing and get the buy-in that I need from you. But you need to recognize it in yourself.
Yes, you do. Yes, you do. And it's, you know, a sort of, um, basic understanding of this dynamic is you might have people who are more junior, junior, and people were more senior, but realistically, and like, as I've gone through this in my career, um, it's never that simple, you can learn from everyone. I've, I've learned from people with 10, 20 years less experience than me because they look at problems in a different way, or they ask questions that I wouldn't think to ask, or they just know things that I don't know.
Yeah. Yeah. Domain knowledge or experiences that you just come across. I mean, yeah.
Or just anything. I mean, it doesn't even necessarily have to do with programming. And I actually think this is one of the great benefits of pair programming is that you learn all kinds of things about how your computer works, that you didn't know bash tricks, little utilities, commands, diagnostic tools and techniques that you would just never even, like, that's never going to show up in a code review. Right. Like it's just the kind of thing where it's like, you learn skills about how to solve problems. Um, which is really what software is all about. Yeah.
Yeah. That's the problem, I suppose, with, with the pull requests, right. You've seen the sausage after it's been made and you know, this is a mighty fine sausage that looks great. And you've got no idea what really, how the process, how, how painful or otherwise it was to come to this beautiful thing. Now that sort of appeals to me as a character flaw where I like to present someone with a beautifully gift wrap, uh, as if it was came out of the firmament. But I've actually one of the sort of big things I've made is, is, um, certainly for open source projects is to never like squash my history because I'm going to present to you this beautiful artifact that I've made. If you open up and look at all the individual changes, you'll see any number of commit messages, that contain, swear words, and other various things. I'm like, this is not, this was a misstep. I made a mistake. So there's a bit of both in there, but I do like the idea of presenting someone to say, look, look how lovely it is.
Oh, I totally agree. Yeah. And I do that too. When I, when I do pull requests, I always squash my commits. Um, because it's just, you know, cause you know, part of me is a writer and I want to be kind to my readers. Right. Like, uh, I, I'm trying to give them something that's easy to understand and easy to digest, uh, not too big, you know, with good work, good names. I got to give, give, give, give things good names. And if you have all your sort of intermediate commits mixed in there, I think plus it makes it harder to roll back. I mean, I think that, you know, again, uh, uh, lovingly lovingly reverting someone's, uh, commit is sometimes something that is, uh, very important and useful to do. Right. Um,
We've discussed this before that's an important thing to be able to do. So you want to be kind to those coming after you and say, well, if I have, it seems very unlikely, but if I have made a mistake, I want to make it easy for you to be able to give me that, that evening's piece of not being paged at four in the morning.
Right. Right. Yeah. The thing you merged in had a problem, we reverted it. You can fix it tomorrow. No need to worry. Right. That's that's the outcome that you want. So yeah. Squashing, the commits, making them creating that sort of nice clean, you know, here, reviewer please. This is, this is another thing that I want to present to you. I think I'm a hundred percent in favor. Well,
Again, I just want to make sort of clear that that that's how I work within repos individually, but as a, as an open-source expositionary expository, whatever that word is. I don't mind people seeing the bits of the sausage. Cause I mean, it would be me, that'd be reverting it. And I don't want to give the impression that I'm not an incompetent fool that's just about the sort of Brownian motion by way to a somewhat decent solution. Right. That's more than the honest answer. Right. So I don't mind having that bit there. And I think that's an important thing for folks to see although that might just be me looking for an excuse.
Well, it is, I mean, it is different when you're creating something for someone else to review as a complete thing, versus, you know, creating commits that sort of show a history of some, you know,
A process. If you didn't have the, I mean, this is, it's a, it's a poor substitute for being sat with somebody while they're doing the work, but it maybe gives something. I have honestly, never actually had any feedback as to the result of whether people see that and kind of go, oh, that's cool. I see how you got to the place, but maybe they don't, but I'm just kidding myself.
I think that would kind of naturally show up and they get blame history, but maybe that's true. I don't know. Yeah. That's a good point. The, here are the things we tried here and the last one was the one that sort of. We thought it worked. We gave up, basically, is what happened. We just gave up. Yeah,
No, that's pretty cool. So then, you know, there's a, there are, there are benefits to both approaches. I definitely lean, I mean, that's not true. I was gonna say I lean towards pull request based development. I think at the very, at the moment I am currently going through a set of processes where I am trying to find a more creative solution to problems. Right. I have a whole bunch of things that are essentially very open-ended and I'm finding it useful to have the time to think by myself, like a couple of hours of staring into the void kind of level thing. That's not honestly to say that talking it through with another human wouldn't make it better. It'd be just different. But I have had experiences before now where I'm trying to go through that process. And eventually I have to turn around to my pair, say, can you actually just look at your phone for 15 minutes because I really just need to try this out. And I don't know where it's going and I, I kind of don't need the continuous, um, feedback because I feel like I need the space to make a, you know, try something stupid and totally different. And I need, I need to not have you watch me. Right. This is like, don't look at me! Lalalala.
And at the end of the 15 minutes, I may return around you and say, you are absolutely right. There is no good way of doing this, or I'm able to say, Hey, good news, how about this? Right? And so there's a fine line between those two. So how do you deal with in your, in your mind, those sorts of creativity, things where you're searching of a huge problem space and, you know, analysis paralysis can be a problem and talking it through with someone else will, may just stop you both.
So I think this just comes down to how individuals work. Cause I, for me, being able to explore a problem like that while talking to somebody is actually helpful, right? Like I very rarely, I mean, not never, but I, I very rarely find myself in a situation where I just want to shut out the whole world and, and, you know, focus on a problem all by myself. I always find very, I very commonly find that just verbalizing it engages a different part of my brain, which is good. Right. It helps me think about problems in a better way.
The nodding docket, the nod nodding duck is real. Um, I mean, I, I remember when I was like, in my late teens, I would refer to it as, as explaining it to my mum because my mum would come upstairs and be going, what are you doing up in your room all this time? And I'd be like, well, I've got a problem and I'll get coffee cups out and use their handles to point as like the link list next pointer. And I'll be trying to explain to her why my linked list wasn't working. And by the time you finished explaining, of course, you've got the answer that everyone knows. And obviously that you're absolutely right. It does engage a different part of your, your, your brain. But I think my concern is that sometimes you don't need that part of your brain. You actually need the other part of your brain, the quiet part of your brain to do some work. So
I think everyone's just going to have their own differences there. And I would never propose pair programming as a like company-wide mandate, right. Or if you did do that, you better have a really clear hiring policy
Look like this is how we do things.
This is how we do it. And it's weird. So like, you should be aware of what you're signing up for here. So like, I would never propose that as like a company-wide policy. It's just something that like, you know, if, if people want to collaborate that way they can and, and, and, you know, creating an environment where that's possible is the real decision that you're making. Like, are we going to set things up so that that's possible. Yes. Okay. Well then it will happen to whatever extent happens and for you individually, I would never say that. No, no, no, no. Your way of doing it is wrong because you know, it's not this it's like, it's whatever works for you and, and you know, different tolerances for how long and on what kinds of problems and all that other stuff I think is completely fine. Um, yeah. So this is, this podcast has been going on for a little while and we have way more to talk about. We haven't talked about actually what you think makes for a good pull request.
Oh, that's true.
That's like, that's a really important topic and we should talk about that. Um, and there's other stuff that we could talk about. There's a technique called mob programming, which is similar to pair programming, which I have not done nearly as much as pair programming, but that's probably something else. So maybe we should talk about that in a second episode of this?
That sounds like a great idea.
Part two?
A part two, let's try that on. Let's try a part two.
Well, then this is the end of part one. Fantastic.
I'll look forward to talking to you about this next time.
All right.