Hey Ben.
Hey Matt.
How 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, uh, on a note where, uh, we were describing the, um, you know, different things work for different folks. And, um, there there's no good one true answer, but right at the end, just as we were running out of time, you posed a sort of 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
He said knowingly
I've been waiting for a month, to hear the answer to this because.
exactly, yeah.
That's when these podcasts are going to come out
Left on tender hooks the whole time, everyone thinking what makes a good pull request. So actually there's this sort of two sides to this. I think there is 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 the person who, and their interaction with the, uh, the, the, the, 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. Right? Sometimes I think we talked about this a little bit last time. Um, that's sometimes you can't infer the why from just the diff the diff like, you know, you change the number 16 to 17 on all the tests that have been updated, and you kind of say like, yeah, we, we updated the 16 to the 17 and all the tests now pass, but why, why, why was the 16 or 17?
What was, what was 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, um, explanation isn't often tracked as well as the, the, the individual changes that you committed and most source control. So source tracking systems work at the level of like the commits that you 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 stored out of the line, certainly in github and stuff. 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, um, 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 he gets merged, it will automatically close the bug, which is a cool feature.
Um, 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're you are necessarily imposing upon your reviewer sometime 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 to get a new feature or you can 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 know very good reviewers who will spend a very long time pouring 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 or somewhere like that. That's, 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, uh, one pull request, but smaller is usually always better unless you're obfuscating, what's going to happen down the line.
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 LGT M and I'm not going to read it. Um, 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, it's, it's, I'm, 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 3000 line pull request, I can't understand it all. I just can't.
Well, this is the second part to a large pull request, in which in a follow-up I'm going to immediately erode this, this, this, this statement away with the next bit, which is if you have a too large pool request, then it is like you say, either your reviewer is just going to go, LGTM, it looks good to me. It 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, this is a very 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, you're writing an option when you do a pull request of like, well, this could be thrown away, right?
I am, 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 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 it, 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 can at least say, Hey, this is, I did this with a refactoring tool.
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 of these lines, but they should all basically be the same.
And then secondly, like having renamed the class, I'm going to give it some new responsibilities and then move on. So then you can kind of do that. Absolutely. So the thing that I said about eroding 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 Mia culpa, right? So, 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 reviewer is going to have an explanation as to why this change is being made.
And hopefully it has some kind of audit trail for like the bugs or closes and, or the, the things that, um, and, and obviously it should be CI'd. If anyone has a CI system, then all the pull request should be run. And it will have all the test passing and maybe you have coverage things and stuff like that. So very often some tooling can take, can take away some of the toil of like, did you write tests for your code? Oh, look, you failed. Because like 0% of the new code was covered by tests. Oh, I'm sorry about that. Right. So that's one thing. So then as a reviewer, on the other side, you have a certain amount of responsibilities. 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, is this okay? Is this nice? And so you have to be thoughtful to them. Um, 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, and the worst is usually interpreted in anything you will write, you know, have you, 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 or no, sorry, just saying merged is no good, but like, Hey, you could have this, this could have been 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. It doesn't have to be obviously as, quite as effusive, whatever word like that as those I just want, but I find that it goes a long way in terms of like, then when you do have to say, actually this thing needs might need to be re re re renamed, or could you consider this? There's a bit of a race condition. If these two things happen, what other ways can that be? Then it goes down. But now I don't want to propose like the sandwich, like way to anyone. That's not a helpful thing, but like, just if you're genuinely acknowledge the work that someone has put into the PR, and that gets you into a really good mindset for giving, uh, the, the few targeted places where you might say can, this may need to change.
Pull requests have have all the worst combinations of electronic communication and judging people. Right. It's really terrible the whole thing is terrible.
That's absolutely true.
But yes, you gotta make that effort to sort of like
Go over and above, I think, to do a good review. And then, um, and then anytime you do ask for a change, have a concrete suggestion, you know, it can be very frustrating for a project owner who knows their own project really well when somebody does it. Yeah. Another sort of, uh, like a small change. 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 linked to the frequently asked questions that says, Hey, yeah, we usually don't use that approach. Is this thing, or please stick to the style of the project if you have the 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 airy fairy say, I don't really like the way this is done.
Right. That 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 anything else, you are very aware that folks are doing this out of their own goodwill. And that's the only coin you have in, 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 in 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, Hey, yeah, we're all professionals, we're all paid to be here, but it's still nice to be told, That's a super cool thing. I didn't know that trick, you know, everybody wants to hear those things. Right,
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, um, the worst thing about open source is you can never get your money back. And that works at both levels. Right. And I have, I have worked, I've been the maintainer for open-source project as well. Not nearly as popular as some of the ones that you've worked on, but I have had 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 and I'm sorry, but no, right. It's like, it's, it's, it's just such a painful conversation to have.
There's no winners really in that situation, unfortunately.
Yep. Yeah. So what about, um, one thing I know that come up a lot, and this is maybe more prevalent, but I was going to say 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? Like, 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, 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 preexisting 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 like as a very separate thing inside the comments I say, this is probably of use to, you know, 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 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, 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 assumed someone else was going to pick up the actual thread of it and I'm just gonna go yeah, that sounds good. Or else worst still, I will be halfway through reviewing it in my very, you know, put my hat on and say, okay, this I'm going to be good. This is, I don't really know this code base. And then
And then someone like me comes in and says, LGTM.
And then he's already checked in or, and then I'm still making writing comments for it. And I find that that's also, you know, rude, rude. So, you know, it needs to be clear or at least, you know, have intentions. There are ways of labeling things and 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 the original poster only, unless they go out of their way to say, once this is fine, whoever's LGTM's this 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 felt like, well, I'm the one who's tying myself in the 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, you know,
Well, and certainly that is, is consistent. If you are working on a model with continuous deployment where it'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. And 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 sort of, um, 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 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. Yeah.
That makes yeah. So yeah. Single, 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. I guess what you're saying is normally you'd CC one of them
I dunno in that instance I think
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, that, that they were aware that I want both sign off 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. 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's who's, who's responsible is where the responsibilities lie. 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, if I have, while we've been recording, this one has popped up and I have 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.
And, you know, obviously with open source projects as well, they'd lose even more asynchronicity here. I suppose. I'm thinking when I've been talking about the pull request and the multiple people, that the 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, 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 usually there's somebody else there's like a fungible. One of like the four or five other people on your team are fungible. You can just pick the person who is least, um, uh, at least recently used. Uh, it, although actually back in, back in the days at Google, uh, I did, there was certainly a bit of horse trading in like the, uh, reviewers you knew were more lenient or otherwise. It was a bit of like, well, somebody else has to LGTM, this, and 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, I'm fancy going for a drink after work. Uh, yeah. Yeah. I actually, just before we go, I've just sent you a PR
Drinks are on me 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 tell you, so 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 will never, 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 like go through code line by line that had been changed at any point in time?
No. No. Have you?
Uh, unfortunately, yes.
Oh, oh.
Yeah, because this is a thing that people do sometimes still do. 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 I've, 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 things that have happened. And I can see that being a positive experience, but I can that's by casting the most rose tinted light I can possibly project upon it. Yes.
Because yes, if you're
Generating small enough amounts of code that can be reviewed and they're like end of week celebration, um, usefully then maybe you're not, I mean, I know you have a pinned tweet right now, if I'm remember, rightly is, you know, like what something to do with pair programming. Do you want to explain what your pinned tweet is?
Oh yeah, no, it is. Uh, I see, I almost want to pull it up.
I think you should pull it up so that I can quote it. 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 kind of.
I'll fix this in post.
I really appreciate it.
Um, but yes, my, my pinned tweet on Twitter, you can do it. My pinned tweet says, uh, it's, 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. Um, that's the whole point is the code is a liability. It's the functionality that has value. Uh, and you know, if you have two people looking at a problem, sometimes they come up with a simpler solution, which is great, which is the hope. But yeah, I have, I have definitely worked, um, early in my career. I worked in some places that would do these more formal code reviews and they are, uh, incredibly painful, um, especially when done in a group setting, especially when you're a junior engineer. Um, and oftentimes not really that helpful, right?
So it'd be one thing if the pain was yielding significantly better code. Um, but the problem in that setting is especially it's a little, it's, 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 the 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, you should have used, uh, you know, a while loop instead of a for-loop or you should have used a, you know, it's, it's like usually trivial things. And I think there's this sort of old, um, cliche I've heard, it's like, if you give people, uh, you know, five lines of code 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 they're all are, we're all in a room together. And we're supposed to be saying things.
I think that's the key there as well. Like we're saying no matter what your reviews technique saying, thank you. This was great. And saying approve is a perfectly reasonable
Yes.
code review. You don't have to go through and find things to say, that's, it's very wary, right? That's not
Everything can be good. Everything can actually be good and
It may not be all every time, but very often you can find. Yeah, yeah,
Yeah. I'm glad that you've been spared that experience
I have. I mean, we've, I've worked at places where obviously the financial 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've been all sorts of talk about like, well, maybe we should do reviews. Maybe we should have whatever. And ultimately the testing is what saves you most of the time. And, and even then like with reviews, um, do 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 pair programming continuous continuous reviews.
Oh yeah. Well it did actually, it was my tweet smaller code. I mean, that, that is definitely like, you know,
There were 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, you, two, two brains is better than one. So you, hopefully you come up with a most 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 them, but, um, that and pull requests, someone reviewing your code actively as well as trying to help 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 and reducing bus risk. Unfortunately let's say, uh, lottery risk. That's a much nicer thing. It's not lottery like winning the lottery, Sorry, lottery.
Lottery, there you go. Now you're an american.
But the risk of somebody, you know, the numbers coming up on the state lottery and it's going, you know what? I don't need to work anymore. I'm off, I guess, crypto risk.
Oh my gosh. Yes. All right. 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 more preferable than hanging out and programming with us or something similar to that. Um, but yeah, I mean, in terms of reducing the risk that if a team member that leaves or changes their role within the business, that you are now left with a hole in your understanding of the system, right. Indeed at least somebody else has seen that piece of code. It's not just like some, some, some, uh, hidden aspects. So there's a benefit there too, right?
Absolutely. Yeah. I mean that, and that is, uh, you know, when I'm making the argument for finding better ways to collaborate, because sometimes you do get pushback on some of these things, both from engineers and from, you know, product owners, managers, other pointy, pointy hair types
To ask questions about it. Oh,
For sure. For sure. But then the answer is, it's like, you know, there are these risks that are very square wavy, right. Where you can go along for a long time and never even get a whiff of this risk. And then all of a sudden, you know, some doge coin goes to a hundred billion dollars.
And Sandra quits because she's made a fortune and doesn't need to work.
They don't even give you notice. They just stopped showing up to work one day. And now you can't deploy your system anymore. That person doesn't work here anymore. Right. Or like there's some critical piece that, um, if it has a bug, you just literally can't fix. Um, and so those sorts of like very, uh, you know, sort of, they're not exactly black Swan because it's like people leave these jobs all the time, but it was 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, um, to know, like, what are the parts of the system that only one person knows, 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 hundred thousand lines of code that are central to your company. Um, and so, you know, and it can be very threatening to somebody in that situation, if you'd be, if you go over to them and you're like, Hey, you know, we're worried about you quitting, so you need to train this other person.
I could see that not going well.
Yeah. That's very, very awkward. So, so encouraging these kinds of collaboration, methods, 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. Um, which can be, which can be a little weird. So yeah,
I can't imagine, sauntering up to someone and saying, soo....
How much ethereum do you own? Just asking, you know, how was your weekend?
So if we talk about knowledge dissemination and like 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.
Yeah. Sorry, mob.
Hello we're the mob here. We've come to fix your program.
So 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 have 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, oh, I've done this for years. The mob programming is not something that I claim to have any particular expertise to.
And I used to, I've never done it. So other than like informally, when, when you pair programming and someone else comes over and said, I was helping her, then you know, you've collected a small crowd just because a crowd attracts more crowd. But do you remember when we were actually in offices? I mean, I know actually the people that started to come back now, I hear so maybe, maybe actual mobs in actual buildings,
Mobs are coming back. Yes. Yeah.
Um, tell me about mob programming, what you know of it anyway.
So the one time I've done this recently, uh, like in the last two years, um, you might've 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 gonna 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 gonna be implementers of the API, but this was going to be a potentially fundamental API. And, uh, the, the idea here was, is we're okay, we're going to try to design this API with mob programming. And we, we booked a conference room for a couple of hours, got the projector up on the screen. And we had a computer hooked up to this projector with a, 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 Chewy seat 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, just fingers are 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 the scribe of the idea. They're not doing anything other than like typo checking.
Well, and it shouldn't be like, write the word function. Now, write the word, arg one. Now write a comma. Now write the word arg two. 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 driven development. Like it is with ping-pong. Um, so if you're not a shop that does TDD or isn't particularly familiar with it, this won't feel as alien. Um, 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 always say that, like, you know, we don't
Have like a resounding success from this particular
I don't have a great success story. And they're like, yeah, that was the API that made us a bajillionty dollars. No there's nothing that comes out of it like that. Um, but you know, the experience I thought was pretty good and it is definitely something that like I personally would like to try more of, um, maybe in slightly smaller groups of like four or five ish people. Um, cause it can be really hard to get five or six people to collaborate on anything, lunch even, uh, let alone something like an API. Right. Um, you know, so yeah. So any sort of mechanisms that can get. What pizza are we ordering? Oh no, that's terrible. We can't, we can't get that. Um, the, any sort of mechanism that allows, you know, four or 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 if 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 a solution and now you're tearing it down. Right. So now I got to 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 all those people there to sort of steer it in the direction that they all, you know, you can almost think of it like, um, like forces apply to a physics problem, right. Where each person is a force vector on
The mass, which is the problem.
The mass of the problem, the resulting vector...that's the solution, right?
Yeah. Yeah. I like that analogy that's yeah, that makes sense.
So actually like creating a situation in which all of those forces can be applied sort of equally and in the right proportion and result in something that is, that is everyone in the room agrees is good, right.
Consensus amongst everyone and just the sort of philosophical buy-in because you will help make it, hopefully it comes along with it. 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. Right. So, so this is something that I would kinda like to do a little bit more. I would love to work with somebody that actually knew this technique really well, um, to, to sort of act as a facilitator and sort of drive it. And you know,
It'd be an interesting experiment to try a few things. Well, if we do it, we'll, we'll have to report back and let our listeners know how it, how it went.
Maybe that'll be part three. Maybe
We've definitely reached the end of what I think is a good amount of, of things covered. But I mean, I, 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 mob programming is that actually the design is being, uh, shared and collaborated on which is cool, but there are other ways of collaborating. We can perhaps talk about those another time as well. But this has been a lot of fun, our first two parter. So if to, uh, our listener, or listeners, sorry, the two listeners could let us know what they thought of. It we'd be appreciative. But, um, this is, this is cool. I guess, I guess we will talk about something else next time.
This is great though. Cool,
Cool. Laters, Ben.