Two's Complement - Pull Requests and Pair Programming, Part 1

Episode Date: September 15, 2021

Matt and Ben compare different methods of collaboration, and how they work for different personalities. Ben is not a psychologist, but plays one on this podcast. Matt gets very close to explaining what makes for a good pull request, and then doesn't.

I'm Matt Godbolt. And I'm Ben Rady. And this is Two's Compliment, a programming podcast. Hey, Ben. Hey, Matt. How are you doing? Good. So I've been thinking, I spend a bunch of time on open source projects,

reviewing code that people have submitted for like pull requests, right? And over the years of doing this, and I'm super lucky that 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 ticks about how to do a good or how to review a pull request well and then in my day job i spend a bunch of time writing code which i then submit to other people to pull request and you know you and i've talked a lot about how collaboration fits together and pull request is just one way of collaborating and so I figured 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 lots of different ways to do it for sure.

And I think we actually, the two of us, have a slight difference of preference when it comes to that. And we can maybe argue both sides. Maybe I'll argue your side, you argue my side. But there's lots of different ways to do it. And I think 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. Yeah. And it is very important to recognize that these are preferences, right? think we might have different positions and now i'm intrigued well i said preferences yeah and that's and it is 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 well 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, right. Whatever makes you happy. And 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 people. So my personal preference when I'm working as a software engineer is to do pair programming. Okay.

That's what I enjoy. That's what I and and that is what i think i am most effective at right because uh and the philosophy you know for me like we might ask what is pair programming i was gonna say i would think that most people would know this but i'm probably wrong about that i what is 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. 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 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 you're not like in each other's laps completely you are there is room to be as you say comfortable yes so that we're talking about at least a six-foot desk, maybe an eight-foot desk, somewhere in that range. So the two people can work at one computer comfortably for an extended period of time. 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 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 to all day because i know how other people feel about might be being close to me close proximity for so long. Yeah. 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 in 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 and 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 a while and i feel energized not that i don't enjoy being around people i just don't find it and there's a limit to right how yeah exactly it's a net tax on your your your soul to to be to give out to people to talk to spend time with people then you're like i just just need to have a little 10 minutes to myself.

Yeah. So 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-sp spaced breaks is an important part of this then um i can do 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 want to go into a little bit more detail about how this works because you mentioned it in a way that i hadn't

thought of it before you know and obviously I have pair programmed. You and I have pair programmed as well. But you mentioned it in the context of continuous code review, which is not really how I have perceived it before. But it's an interesting one. So perhaps we're going to dig into what you're – is there one driver, one backseat driver? Do you switch? Do you take every other key press? How does that work? Mm-hmm.

So the sort of the the basic technique so you remember in the episode oh have we posted one yet where we talk about shuhari we did talk about that one right yeah so shuhari so the shoe 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 in do you want to just for the sake of just quickly recap shuhari in case people don't want to squirrel back and listen to what it is so shuhari 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 shoe. That's the shoe. And then re 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 see all the patterns that are happening as we do all these various things. And then re 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? That's re. So, the, hey, Ben, how do I do pair programming? The shoe-level technique for how to get a sense of what true pair programming is like. The prescriptive way that it is ping pong. Yeah, ping pong. And 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 ping pong is taking it in turns, presumably, for some amount of time. How long would you say? Yeah, well, so the technique is this. And it's intimately tied in with test-driven development. You don't have to do test-driven development and pair programming, but the way that ping pong works

is with test-driven development. Got it. Is you have two people at a computer, like I said before, with a 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 they write a test for the other person. 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 that 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 like testing where you're like, well, I'm going to try and make it not work.

And then you're going to say, well, this is the minimal amount of code that will satisfy your test. Ha 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 uh it's very friendly friendly yeah that's the word i'm looking for yeah exactly so that's the that's the starting point is to literally have that and obviously as you say phrased around tdd as being like the way that you frame i should say framed around tdd

is the methodology yeah so then presumably after that you can migrate to less proscriptive ways of doing things. Exactly. And the intent of ping pong in a lot of ways is to give you a sense of some really important attributes of pair programming that it's easy to get lost, especially if you've never done it before, especially if you've never done it effectively. Like anytime you find yourself in a situation where you are watching another person code like sort of passively it's falling 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 or worse

and i know this has happened to me before is like someone leaves back in their chair and starts checking their emails on their phone yeah that's not that's that's clearly like you're not paying i'm going to start writing fairly 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 context loaded up in your head right how many times have you have all of the context loaded up in your head, right? How many times have you, have you been in the middle of a code review and you, you know, 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 because 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 statically looking at a set of code, it's 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 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 sort of like if you're leaning back in your chair with your phone you've switched

into code review mode and and that's and then you've lost that that ramp up yeah yeah yeah so so a way to simulate that is with ping pong because it forces you to do that and it forces you to experience that basically and 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 presumably as well as you you as a programmer who's used to pairing and your partner who is in the same situation, 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 whereupon 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. Because 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 got to learn how to do it you know from anecdote anecdotal evidence of my own right there 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 yeah you know when i'm accidentally copy 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 i'm testing for the person next

me to go like wait wait wait wait wait no no no you realize that you've got i mean yes of course i realize that i 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 like 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, yes, I do. You are watching. Yeah. So, right, there's a dynamic that comes from that.

Sorry, you were going to say. Oh, yeah. And as you progress through these things, you start doing stuff where you bend the rules a little bit. 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, is 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 kind of an important thing. And so 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 because 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. That just seemed like... You can kind of trigger the pair of you both back into that mode by just being conscious about it and doing it intentionally, right?

And it's not something you would necessarily do if you were doing it by yourself. You can do it by yourself. But sometimes it's really helpful just in the course of trying to understand, like, oh, I kind of lost it. What were we doing again? What was this?

And 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, let's go back and reread this thing, right? Right. So that can be a really sort of good balancing. But again, that's sort of something that you learn how to do effectively later 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 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 that kind of thing there and i have spent a bunch of time and i've learned so much from people who are substantially better than me at closure or unix scripting or c++ techniques or whatever by pairing with them. And so that, irrespective of the quality and the bug freeness and the sharing of ideas of how the systems work, that has been a huge boon to me. It's 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 are good for some things you know there's not going to be a clear winner from this right i think we're let's get our cards on the table here we're not 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, a sort of necessity for open source projects that I'm working on. So that's obviously somewhere where I've formed some opinions about the best way to do them, the best way to receive them and handle them and things like that.

But I've also realized that pretty much in all of my professional career, I have always thought about writing code that way once source control came into my life. And it's literally only now that I'm sort of ruminating when I used to, I have a vivid memory of speaking to a friend who I later founded a business with while we were both working in the games industry. He and I were working 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 you know 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 and 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 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 old 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're and if you actually go and look at any of my uh pls if i've ever sent you you'll probably find 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, I'm looking at it hopefully with a more impartial take two steps away mind.

And oftentimes I'll be like, oh yeah, I should probably break this into two pull requests, or this is 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 thing. And of course you can diff on your computer, but I actually find pushing to GitHub and using the GitHub tooling, which I'm familiar with 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 their their caches are warm if not actually boiling hot if you're sat next to them for the half an hour you know back and forth that you've been doing 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 is well described in the pull request itself so that you can give enough framing and enough context to the 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 are you even doing this that kind of meta meta question 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 you know 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 uh it can be very draining but and um it allows you to with a certain amount of creativity stack and nest sorry my dog is making a right of a racket behind me right now. No longer a puppy. Now, well, no longer a tiny puppy. Now he's just a menace making very loud noises, thumping around. But yeah, with a certain amount of forethought,

you can have a chain of changes, each of which can be reviewed. And you can sort of prevent yourself from being totally blocked by waiting for somebody. Because of course, that is the problem with pull requests is 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 my paul requesty type thing is it not the case that in some cases if you are pair programming with a particularly

um what's the what's the best word charismatic programmer they might be able to carry you along a path where you wouldn't normally go in the in not not, and not in a good way. Like, Hey, you know, I'm doing these, this isn't, this a clever thing. And, and it requires a certain amount of social dynamic and social capital to sort

of say, uh, actually clever closure programmer. Sorry. Again, my hand is making funny noises, but Hey, very clever closure program.

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 I mean that clever in the sort of pejorative sense. Yeah, absolutely. And so this gets back to pair programming being a skill like any other skill. And as a pair, you need to make sure that you're not – 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 pair is just sort of there, you know, hanging out, making weird noises. Like your dog. Like, yeah, exactly. He gets it. So 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 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 to back up about 12 steps right and that's obviously a huge opportunity in some cases to explain to someone and level them up to if you are the the the person who's lost left the other person behind so no let me sit down and explain 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 basic understanding of this dynamic is you might have people who are more junior and people who are more senior. But realistically,

and like as I've gone through this in my career, 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 they have yeah domain knowledge or experiences that you just have not 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 right 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. Right. Which is really what software is sort of all about. Yeah. Yeah, that's the problem, I suppose. With the pull request, right, you've seen the sausage after it's been made. And you're like, 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 wrapped uh yeah 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 although 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 who contain swear words and other various like things 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 saying look how lovely, look how lovely it is. Don't you appreciate it? Oh, I totally agree. Yeah. And I do that too. When I do pull requests, I always squash my commits because it's just, you know, part of me is a writer and I want to be kind to my readers, right? I'm trying to give them something that's easy to understand and easy to digest.

Not too big, you know, with good names. I've got to 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, lovingly

reverting someone's commit is sometimes something that is very important and useful to do. Right. We've discussed this before, yes. That's an important thing to be useful to do right um discussed this before yes 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 yeah the thing you merged in had a problem we reverted it you can fix it tomorrow yes no need to worry right that's that's the outcome that you want so yeah squishing 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 100 of favor well as again i just want to make sort of clear 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 because 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 that's sort of brownie and motioned my 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 for folks to see although that might just be me looking for an excuse to be 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 yeah if you didn't have the i mean this is it's a poor substitute for being sat with somebody while they're doing the work but it maybe gives something i i've 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 so maybe

they don't but i'm just kidding myself i think that would kind of naturally show up in the git blame history but maybe that's true i don't know yeah it's a good point like here are the things we tried here and the last one was the one that sort of we thought it worked yeah we gave up right we gave 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 parents

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 and totally different and i need i need to not have you watch me right this is like you know don't look at me and at the end of the 15 minutes i may return around to you say you are absolutely right there is no good way of doing this or i may better say hey good news how about this right and so there's a fine line between us two and so how do you deal with in your in your uh mind those sort 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 well may just stop you both so i think this just comes down to how individuals work because 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 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 right it helps me think about problems in a better way i mean we've all and so the nodding duck that nodding duck is real um yeah yeah i i remember when i was like in my

late teens i would refer to it as as explaining it to my mom because my mom 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'd get coffee cups out and use the handles to point as like the link list next pointer. And I'd be trying to explain to her why my link list wasn't working. And by the time you finished explaining, of course, you've got the answer.

Like everyone knows. Of course, yes. And obviously that, you're absolutely right, it does engage a different part of 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 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? Or if you did do that, you better have a really clear hiring policy.

That's like, look, this is how we do things. If you don't like it. And it's weird. So like, you should be aware of what you're signing up for here. But like, I would never propose that as like a company wide policy. It's just something that like, you know,

if people want to collaborate that way, they can. 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'll happen to whatever extent it happens. And for you individually, I would never say that, 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, you know, different tolerances for how long and on what kinds of problems and all that other stuff i think right completely fine yeah yeah 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. 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 idea. Part two? A part two. Let's try that on. Let's try a part two. All right.

Well, then this is the end of part one. Fantastic. I look forward to talking to you about this next time. All right. You've been listening to Two's Compliment, a programming podcast by Ben Rady and Matt Godwald. Find the show transcript and notes at twoscompliment.org. Contact us on Twitter at twoscp.

That's at T-W-O-S-C-P. Theme music by Inverse Phase.