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

Episode Date: October 1, 2021

Hey Ben, when are you going to release the second part of that podcast on pull requests and pair programming? I've really been looking forward to it. Oh, I don't know. I need to come up with a witty description first. Hopefully some time this week.

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, buddy? Great. So last time, you and I were talking about the various ways that

we collaborate with other people, be it through pull requests, or pair programming, or a bit of each. And we kind of finished on a note where we were describing that, you know, different things work for different folks. And there's no good one true answer. But right at the end, just as we were running out of time, you posed a question to me of like, what makes a good pull request? So maybe we should start there. So what makes a good pull request?

I'm glad you asked. He said knowingly. I've been waiting for a month to hear the answer to this because that's when these podcasts are going to come out. Left us on tenterhooks the whole time, everyone thinking what makes a good pull request. So actually, there's sort of two sides to this, I think. There's what makes a good pull request and there is what makes a good review. And that can change depending on the person who submitted and their interaction with the project owner or the reviewer or however that fits. So the first thing about a good pull request for me is it has to have a good explanation as to the why.

Sometimes, I think we talked about this a little bit last time, that sometimes you can't infer the why from just the diff the diffs like you know you change the number 16 to 17 and all the tests have been updated and you kind of say like yeah we we updated the 16 to the 17 and all the tests now pass you're like yeah but why why why was the 16 or 17 what was wrong with 16 tell me something about this now obviously there is a world in which if it's not too obvious from the code alone, then that pull request explanation isn't often tracked as well as the individual changes that you've committed. Most source tracking systems work at the level of the commits that you do do be it git or any of the other sort of source control packaging packages um they're not necessarily going to have a link back to the original pull request you know the metadata is stored out of line certainly in github right so if it's not too obvious then maybe you only need to make a change to the way that the code is written to say hey yeah this was should never be 16 um so anyway a clear explanation as to the why of the change and hopefully for an open source

project and maybe even for some internal projects links to the bugs or issues that this is related to or even closes which is a wonderful thing you can do is to sort of say hey this closes that knowing that when it gets merged it will will automatically close the bug, which is a cool feature. And then it should be relatively small, right? If you can possibly make it the smallest useful change, then you're doing your reviewer a favor, right? You are necessarily imposing upon your reviewer some time. You're stealing time from them, hopefully to give them something good.

You know, in an open source project, you're hoping that you're saying, hey, reviewer, this is worth your time because you're going time from them hopefully to give them something good you know in an open source project you're hoping that you're saying hey reviewer this is worth your time because you're going to get a new feature you're going to get a bug fix that's great but you are still presupposing that they're going to spend some amount of time and for some of these things like i i know very good reviewers who will spend a very long time poring over the lines line by line and really giving you that thorough audit that like a linter would would do right in a better situation and like no this doesn't really work the way you think it does i think you know you can be more efficient in this way whatever so you really are asking a lot from the reviewer and so giving them a smaller piece is a nice way of saying only 15 minutes of your time, thanks.

Or only five minutes of your time. Somewhere like that. That's the nicest thing. It depends on the language. It depends on the problem that you're trying to solve. And to an extent, it depends on your relationship

with your reviewer as to exactly how much you can get into one pull request. But smaller is usually always better unless you're obfuscating what's going to happen down the line. Right, right. I've definitely had situations

where I've just been like, you know, this is some combination of honesty and selfishness. But I'm like, if you send me a pull request that's longer than about 500 lines, I'm just going to say LGTM and I'm not going to read it.

And I'm saying that not because I'm lazy and not because I don't want to review your request, but because I know I'm not going to be able to really understand the code at the level that you expect me to understand it. And I'm not even going to try. And it's like, I'm being a little bit sort of selfish there, but I'm also just being like, there's just no way for me to do that. If you send me a 3,000 line pull request, I can't understand it all. I just can't. I'm not going to have it. Well, this is the second part to a large pull request,

which in a follow-up, I'm going to immediately erode this statement away with the next bit, which is if you have a too large pull request then it is like you say either your reviewer is just going to go lgtm it looks too good to me you know what looks fine or they're going to say to you have you considered doing this a completely different way and you're going to be really really upset that you have invested all this time doing a giant giant giant change when there is perhaps they're like yeah if you just pass a negative number and it does that anyway what do you this is a really awkward and like or you know obviously that's a very pithy um uh comeback but i mean like

the larger a change is the more likely people are to have strong opinions about how it affects the rest of the code base and effectively you're writing an option when you do a pull request of like well this could be thrown away right i'm doing something which somebody could say i don't like it and so it's almost on yourself to say well how about if i haven't already reached out to the the person who's going to be reviewing it or someone else to say can we get a bit of buy-in about the general approach about my problem um how about i make it a small enough thing that i they won't feel guilty telling me this is no good this is not how it's going to work and i'm not wasting too much of my time spending a lot you know crafting

a beautiful thing that's just not ever going to get merged in right so that's another reason to make it smaller and to the point of course there are always times when you can't make a minimal change because you're renaming something across the whole code base or whatever but hopefully those mechanical changes you could at least say hey this is i did this with a refactoring tool yeah yeah you can at least make that a focus change right like you can have a pull request that is i'm renaming this class and it's used in a thousand different places and you can read all these lines but they should all basically be the same thing and then secondly like having renamed the class i'm going to give it some new responsibilities and then move on

yeah so then you can kind of do that absolutely so the thing that i said about eroding uh the pull request is that obviously if you are breaking what is a larger change into smaller pieces you can start doing some trickery where you build one change off of the next change and have like a set of cascading pull requests. And that's something I'll often do. But I'll do that only really because I'm very confident that the very head of that chain of changes is not going to significantly change. And if it does, it's mea culpa, right?

So that's a good pull request is focused. It is sent hopefully to somebody who is not going to be shocked to receive it you know the the reviewer is going to have an explanation as to why uh this change is being made and hopefully it has some kind of audit trail for like the bugs it closes and or the the things that um and obviously it should be ci'd if anyone has a ci system then you know all the pull requests should be run and have all the tests passing. Maybe you have coverage things and stuff like that. So very often, some tooling can take away some of the toil of like,

did you write tests for your code? Oh, look, you failed because 0% of the new code was covered by tests. Oh, I'm sorry about that. So that's one thing. So then as a reviewer on the other side you have a certain amount of responsibility you also have to understand that somebody has just sent you a piece of work and they are sort of standing sort of awkwardly cap in hand just hovering off to the side looking at you expectantly like is it good is it is this okay is this nice and so you have to be taught you know thoughtful to them um and and

so the first thing i would think of is is be kind especially as pull requests are are are mostly administrate administered not administrated administered over electronic means right you if and the worst is usually interpreted in anything you will write you know have you know you always say thank you for making this change like i i go out of my way to find all the best parts and make sure i celebrate them in a pull request because otherwise it can be a miserable like just saying thanks oh no sorry just saying merged is no good but like hey you could have this this could have been a copy pasted but you took the time to extract a class and you took time to write tests for that extracted class

and then you used it in three places that's great i love it right yeah it doesn't have to be obviously as quite as effusive effusive effusive whatever a word like that as those i just was but i find it goes a long way in terms of like then when you do have to say actually this thing needs might need to be you know renamed or could you consider this? There's a bit of a race condition. If these two things happen, what other ways can there be? Then,

you know, it goes down better. Now I don't want to propose like the sandwich, like way of giving criticism to anyone. That's not a helpful thing, but like just, if you're generally acknowledged the work that someone has put into the PR, right.

And that gets you into a really good mindset for giving the, the few targeted places where you might say, can this may need to change. Polar cats have all the worst combinations of electronic communication and judging people. Right. It's just, it's just,

it's really terrible. The whole thing is terrible, but that's absolutely true. You got to make that effort to sort of like, you have to go over and above, I think to do a good review and then

anytime you do ask for a change have a concrete suggestion it can be very frustrating for a project owner who knows their own project really well when somebody does yet another sort of small change and you're like no no it just doesn't work that way and you

just say no please change this thing right that you need to be able to say hey why don't why don't you change it in this way because and then link to the frequently asked questions it says hey yeah the reason we don't use that approach is this thing or please stick to the style of the project a few other bits and pieces like that but again if you're asking someone to change and you have a concrete way of changing it as opposed to just airily fairly saying i don't really like the way this is done right that's not a nice way of giving somebody feedback you say yeah so that's the kind of thing i'm thinking about when i'm reviewing and mostly from the open source side of things where more than uh anything else you are very aware that folks are doing this out of their own goodwill

yep and that's the only coin you have have in the open source community is the goodwill of others. You know, and I'm totally blessed to have some amazing people who will submit stuff to stuff that I'm responsible for. And I have to keep that top of mind to say like, thank you. You didn't have to do this.

You're a volunteer and you're trying to make the world better. Thank you. I do try and get that into the reviews i do at work too though right i do want to say like you know hey yeah we're all professionals we're all paid to be here but it's still nice to be told yeah that's a super cool thing i didn't know that trick you know everybody wants to hear those things right right right right yep yep no that's that's a good point that you make especially about open source right It's like, the worst thing about open source is you can never get your money back. And that works at both levels, right? And I have been the maintainer for open source projects as well, not nearly as popular as some of the ones that you've worked on. that experience of having people sort of send me PRs for like very well intentioned changes that just don't match the model of what the project is

trying to do. And it's always a super awkward conversation of like, I realize that you put a lot of time and energy and thought into this. I'm sorry, but no, right. And it's like, it's,

it's, it's just such a painful conversation to have. So it's like, there's no winners really in that situation, unfortunately. Yep. Yep. Yep. have. So it's like... There's no winners really in that situation, unfortunately. Yep, yep, yep. Yeah. So what about...

One thing I know that could come up a lot, and this is maybe more prevalent... I was going to say this is maybe more prevalent in open source, but I think it actually is a problem in lots of different contexts, which is when you have multiple reviewers, right? So you have a PR that you create and you want to send it out to a group of people. Like, what are some things to do in that situation?

So that's interesting. I avoid it where I possibly can, right? I try to make it very clear that I would like one person to review it and I send it to that one person. And I suppose within a work context, you know, the thing that I like to say is have either reached out to the person ahead of time or have like a pre-existing arrangement with them. Because, you know, like, hey, we're on the same team.

So we expect some kind of level of service, quality of service. And say like, okay, I'm giving it to you. Can you review it? Or let me know that you can't review it in a relatively timely fashion. And then if other people should be notified of the PR or might have opinions about it, I will CC them as a very separate thing inside the comments. I'll say, this is probably of use to Bob and Tracy. They should know that this change is going through. And then, of course, anyone can dive in on a GitHub-style review.

I mean, I guess it's worth saying that like my mental model is very focused around the github workflow although although the git lab has something similar and you know llvm has fabricator and other things but it makes sense to have one person who is on the hook to do the review otherwise i find when i'm on the receiving end of a pull request and as i'm one of five people uh the chance of me replying sort of proportional to the inverse square of the number of other people that there are on it like you know everyone assumes someone else is going to pick up the actual thread of it and then i'm just gonna go yeah that sounds good or else worse still i will be halfway through reviewing it in my very

you know put my hat on and say okay this i'm gonna be good this is i don't really know this code base and then it's everything he comes in and says LGTM. And then it's already checked in or, and then I'm still making writing comments for it. And I find that that's also, you know, it's rude, rude.

So, so, you know, it needs to be clear or at least, you know, have intentions. There are ways of labeling things in GitHub. If you want to say like,

you know, one of two or, you know, everyone needs to commit this or whatever, just as a way of hinting. That also comes back around to like, when, once the reviews are all in who should merge the PR in and i have very strong opinions about this which it

should be the original poster oh yeah unless they go out of their way to say once this is fine whoever's lgtms should commit it and that's only mainly because sometimes i like to orchestrate amongst other changes that i have which order they go into a code base. And I feel like, well, I'm the one who's tying myself in stupid knots, making all these different branches that are all interrelated and trying to PR them. I can untangle them if it's my fault. But if someone else commits something else first, then maybe I don't. Well, and certainly that is consistent if you're working in a model with continuous deployment, where's like once you merge it it's going to prod so you better have the person that's shepherding that change through to production because normally if you're not making a pull request you commit something to to the main

branch and it goes into production right that would be the normal way to do it so introducing a pull request shouldn't really change that model right like they're just getting a review of the code they're not necessarily wanting to change the the sort of ownership of the deployment right right it's still on me to kind of essentially watch the deploy and make sure it goes into production and i tail the log and go oh yeah that thing did work the way i thought it did or whatever just as the final final whatever it is that you need to do yeah exactly right right right yeah that makes sense so yeah one single single reviewer hopefully i check. Whatever it is that you need to do, yeah, exactly. Right, right, right. Yeah, that makes sense. So, yeah, single reviewer, hopefully. I mean, obviously, there are cases when you need to get multiple reviewers.

Yeah, I was going to say, like, are there situations where you have, you know, a change that, for whatever reason, you can't break into two pull requests, and you're like, well, two people need to look at this. Yeah. I guess what you're saying is normally you'd CC one of them. I don't know. I think in that instance, I would just... To, like, wait? Or, like, how do you handle that? I think I normally you'd cc one of them i don't know i think in that instance i would just to like wait or like how do you handle that i think i would probably send it to both of them but make sure that they were aware that i want both sign off from from both of those

people otherwise um yeah otherwise you could easily construe oh i have to review this or no it's just one person needs it as long as i think as long as it's clear then um then it's not much of them but i prefer strongly having one person so that everyone knows who who's whose responsibilities where the responsibilities lie right i personally i have all the email rules in the world to make sure that pull requests pop up on my desktop and tell me hey you know you've got something to do straight away um in fact while we've been recording this uh one has popped up and i and I'm feeling a bit bad about not doing anything about it but I'm sure the I know I know the person who submitted it I think it'll

be fine yeah and you know and obviously with open source projects as well there's even more asynchronicity here I suppose I'm thinking when I've been talking about the pull request and the multiple people thing that's been definitely much more about work projects where anyone could reasonably review the code and commit it as you say there might be areas of the code base that are like mostly this is you know uh ian's area of the code and then there's you know darcy's over here and you know the two of them need to give me some sign off from it that's that can easily easily happen but but usually there's somebody else there's like a fun one one of like the four or five other people on your team are fungible.

You can just pick the person who is least recently used. Although actually back in the days at Google, there was certainly a bit of horse trading in like the reviewers you knew were more lenient or otherwise right it was a bit of like well somebody else has to lgt the tm this and you know this is a bit gnarly and i can go one of two ways i will either send it to the person opposite me and i'll kind of do the whole social engineering thing of like hey uh fancy going for a drink after work uh yeah yeah i actually just before we go i've just sent you a pr do you mind having a quick look by the way which i mean okay that's not it that never actually happened but there was definitely the the reverse actually happened i'll tell you so

the one of my good buddies is probably the best code reviewer i've ever had and if i definitely wanted it to be picked apart down to like the absolute atomic level of like hey did you know that this has a strange side effect? I sent it to Malcolm and Malcolm would be like, yeah, I'll find all the problems that you'll ever. And some of you never even realized could have been problems. And that was sometimes what you wanted.

So have you ever worked at a place that has had more sort of like traditional code reviews where you'd have like a, you know, a code review team or committee or a group that would be assembled to go through code line by line that had been changed at any point in time. No, no. Have you? Unfortunately, yes.

Oh. Oh. Yeah, because I think this is a thing that people do sometimes still do. Right. I don't really understand why. Maybe because they think they have too many people employed there. I'm not sure. I can certainly see.

I've seen some people say what a good way to do code reviews, just in general, is to, like, have the end of the week, everyone picks out the changes, and you sort of project them up, and you go over some of the code and for certain critical things you know it's a great way of everyone getting on board and seeing the code almost celebrating some of the great you know things that have happened and i consider being a positive experience but i can that's that's by casting the most rose-tinted light i can possibly project upon it yes because my yes if you're generating small enough amounts of code that can be reviewed in like a end of week celebration um usefully then maybe you're not generating i mean i know you have a thing you know you've come on like your your pinned tweet right now if i remember rightly is you know like what something to do with pair programming do you want to explain what your pinned tweet is just oh yeah no it is uh is. I almost want to pull it up just to make sure.

I think you should pull it up so that you can quote it completely. And I'll cover for you by talking and saying that I'm covering for you, which means I'm not covering for you at all. Thanks. Thanks. Thanks for covering for me. We'll fix this in post. I really appreciate it. We'll fix this in post.

But, yes, my pinned tweet. Come on, Twitter. You can do it. My pinned tweet says, it Twitter, you can do it. My pinned tweet says it's like two people talking and the first one says but if all of our programmers are pairing, won't they write half as much code? And the second person says no, hopefully they'll write even

less than that. The whole point is that code is a liability. It's the functionality that has value. And you know, if you have two people looking at a problem, sometimes they come up with a similar solution, which is great.

Which is the hope, right. Which is the hope. But yeah, I have definitely worked early in my career. I worked in some places that would do these more formal code reviews.

And they are incredibly painful, especially when done in a group setting, especially when you're a junior engineer. Right. And oftentimes not really that helpful, right? So it'd be one thing if the pain was yielding significantly better code. But the problem in that setting is especially it's a little bit of bike shedding where people can't scroll around and sort of dig into the context of the changes, right? They can't expand that tab in GitHub or they can't, you know, go pull a thing up in an IDE and click around. And so they only see what's on the screen.

And so it's really hard for them to understand what's actually going on. And so what they do is they pick apart things like style they say like oh that variable name could be better or you should have used you know a while loop instead of a for loop or you should have used you know it's like usually trivial things and I think there's this

sort of old cliche I've heard it's like if you give people you know five lines of code to review they'll find five things wrong with like, if you give people five lines of code to review, they'll find five things wrong with it, but if you give them 500 lines, they'll say it looks all good. And it's sort of the in-between of that, where it's like, there is 500 lines to review, but

we're all in a room together, and we're supposed to be saying things. I think that's the key there as well. It's worth saying that no matter what your review technique, saying thank you, this looks great, and saying approve is a perfectly reasonable

code review. You don't have to go through and find things to say. It's very wearing, right? It can't just be good. Everything can actually be good. It may not be every time, but very often you can find... yeah yeah so i'm glad

that you've been spared that experience i i have i mean we've i've worked to places where obviously the financial uh impact of changes can be very sorry misplaced changes or miss uh bugs is what i'm talking about here right it can be very um very big and so there have been all sorts of talk about like well maybe we should do reviews maybe we should have whatever and like ultimately the testing is what saves you most of the time and and even then like with reviews um you have to be sure that um the person who's reviewing your code would also have caught a bug for it to be worthwhile the drag of doing that in the same way. Now, I guess we never actually spoke about some of the benefits of doing reviews at all,

be they programming continuous reviews. Oh, yeah. Well, we did, actually. It was my tweet, smaller code. I mean, that is definitely like, you know. But there are other benefits to it. Oh, yes, for sure. The thing that I keep coming back to when I do pair program is that, I mean, first of all, two brains is better than one.

So hopefully you come up with a more sensible solution, full stop. And we've talked about all the knowledge transfer that can happen between individuals when they're sat together. And obviously there are some of the drawbacks about the how much of it takes out of you and various different personalities may not work for for them yeah but um that and pull requests someone reviewing your code actively as well as trying to help the the quality of code by saying hey this doesn't work the way you thought it did or maybe you've considered this other thing all that kind of stuff is you're sharing knowledge about the system you're developing together yeah and reducing bus risk you know the unfortunate let's say uh lottery risk that's a much nicer thing lottery risk lottery like a

lottery winning the lottery sorry lottery lottery there you go lottery okay now i could but the risk of somebody you know their numbers coming up on the state lottery and it's going you know what I don't need to work anymore I'm off right I guess in our current line of work crypto risk laughter laughter

oh my gosh yes alright Ben and I work in an industry where many of our friends are into crypto and so as crypto waxes and wanes there is definitely a risk that some of them may decide that buying their own tropical island is is uh it's more preferable than hanging out and programming with us or something similar to that um but yeah i mean in terms of yeah reducing the risk that if a team member leaves or changes their role within the business, that you are now left with a hole in your understanding of the system, right?

At least somebody else has seen that piece of code. It's not just like some hidden aspect. So there's a benefit there too. Right. Absolutely. Yeah. I mean, that, and answer is there are these risks that are very square wavy, where you can go along

for a long time and never even get a whiff of this risk. And then all of a sudden, some Dogecoin goes to $100 bazillion. And Sandra Quisca, she's made her fortune and doesn't need to work anymore. Right. And they don't even give you notice. They just stop showing up to work one

day, and now you can't deploy your system anymore because that person doesn't work here anymore, right? Or like, there's some critical piece that if it has a bug, you just literally can't fix. And so those sorts of, like, very

you know, sort of they're not exactly black swan because it's like people leave these jobs all the time. But those sort of, like, you know, those sort of risks that can sit there and hide. And it's really hard to see them. It's really hard to detect that, right? Like, to know, like, what are the parts of the system that only one person knows, right? Right. And it's just been going along fine because that one person has been, you know, making sure that it doesn't break and fixing the bugs and picking up all the issues

and making the improvements. And no one's noticed that it's actually just Alice. She's the only person that understands those 100,000 lines of code that are central to your company. Yeah. And so, you know, and it can be very threatening

to somebody in that situation if you go over to them and you're like, hey, you know, we're worried about your quitting, so you need to train this other person. I can see that not going well. Yeah, right. That's very awkward. whatever they might be, is a great way to sort of, like, systemically reduce that risk without having to identify it and address it on a case-by-case basis, right? Yeah. Which can be a little weird.

So, yes. I can't imagine Sordra got to Odyssey saying, so, about that, how much Ethereum do you own? Just wondering. Just asking. Just asking. Just asking. How's your weekend? So if we talk about knowledge dissemination and multiple brains being applied

to a single problem to sort of see if there's a good solution or not, then it would be rude not to talk about mob programming. Mob programming, yes. Sorry, mob. No, no, mob programming. Yeah. Sorry. Mob. No, no mob programming.

Mob. Mob. Hello. We're the mob here. We've come to fix your program. We've come to fix your program. So I, I will first say that I,

uh, I know a lot of people that do this, that I trust that do that. Say they do this very effectively. I've tried it a couple of times myself. Seems fine. I can see how it could be very good, but I am not, unlike with the pair of programming

where I'm like, I've done this for years, the mod programming is not something that I have any claim to any particular expertise to. I've never done it. Other than informally when you're pair programming and someone else comes over and starts helping, you've collected a small crowd just because a crowd attracts more

crowd you know but do you remember when we were actually in offices i mean i know actually people that's starting to come back now i hear so maybe maybe actual mobs in actual buildings the mobs are coming back yes yeah uh so yeah tell me about mob programming what you know of it anyway so the one so the one time i've done this recently uh like in the last two years um you might have actually been in the room for this i don't remember but um we were designing an api and this was going to be an api that was going to be used by a lot of people uh some of the people in the room were going to be users of the API. Some of the people in the room were going to be implementers of the API. But this was going to be a potentially fundamental API.

And the idea here was, okay, we're going to try to design this API with mob programming. And we booked a conference room for a couple hours, got the projector up on the screen, and we had a computer hooked up to this projector with an editor. And the main rule of mob programming

that we followed, and I think this is the more important rule to follow. Again, I am not an expert in this but like sort of the the pair programming thing is like don't you see your your um your your pair the main rule that you follow here is you say the person who's who's driving the person whose fingers on the on the keyboard is not the person who's designing the code all of the ideas for what goes into the code need to be verbalized by somebody that is in the room.

Got it. Communicated to that person who then implements it. They are just the remote hands. They're just a scribe of the idea. They're not doing anything other than like typo checking. Well, and it should be like write the word function. Now write the word arg1. Now write a comma.

Now write the word function now write the word arg1 now write a comma now write the word arg2 it needs to be explain your solution to the driver who interprets it and implements it right um now this has a nice benefit of actually the sort of rudimentary version of this i think is not particularly coupled to test room development like it is withPong. So if you're not a shop that does TDD or isn't particularly familiar with it, this won't feel as alien. In our case, I thought it worked pretty well. It is maybe

worth noting that we didn't wind up using that API. So I will say that... We don't have a resounding success from this particular... I don't have a great success story and they're like, and that was the API that made us a bajillionty dollars. No. There's nothing that comes out of it like that. But

the experience I thought was pretty good and it is definitely something that I personally would like to try more of, maybe in slightly smaller groups of four or five-ish people. Because it can be really hard to get five or six people to collaborate

on anything, lunch even, let alone something like an API, right? Yeah. MP hard problem. Yeah, so any sort of mechanism that can get... What pizza are we ordering? Ah, no, that's terrible. We can't get that.

Any sort of mechanism that allows four or five five six people to collaborate in that way i think is extremely interesting because there is a certain set of problems where you really want a lot of buy-in from people like they're going to be very affected by something and you can do it as a person goes and creates a pull request and sends it out to all five people and they all sort of like pick it apart and have their own ideas but again you sort of have that problem that you were talking about especially for things that are really important well i've already built the

solution and now you're tearing it down right so now i gotta start over from from grounds you know from square one and that's terrible and it's awkward to say that that's what needs to be done if that's what needs to be done and so having what needs to be done. And so having all those people there to sort of steer it in the direction that they all... You know, you can almost think of it like forces apply to a physics problem, right? Yeah. Each person is a force vector.

On the mass, which is the problem. On the mass of the problem. Yeah, the resulting vector, that's the solution, right? Yeah, I like that analogy. That makes sense. So actually creating a situation in which all of those forces can be applied equally and in the right proportion

and result in something that everyone in the room agrees is good. Right. Consensus amongst everyone and just the sort of philosophical buy-in because you helped make it hopefully that makes a lot of sense to me but as you say it didn't actually get used in this particular example but that may not be because of the situation there's a million reasons why that

might be true right yeah right so so this is something that i would kind of like to do a little bit more i would love to work with somebody that actually knew this technique really well um to just sort of act as a facilitator and sort of drive it and you know just it'd be an interesting experiment to try a few things that yeah yeah and we could well if we do it we'll we'll have to report back and let our listeners know how it how it went yep maybe that'll be part three maybe so i was gonna say we've definitely reached the end of what i think is a good amount of things covered. But I mean, the things that spring to mind for me is like the other sort of collaboration.

You know, we've talked about code, but not everything we do is code. And I think the thing that you were talking about with more programming is that actually the design is being shared and collaborated on, which is cool. But there are other ways of collaborating. And we can perhaps talk about those another time as well. But this has been a lot of fun. Our first two-parter. So if our listener, or listeners,

sorry, the two listeners could let us know what they thought of it, we'd be appreciative. But this is cool. I'll guess we will talk about something else next time. Yeah, this is great, though. Cool. Later, though. Cool. Cool.

Later, Ben. Later. You've been listening to Two's Compliment, a programming podcast by Ben Rady and Matt Godbolt. Find the show transcript and notes at twoscompliment.org. Contact us on Twitter at twoscp.