Here's What Pull Requests Are REALLY Solving For Developers...

Transcript is auto-generated and may contain errors.

What's up, folks? I'm in Arizona. I'm on vacation. I'm at a conference. Well, my wife's at a conference, so I'm just tagging along. And uh so she's at some sessions right now. I'm not there. I'm here. I got downtime. That means we're going to the YouTube comments. So, um this one is from Federico Rone. Awesome name. Um he's got two questions. I'm going to do make two videos on these. Make them kind of short and focused on what's going on. Um, this is in response to uh one of the videos that was I I'm at at a computer now, so I can actually read stuff. Uh, approve my poll request. So, um, one of the Redditors was talking about um his sort of expectations for people approving poll requests and stuff like that. And I think that like he had some good ideas, but I think the way that he presented it kind of made it seem like he just wants people to blindly like check the box and say submit.

So, I think it came across wrong. So, I made a video about that. And so, Feder Rico's first question is, I read on LinkedIn people saying they don't do pull requests. If the code passes a bunch of different tests and then he says like run automatically by uh the CI/CD pipeline. Uh so, continuous integration, continuous deployment for folks that don't know, uh then it means the code is of good quality. This avoids bottlenecks of having to wait for reviewers. I don't know if I agree, and this is his words, right? I don't know if I agree, although I don't have much experience. What are your thoughts? Um, and then goes on to say, "For context, I currently don't have anyone reviewing my code outside of myself and I review code from one other junior dev." So, great framing. Thanks, Federrico, uh, for the question. For folks that are new to this channel, uh, leave comments below if you want software engineering or career questions answered.

I'm a principal engineering manager at Microsoft. Been managing engineering teams for almost 13 years now. Uh, so I'm not saying I have all the best answers, but I will try my best to answer the questions you have. If you're not comfortable leaving stuff in the comments because it's public, you can look for Dev Leader on social media. That's my main YouTube channel as well. It's got C tutorials. It's got a podcast with other software engineers and ré reviews. So, you can have your resume reviewed completely for free. Costs me money because I have to get the video edited, but I think it's uh all for for good cause. So, uh, if you think these kinds of videos are interesting, um, I do a live stream on Dev Leader every Monday, except this Monday coming up. This might not even make sense depending on when you're watching this, but basically every Monday, unless I'm on vacation or sick or something, at 7:00 p.m.

Pacific. And generally, I go through code commute topics uh, in the live stream. So, there's lots of people that come over from Code Commute. Super cool to chat with you guys. So for Feder Rico's question, so um I have seen um I've seen people divided on poll requests and code reviews and I think the problem when we start having debates like this on the internet is like there's a lot of context missing. So to give you an example um like I think in general the process of doing some type of review is helpful okay like what that looks like in the implementation TBD um but that's going to depend a lot on the context to give you an extreme example um when I had one of my teams before Microsoft the digital forensics company I had worked with these guys for years and we had a small team we were building in the same product area for forever.

We were uh kind of we were so in tune with each other that like doing standups was almost like a complete waste of time. Like we we would call ourselves like agile. We didn't follow everything to the tea, right? But um you know, it didn't make sense for us to even do standups cuz we'd be like, "Yeah, we're just talking about the same stuff we've already like we would talk all day all the time about the stuff we're building." Um, so even for standups, um, it would be mostly if our like product owner just kind of wanted to sync a little bit more in depth. So it wasn't even like a real standup. It was just like a touch point with our product owner who was already like pretty in tune with us. But you know, sometimes if they were at conferences or whatever coming back like it might just be a good opportunity to catch up.

But point is this group was very much on the same page all the time. and I was managing this team, but I was also writing code with them and I had been for years. So, we were at the point where like a code review was like, "Hey, it's up." And like we would honestly just be spot-checking stuff like, you know, we we know that we're always adding tests for things like that's part of our team culture. Uh we know that we follow um you know, same design principles and stuff like that. So, uh, if someone was introducing something that was new or we hadn't really done before, we would already been talking about it. We'd be saying, "Hey, this pattern doesn't seem to really be working here. I'm going to try this other thing out." And we would go through it ahead of time. We would, you know, see a little prototype or something in action.

And then we'd be like, "Yeah, cool. Like, let's go ahead and do that." So, in this group, by the time it came for a review, it was like there's not like what are you actually checking for at that point? Like we don't we have we don't need to go looking for typos and stylistic things because like we didn't really give a because we're we're already so consistent that the amount of time that would be spent on that stuff like trailing whites space like we have llinters and stuff for that it like it it doesn't matter. Um but for us it would be like hey like just to give you an example hey like obviously you have test cases here like I was just reading through them like is there a situation where X could happen like should we have a a test on that or

um hey I remember when we were talking about this we said that because we were doing mobile forensics and that meant that we had to integrate with uh phones a lot right phones get pretty wild uh just in terms of like the different manufactur different behaviors and stuff like that. So, we might say, "Hey, I remember us talking about this. Like, do we have a concern that like there's a bit of a gap in how we're unit testing things here? Like, we have pretty good coverage, but is there a scenario where like we need to do something different?" We ended up having to uh sort of create like an integration testing framework with physical devices attached at some point because of conversations like this. So, just like looking for gaps. Um but by that point like you know we didn't have to go um do anything like intense in the reviews.

It was extremely rare that we'd be doing a review like I couldn't even think of an example if we were doing a review and it was like hey like redo this. Um our team did have interns uh almost all of the time and reviews I think were really good for the interns because they weren't on the team for a while. the codebase was new to them. We could use that as a teaching opportunity, right? Um but they also got to see how we operated in general. So they could see that we're always talking about the stuff we're building. To to um clarify as well, this was while um everyone's basically in the office. So I know there's a lot of remote work right now. Um, I let me say this. There's people that I work with outside of work that we embody the same type of thing.

Like, uh, we use Slack for our own stuff and we embody the same thing where it's like we're just always talking about the stuff we're building. We don't review each other's code. And it's not because we think there's zero value. It's because we have worked for so long together. This, you know, this other group and I, the second situation, we're even working remotely. We're always talking about different design philosophies, how we want to move in different directions, if things aren't working, how we're going to test things. We're already on the same page. The review is likely not going to show me much. So, we're just going to forfeit that. Again, not saying there's zero value, just that it's minimized for us to the point because one of the things here is like u that Federico brought up was like this avoids bottlenecks of having to wait for reviewers.

the group that I'm working with now, the group that I gave you an example of from when I was working at Magnet Forensics. I mean, the tradeoff was basically like we can be much more agile. We already have these things in place. We were of the mindset where if there's something that we need to manually be looking at that's not more of a creative exploration kind of thing like automation like automate everything because if we have to keep doing it as humans it's not going to scale. Um but that's not going to work in every situation. I'm not trying to say like hey it's just super easy just do it this way. But that's how we operated. um at Microsoft I would say the like I see really active reviews. I see a lot of stuff um being discussed in reviews but it's so I would say it's absolutely helping.

It's catching things. It's getting people to go back and design stuff like it's serving a purpose. But then I I look at this stuff and I'm like I've seen it work in ways where um this stuff is caught so much upfront so much further up front. Like by the if someone I'll I'll put it this way. I feel like if someone's putting code up for review and it's not like an early draft to be able to to talk about an idea. If someone's like I feel like I'm done. I'm kind of maybe I'm still writing tests but I want you to go review this or I'm am completely done. I've tested this and everything and like I want you to review it. If at that point people are like I want you to go redo this or this doesn't look right to me. I feel like our like software development process has failed.

Um, which might sound harsh because like we're using part of that software development process, the review to catch the issues and it did great, but the amount of wasted time and effort to be able to get that far before saying like maybe do this a different way could be avoided. And I say that because I've lived it. I don't have the answer in all of these situations to say, oh, like just like do step one, two, and three and and all of a sudden this is avoided. Um because I think this is a cultural thing and I can't dictate the culture on a team. I can make suggestions. I can talk to people and say, "Hey, like I know from talking with you in one and stuff, you find it frustrating when you know something's all the way in review. you've spent, you know, two weeks on something just to have someone tell you no.

Even though you had a design dock, even though like all these things, you're still being told like go back to the drawing board. Like you find that frustrating, right? Okay. Like what could we be doing? Like do you have thoughts on what we could be doing to change this up? A lot of the time this comes back to like more uh more frequent and earlier. Just whatever conversations that you might be having in a review, do those earlier and more often. I'm not prescribing how that's done. I'm not saying you have to have a draft like or you must get on a call or whatever. Just like more early and more often. I think that moving in that direction. You find whatever works for you in terms of the implementation. I think that that will save a dramatic amount of time and reduce frustration in reviews where someone's like, "Oh, not this way." I think what ends up happening instead is that people go, "Hm, this sucks.

I don't like when that happens, so I'm going to stop putting that reviewer on here. I'm going to work around them because they're the pain point." It's like, no, the the pain point is the fact that we're not collaborating on stuff earlier. So, that's my my general uh philosophy on that stuff. Um, so you know, for LinkedIn people saying they don't do PRs, I've lived the time with some teams where doing poll requests would slow us down and not add much value. But it's because these other things were in place based on our team culture where the value was minimized. Um, so what I want to say with all of this is that I think that what pull requests and code reviews add, there's a lot of benefits in there. And even when I was talking about these other scenarios, even if we were to review code, it's not that there was no value, but gating stuff because I forgot to mention, even if I was like, hey, what about these other test scenarios?

I might say like push your code through like it's fine. It's fine. You have it tested. We know it works. I've been talking to you while you're running it because you know we've been working to basically together on this stuff. I see it working. The product owner seen it working for for every like measurable thing that we have. This is good to go. Is there a missing automation test case? Like perhaps like push it through and then go add this other one. Just follow up with it. Or we might say cool. we don't have the right tech for that right now. Add it to the backlog. We want to sort of accumulate some data points around this to say we got to go build some automation around this. We need the framework and we'll revisit and we can add these scenarios. So, a lot of our culture sort of enabled us to be more flexible and not really gating each other even on pull requests and code reviews.

Um, and I realized like it's funny. I wanted to make this video and go to answer this and like my perspective is like not to cut out the poll requests and code reviews. Like not at all. I think that they are helpful and I I realize as I've been talking through this, it probably sounds like I'm almost against them, but that's not the case at all. like I am absolutely all for them, but I think that if you are in the groove of doing poll requests and code reviews and you're having conversations and and the reviews and stuff are helpful and they're catching things, the natural progression of this kind of stuff, in my opinion, is that we get to the point where we're like, hm, like I I I see it every time, every team I've been on that does them, it's like the pull requests seem to be a bottleneck or I seem to have frustration because I have to go back and redesign.

There's all these common things that keep coming up. And instead of going, okay, well then don't do pull requests, I say the pull requests are your your safety net. What are all the things that you find are inefficient or frustrating? And like how do we just move those checkpoints up sooner in your development process? I've made other videos on this where um to exaggerate this, right? forget the pull request. In other software development sort of workflows, I've I've lived and worked in situations where you finish the thing and then you go, "Great, it's done. Let me give it to the tester now." And then the tester in like 10 seconds is like, "This is bullshit." Like, "It doesn't work. Send it back." It doesn't mean that like the tester is the bottleneck and they're the bad person, so get the tester out of here.

It just means that if someone's going to be going through something like why don't you include them earlier because it's not like written as part of the software development law like if you know that they're going to be looking at this stuff include them. It's the exact same idea as having like a product owner saying go build this and you're like great and then I'm not going to talk to you for a month until I build it and come back and then show you and then you're surprised that it's not exactly what they wanted. Right? They might not even know exactly what they want. They might be saying, "Here's a problem to go solve. Like, I don't know the answer." And you're like, "I'll figure it out." You solve it one way and they're like, "I don't think that actually solves it the way that I need it." You just have more frequent touch points.

And while it's more frequent and there's more overhead for it, the amount of sort of issues or opportunities uh that you in amount of issues you reduce or opportunities that you um issues that you avoid and opportunities that you introduce. Words are hard. Um I think that like that is the direction I will always push people in. So you might get to the point where you're like coder reviews aren't really adding a lot. I wouldn't say like just cut them out then. I would just say like maybe they're an extremely lightweight thing, right? If um another thing on this too is like oh um people aren't reviewing my code. It's like are you asking them to? This is like one of the the most common ones I experience now is like ah like my review's been up for a day and no one's looked at it.

I'm like did you tell anyone? Well, no. I was going to wait. And it's like why why are you shocked? Everyone's busy. Everyone's busy doing stuff, but we all know that like the code reviews are gating code from going through. So, if you don't wait, just message people, tag people in the chat and say, "Hey, it's ready." I don't want to bother them. Well, I mean that if you don't want to bother them, like I don't know why you're surprised that no one's done it. Like, we're we're all a team, right? Like, if someone messaged you and said, "Hey, I have a review up. Could you get to it when you have a moment?" Are you going to be mad? Probably not.

But if they if the other person hasn't been engaging you for a week and they're finally fed up and they're like, "No one's looked at this for a week." And they're like, "Hey man, you got to look at this now cuz it's been a week." You're probably going to be like, "Screw you. I'm busy doing stuff." So, if we just all like communicate more frequently, it solves or improves, I don't want to say solves, it's not really fair. I think it improves so many of these like friction points in a typical software development life cycle. But in particular around reviews, I think this is one I think I recommend doing them. Um I recommend uh having the hard conversations that come up in reviews, right? People are disagreeing about stuff, whether it's like, you know, people are like, I really care about the whites space. And someone else is like, dude, we're wasting so much effing time on whites space conversations.

Like why are we doing this? I think that that's a complete waste of time. But if that's a sticking point for people, let's talk about it. How do we solve that? Put a liner in. Done. Move on. Never have the conversation again. You don't need to, right? Like I think we always try to avoid these like difficult conversations cuz it's like, oh, people are going to be disagreeing and like we're always going to be disagreeing about certain things. the guys that I was talking about that I've worked with for forever, we disagree on stuff, it's not like like for the most part we're on the same page agreeing with each other because we've been doing things the same way with each other for many years. Doesn't mean we don't disagree. So, we have to have those conversations. Like, we know that we want everything to be better.

So, it's just a matter of like understanding what everyone's saying and then saying, "Cool, like we want to move forward on this. let's find the path forward. Um, the more that you have those sort of difficult conversations and don't try to avoid them, the easier they get. And I'm saying this as someone like I don't like having difficult conversations. I'm an engineering manager almost 13 years doing it. I don't like having difficult conversations. I know they have to happen though. So the more you do them, it's kind of like I don't know for people with public speaking, right? You're like, "Oh, I'm nervous to do it. I'm nervous to do it." And then you start talking. talking like it's actually not so bad. Like it's going to get better. Um anyway, I think that's what I have to say about this one. Um thanks Federico for sending this in.

I'm going to do a follow-up video right after this one. Um it's going to be related, but I kind of wanted to talk about it separately. So, thanks for watching. I'll see you next time.