Developer Only Adds OTHER Teams To Reviews

Transcript is auto-generated and may contain errors.

Hey folks, I'm just driving to the office here on Wednesday. I didn't get my videos in this morning going to and from CrossFit. Um, so I'm going to do two quicker ones here. You might not be able to tell when I do them back to back like this, but just a heads up, that's what's going on. So, we're going to experience devs for both of these. This topic is going to be about uh code reviews and an engineer that is basically just putting other team me or uh individuals from another team onto the poll request or the code review. So not including team members basically. And the additional detail that this person offered was like their manager seems to like treat this person like a rock star. So like doesn't doesn't seem to acknowledge it or give a about it. How much of that is true like we obviously don't know because it's Reddit and we don't see the full picture.

But I thought it'd be interesting to talk through because we've been talking about uh polar crossing coderies a little bit more recently. And so let's dive into it. Uh, in general, I don't think it's great practice to like not include team members on poll requests and code reviews. And so I poke through the comments to see like do do other people have a different take on this or what's going on? And uh, yeah, cat hair on my face. The uh one comment that I saw that kind of stood out to me was like again we don't have actual context for what's happening in reality. This person said maybe you know maybe that person given their seniority and tenure maybe they actually know uh the individuals that they're adding on to those poll requests and code reviews like maybe those people have actually worked in that area before.

Um, so maybe what seems like they're avoiding the team members, they're actually putting in people that have like knowledge of the domain from before. Now, just to cut myself off, I'm not suggesting that means it's a like that alone is like reason to not include team members, but I actually think that is a really good reason to include people from different teams. So, um I'm not necessarily like uh taking that statement and then saying therefore I fully agree that he's he or she's absolutely doing the right thing. I just think that like that's actually a pretty good, you know, reminder for folks is like maybe you don't actually have some of the context in that situation. Uh and the person who has more tenure uh knows some of the other individuals that have worked in that space. and they're trying to get their perspective as they're making code changes there.

So, I think that's that's pretty interesting. I like talking through this stuff because like there's just different perspectives. I don't think that on the surface I would have thought about that. I think it makes sense. I've seen this kind of thing happen a lot. Um especially like the two teams that I've worked on at Microsoft in Office 365. There's a lot of code that's really old, right? Like there's um there's stuff we're like a lot of Microsoft technology if you think about Outlook and Exchange and stuff like that like there's stuff that's been around for like you know it's older than some of the engineers on the teams right so to go like hey look I have to go touch something that's way back and you know this person like oh yeah they're still at the company they're still you know they might be on a different team or something like I might go I say I but like the person might go add them.

That was the longest transition of a light. I like stopped cuz I could have or shouldn't have gone through. It was like three more seconds. Um so like I I think it's a really common thing that happens. So good to call out. Um there was a lot of people and I think this does make a lot of sense like you can work um not work around this problem but like you can you can minimize this being a problem. that person just ran a red light. Uh by actually using some of your tooling and it depends what you're using, but like you can set this kind of stuff up um you know in whether it's uh GitHub or other tools to be able to say look like there's there's people that like are automatic reviewers, right? So if you are touching certain files or paths um automatically put these people on.

Like I know like we use Azure DevOps at work and there's area owners right so automatically if you are touching some of the files like it will just include the people like some of the team members as reviewers or it'll add the team and then like you know one person or two people from the team depending on the policy they need to like sign off because you're touching something that they're an owner of. And so like that just might be a a really loweffort thing. I saying loweffort. I mean low effort depending on who you are and your experience doing it. But in the grand scheme of things, probably a pretty loweffort thing to do that can like minimize some of that. Now that comes with other changes in team culture and and process and stuff like that.

But you know if one of the issues is like the team is not getting exposed to some of these changes then like that might be a great way to just like you know the tooling kind of builds it into how your team operates. So, I thought that was a great suggestion. There's a lot of people that were like, "Hey, like you don't even need to talk about this. Solution is this. Move on." Um, so I think that is like a technical solution uh or at least a uh an option technically to go um you know perhaps minimize this challenge. So something to consider. There's a couple of like other angles I wanted to think about this problem from.

Um, and uh, there is sort of another sort of theme of comments around this, but one of the reasons that the the poster was kind of complaining about this, and I I think it's like a fair reason, is they're like, "Hey, if they're not adding our team members, like they're like for me uh, selfishly like if I don't get to see some of these changes coming through, then I don't get to learn the code, right? like that that stuff's kind of changing right underneath my nose and I don't even get to see it. So like what the heck, right? And like and the solution to that is really just add me to the poll request so I can see it. So, one of the themes of comments around this was like, hey, like like if your goal is to like learn the codebase, they were kind of saying like that seems like a pretty crappy excuse.

And I thought that was an interesting take to say like basically that what that person's saying is a is a bit of an excuse, right? Um because I agree with the person like I think that you know it's a super loweffort thing to just toss some team members on it. So even if it's purely for visibility, right? Um, there have been situations where we might have like new developers joining the team and it's like realistically we're not expecting that you're going to get put onto this code review and like have like tons of like really and I don't mean to be condescending here but like tons of really valuable feedback because you're probably like I just have questions right now and that's totally cool, right? Like if you if you haven't worked in the space you might not even know the language. So you don't know the language, you don't know the domain.

And it's like realistically you probably aren't going to be like reading someone's code and being like ah yes like you've totally missed this scenario like go back and add the test for it. Like probably not. I'm not saying it's impossible but probably not. But you might have questions and so you know I think it's a great practice to just make sure that the team members can see changes coming through and even you know being clear with people like you know if you don't have comments or like feedback that's totally fine like you can leave comments and questions right depends on your team culture and stuff but like if you're reading stuff and you're like man I have no idea what's going on here or curious about why we follow a pattern or or whatever else, like leave comments or message the person, whatever. It's I think it's a great opportunity to to get some learning.

And so that's why I like partially, you know, agree with the the poster. But I think the other people that are kind of saying it's a bit of a lousy excuse is like I I also think they're kind of right because if your goal is truly just to learn the codebase, like you know, you can see the poll request going up. you might not get a notification for it, but like there's nothing stopping you from just looking at the pull request. So, I thought it was interesting cuz it's like it's not it's not wrong. Um, depending on your tooling and setup. Why is this I didn't check the traffic. Okay, it's an extra 15 minutes of traffic for like the next mile. This is probably a an accident. Can't win, man. What does this time say on this sign? I'm not going to Belleview. That's 45 minutes.

Both 27 minutes. Depending on what part of Belleview, it's probably I'm probably on the 45 minute mark. That's what Google say. It's like 9:30, man. like I don't want a 45minute commute at 9:30 after rush hour is stupid, but I get to hang out with you folks and that makes it better. Um, so yeah, I think that if someone's truly motivated cuz they want to go learning and stuff like technically your tooling should allow you to go viewing poll requests and stuff like that. So, um it's kind of a oops kind of a bad excuse, but um like I can see both sides of that. Now, the the one part that I think is kind of interesting, and this might be where I I'll talk about this a little bit more before I wrap up and make the next video on the next topic, is like the it seems like the manager's unwillingness to to kind of do anything about this.

And I I kind of look at this from two fronts. One, did the original poster even talk to the other person about this? This goes back to a handful of recent videos I made recently where um you know, one of the things that I always try to remind people that I work with, right, that I'm coaching that are are team members that report to me, it's like there's always going to be interpersonal conflicts and friction in your career. Always, right? It's like the goal isn't to try and like run away from them and avoid them. The goal is like to understand when they happen like how do you navigate these things and like get to a point where you can reduce that friction and and make progress. And there's obviously not like a one-sizefits-all here. It's not like a you know always just follow step 1 2 3 and it works perfectly.

Not like that. But the reality is you need like skills and experiences and practice in kind of navigating this stuff in order to get better at navigating it. And one of the things that I tell people is like look like I'm happy to support you if you need like if you need me to talk to someone and like we can talk about what that looks like. Do they need anonymous feedback? Do you want me to like structure it in a way that like mentions you? Like whatever it happens to be, right? I don't want to set someone up and they're like, "Oh my god, like I can't believe you said that to that person now. They're going to come after me." Like, um, I want to make sure that whatever path we're taking, they feel comfortable.

But I always say, I think the most effective thing, not only for like making progress on this thing, but the most effective thing even beyond that in terms of gaining the skill and the experience is like go talk to the person. Go do that. And I realize it's like it's easier said than done because if it was so easy then people would have just done it. Um but is what it is, right? Like you have to kind of practice it in order to make some progress on it. So I think this person should probably go talk to that individual. And then um probably the other thing that I mentioned is like I find it kind of weird that the manager isn't doing anything about it, but I don't really know how this person approached it with their manager.

Did they just kind of like casually mention it and they're like, "Hey, like would be nice if people on the team did this and the manager is like, "Yeah, I guess like that makes sense." Or like I don't I don't know like sure. and then that person's interpreting it like the manager can read their mind that like this individual specifically is not doing it or that there's actually like a team culture problem where that's not happening like we don't know how that topic came up. So, um I would recommend that this person talks to that individual, sees how they can kind of clear the air on it. And if that's a team culture problem, then like yeah, like start, you know, culture has been another topic recently that we keep going over in in these videos. And uh you don't get to say what the culture is.

You have to kind of live out the actions and live it uh by example. And then culture is like what you observe from what's happening repeatedly. So you need to be able to demonstrate and build momentum that it's like a thing that people want on the team is to add other team members to code reviews and poll requests, you know, publicly praise people. Hey, thanks for adding me to that. Like we'll check, you know, um or you can say like, hey, hey folks, I added you to this. Thanks so much. I really appreciate whatever. Like kind of just like demonstrating to the team like why it's a good thing and then getting other people bought into that and then it builds momentum, right? lots of different ways to do this, but um I don't know how clear they were with their manager about this. And my guess is that like probably not clear enough or um or sort of explaining why it feels like such a pain point.

And I would uh encourage them to talk to the individual, then revisit it with their manager. But overall, I'm gonna wrap it up there. Um, I actually just realized I was glancing over cuz it looks like my microphone's about to die, too, which is kind of dumb. But anyway, thanks for watching and I will see you in the next video.