How do I NOT sound demanding on a code review?

Transcript is auto-generated and may contain errors.

Hey folks, I'm just headed to the office. It's Friday morning. Got a busy day. Going to be like people conversations for hours today. Um but it's good. So it just means I got to get to the office at a reasonable time. So we're going to experience devs for a topic. I do have a couple comments to um to respond to and I'll try to do those on the way home. The experienced dev's topic today is going to be on code review feedback. And basically, I didn't even read the comments. I didn't read the full post. I just thought it was a good topic. It was uh posted as how to give code review feedback without sounding bossy. And I just want to make sure my camera's charging when I stop here. And now it is. Good. So, um, I've done a couple videos on this topic before.

I've made LinkedIn posts and stuff like this, and I find that people are pretty divided, which kind of surprises me. Um, but the way that I've seen this come up in social media is that um, when people talk about code review feedback and this kind of stuff is that I find that there's an audience that is more interested in coaching and like being helpful. And then there's another audience which is like, we don't got time for your Like either figure it out or like too bad like you're wasting my time on the review and like we got to move forward. So, like just do what I say kind of thing. Um, and it's like it's not about feelings. No one no one should have feelings. If you have feelings, then you're like doing it wrong. So, I just wanted to to talk through like how I like to approach code reviews and try not to sound bossy and and being helpful.

And then uh we'll see how it goes. So, friendly reminder, if you're new to the channel, this is uh primarily driven by questions you submit. Uh, and then when I don't have a queue of questions, I go to Reddit. So, if you're interested, leave a comment below with your question. If you uh want to send in something that's either longer or you don't want to uh you want to be kept anonymous, just send a message to Dev Leader on social media. It's my main YouTube channel. It is also um where I'm posting like C tutorials. Uh there's resume reviews, things like that. There's a live stream every Monday at 7:00 p.m. So check it out. I need sunglasses cuz uh Seattle has sun apparently. Let's see how that goes. Cool. Okay. So, um to start things off, I'm I'm of the mindset like uh I always want to try coaching and helping.

I just want to preface my entire um talk on that because I tried to mention that from my experience sharing this kind of thing online, I see sort of like a few major camps that take different perspectives on this all. That's my bias. We'll try to talk about different sides of this, of course, but um I'll lead with that. So, in general, um like what's the what's the point of a coder, right? Like I think there's a handful of different reasons and depending on your organization, how your team is, uh your beliefs, especially beliefs like that the team agrees on, there's different like goals in a in a poll request or code review. Um the probably the universal one is that this is a a gating tool for quality.

And again you that might even be argued someone like when I first got introduced to code reviews I was at a company where the code review happened after the code was merged which seems kind of weird but um so it wasn't used for gating but I would say generally you have like a gating mechanism and that's to help enforce quality. Okay so um in a general sense that's what we're after. uh that means that ideally we're introducing code that is uh not degrading the quality of the code base right um or if it is it's understood so we're making a conscious decision about what's happening so that's you know one major part uh I would argue that um based on how a lot of teams are structured especially if you have uh you know more junior people on the team newer members to the team

that this is an opportunity for for coaching Personally, I think it is I would say on a team that is much more mature where like and I've worked on teams like this where the members of the team are much more mature especially working together. I don't mean mature in terms of being like a mature adult. I mean um you know effectiveness working together. They're not new to the team. They're not new to the uh code base or the domain. Uh they they have tenure there. Um, I would say when you have the newer people on the team, there is an opportunity for coaching. And that's because yes, there's lots of patterns uh for people to learn from, but the other part about that is that there's often drift. So, they might be looking at the wrong pattern. They might not have known a pattern exists. They're not familiar with the code base.

So, there's opportunities for that. there's going to be coaching opportunities around like um you know how how effective a scenario is like did we optimize for the right things all this kind of stuff and uh in previous videos I've made I've talked about hey like if you're noticing you spend too much time on this stuff in the review try to work on like earlier feedback points right like design specs up front uh draft PRs early on to show like the progress and stuff like that but my point here is that I I find that there is a really good coach ing opportunity. And if you're finding that that's actually becoming painful, like why do I have to be having these types of conversations so late, I would say it's not that the tool is wrong, it's just that the in my opinion at least, it's not that the tool is wrong, it's just that the conversation should be happening earlier.

Like it ends up being more friction because it's so late in the development process. So, um, dating for quality, uh, coaching opportunity. Um, and then I guess the other thing to mention is like knowledge sharing. Um, I don't know if that's necessarily a primary goal, but maybe that's arguably a side effect. So, you get some people on the team that u might not have worked directly on the feature, but they're familiar with like the codebase itself. They can give uh perspective and they can also learn about it. But with that out of the way, and again like I'm not saying you have to necessarily agree with all those things. I'm just trying to frame up like this is how I'm thinking about this stuff. And obviously they're generalizations. I'm not uh saying every team or every person is like this.

But if we have that as a some groundwork to start with the um the reality is that if we're leaving comments on code reviews like there's often you know multiple reasons for this kind of thing but I guess generally a comment is not just hey great work on a code review. Um, although I would honestly say that especially if you're trying to lean into coaching for more junior people, if you notice that they've improved and they started doing things that you've given them feedback about, like I would say absolutely maybe leave a comment there and acknowledge that you're noticing the improvements. But that's a pretty rare thing. It's not like a pat on the back kind of session. Um, I'm not here to say if that's right or wrong. I'm just saying that's not really common. Uh sometimes it's like nitpick comments, right?

Like, "Hey, uh if you have to go back or whatever, if you're already making changes or for next time, uh maybe maybe improve this name or um you know, the way this is formatted could be a little bit better or like you know, things that it's not going to it's not a deal breaker." Um now, those are very subjective a lot of the time, right? But uh the idea is that as the reviewer, you're not willing to gate the whole the whole poll request or the whole code review on that particular comment. So that leaves us with the last part which is like you have an opinion about something and you're like I need to see a change here or like I'm not comfortable progressing until I see a change. And I think fundamentally this is where this Reddit post is kind of getting to, right?

Um maybe around the nitpicks they feel like they're being bossy. Uh, so we could talk a little bit about that, but I think primarily it's like, hey, I don't think this is like I'm not comfortable with this and I need you to go change it for me to be comfortable. And I think this is where you can get into more territory where it feels bossy. Um, so just to kind of bring it back to what I said at the beginning, uh, I've seen this on social media where sometimes people take the stance where they're like, it doesn't doesn't matter how it comes across because it's not about feelings. It's supposed to be it's supposed to be objective. Like this is the, you know, the the way the code is supposed to be moving forward.

uh it's not a personal thing like having feelings about it is wrong because like it's not about you it's about the code that's there and I wanted to start by saying like I this is absolutely not the stance I take but there are parts to this philosophy that I I can agree with like for example the code review comments that are left they are not supposed to be personal Right? They're not supposed to be. People should be leaving comments about the code that they see, not the reviewer that left them. Right? You could have a junior dev that put the same code up uh and they're new and they're kind of shaky and uh the most experienced dev on the team could put the exact same code up. If there needs to be a comment about it, like it shouldn't change depending on who wrote that code.

It shouldn't change depending on on you and the uh the relation the working relationship you have with that person. Like it should not make a difference. It's about the code that's there. So I agree like that that makes sense. Um kind of like that uh the the philosophy around like we want to treat it as like more of an objective thing. I think again makes sense. Like that's the goal. It's not about like it's not supposed to be about feelings, but where it breaks down for me is like um this is what people want or this is what they uh this is how they perceive code reviews, but it's it's not actually reality. Okay. And I think this is where I say I understand that you don't think it should be something that's taken personally. Like it's not supposed to be. You're talking about someone's code.

It's just it's code. It's literally text. But the reality is that people do take it personally. Okay? like the what people end up miss in my opinion on this is when people take this stance so uh so strictly I think that they're failing to realize that there are people that do take it personally and unfortunately you don't get to dictate that like you don't get to say like no you don't take it personally or like no you don't have emotions about this you don't get to say that like it's just it's just the reality right so the where this is difficult is that people have a perspective on this and I don't disagree with it being like the goal state but it is also not the reality and the reason that I know it's not the reality is because I've spent the better part of

like 13 years coaching the people on the receiving end of this where they're like I don't want to put my code up because so and so was an to me. I don't like working with so- and so. It's really difficult to work with soand so. A lot of the time, these types of people are the ones that are like, "It's not personal. Don't take it personally. You're not supposed to. I don't care. Like, it's not an emotional thing." But they're not wrong that it's not supposed to be, but how they come across creates a problem. So, I wanted to kind of to to talk about this entire topic because when I saw it laid out like how do I not come across as bossy to me this is not I haven't read the comments. I'm sure there's going to be people that are like it's not about being bossy or not like if the code's bad or got to be changed go change it.

But what I like about this is that to me it suggests that someone has awareness that they're interacting with people So, I will say it one more time, and I don't I honestly don't know if I'm articulating this clearly. So, uh you know, if you're willing to type in the comments if this makes sense to you, or you have a different way that you might say it, let me know. Um cuz it's not it's weird. It's like something I believe in, but it's not something I say out loud a lot. But the what I'm trying to say is that code reviews should be objective. Code reviews should not be about emotions. um code reviews should not um be taken personally and I use the word should in all of that but in practice this does happen and you do not get to tell other people that they're not allowed to have feelings.

You just don't get to do that because it doesn't work that way. So instead of being like, "That's my expectation. Too bad, it's just not going to work for you and people are probably going to not enjoy working with you." Now, I'm not saying, just to clarify before I move on from this, I'm not saying that you need to um then never say anything or you always have to tiptoe around it. like you can find a balance, but um basically ruling out that people have like feelings about comments that are left. Um sorry man, humans it's just it's reality. So figure it out. How to not be bossy in my opinion is to structure things like learning opportunities. And you can do it uh multi multiple ways. But when I say learning opportunities, it can be learning opportunities for you and the person. So this might change depending on um I don't know the the difference in in experience let's say between the individuals.

Just to draw like um some more clear examples here. If you're a more senior person on the team trying to give feedback to a more junior person, right? you are probably in a position where you're like, I see something. I want to be able to help this person and get them to change it without sounding bossy. I would honestly just structure it like a learning opportunity or it's like, "Hey, see what you're doing here, right? See what you're trying to accomplish." And then instead of just being like, "And it's wrong, so change it." It's like, uh, you know, we've seen these types of patterns and here's something that comes up with them. why we try not to do that and we try to use this other thing instead is for these reasons. Um you can find you know examples of this here here and you know if you want help walking through how to to do it this other way instead let me know kind of thing.

Now whether or not you write that all in a a code review comment or you know you say hey we can chat about this offline like but here's a you know highle thing and then you put the information back in the code review for others to learn. I don't care how you implement it, but the point is like you you treat it as an opportunity to be like, "Hey, I don't I'm not just telling you to change it because um you know, I tell you what to do when you press the keys." It's no like this is a pattern that we need to move away from and I would like for you to know for the future so that you understand why. And that way, you know, you don't you don't feel like you're just being told you're wrong. It's like it's a learning opportunity for being better in the future.

Um, this can even happen, you know, with peers like people at the same level kind of thing. Might just be that you've worked in different parts of the code or someone someone forgot or they weren't aware, whatever. But just treating it like a learning opportunity, I think, is uh is a good way to do it. Now, I said learning opportunities two ways. If you start to feel a little bit awkward about like, well, okay, you said that for more junior people, but what if someone's my level or maybe they're more senior than me and I'm feeling like I'm seeing something that's not not okay. Um, you could try to ask about it, right? I'm not saying you have to do it this way. Like if you're if you feel comfortable and you're like, I know that this is like a thing that needs to be changed, you could draw attention to it.

That's totally fine. It might be someone uh something that they missed. It might be something they they also weren't aware of, whatever, right? Uh if you're uncomfortable doing this, and I bring this up because I've had people say to me, "Hey, I'm more junior on the team. How am I supposed to leave code review comments?" Right? Like one way is to to be curious. It's a learning opportunity for you. So, you can say, "Hey, um, by the way, use your own words." I I realize because I've I've had conversations about this on social media where people have even said to me like, "No one talks like that in a code review." And I'm like, "Dude, I literally write comments like this." So, you can write them however you want. I'm not telling you how to do it, but you could write something along the lines of like, uh, if I understand correctly, here's what this code is doing.

and then say like I would like to understand better you know for other types of scenarios like does this you know and you could give them some examples like is this is it safe is this what we should be doing and just trying to not not structure it like hey go go do this I'm telling you what to do you structure it more like I'm raising awareness to this I'm trying to understand it and that way it becomes something where the other person doesn't have to defend right way in both of these examples I'm giving where it's a learning opportunity. The only thing I'm trying to optimize for is reducing a defense um like mechanism that comes up right when you tell someone go change this or I don't like this or whatever. Uh yes, like I was saying, some people will start to take things personally even though they shouldn't.

That's okay. Um, if we can reduce the defensiveness that comes up, then it becomes a lot more smooth. That's the whole meta point here is like little things that you can do. And I encourage you, like I'm only giving you some things to think about. I highly encourage you to think about your working relationships with people and just think about like how do I if I want to approach a conversation like this in a code review and make suggestions. One of the things to try and do is reduce the the defense uh mechanisms that come up when people are told do something a different way. It's like a it's a natural reaction for people to do this. So, it's not a matter of like, oh, we need to avoid it at all costs or this is wrong or it's bad. It's just like, nope. It's very natural for people to want to resist, right?

You did it away for a reason because you thought it was the right thing to do. Unless you did something and forgot or whatever, but primarily it's because you thought it was the right thing to do. So when someone says no, you're like, well, like I thought it was the right thing to do. So you want to resist the the other perspective. It's very natural. So anything that we can do in little increments to try and reduce defense mechanisms, I think are helpful. That's why I like the the learning opportunity approach. Um, I would say too, um, like a strategy is like I I kind of mentioned like the the nitpick kind of comment. Um, I would try to find ways on your team to be clear about your your expectations as a team with that. I I've mentioned in previous videos that especially now as an engineering manager, like I'm not writing the code in the team.

And when people put me on to reviews, it's pretty rare that I am just all out gating uh a code review, right? If someone had no tests or something like that based on the circumstances, I might be like, "Hey, like you should go you should go do that." Um but even with that, like I might say like, "Hey, I notice there aren't any." So again, it might depend on my level of trust with the developer and their level of experience because in some cases someone might say, "Hey, look, like based on how we're making this change, like we we need to do this in place. We're going to validate something. We can come back and, you know, update our test suite to make sure it supports things like this." Whatever. There could be a million reasons. So, I'm not there to to stop people, right?

At this point in my career when I'm working with my team, if they put me onto a poll request for feedback, one, if it's C specifically, then I can give them lots of constructive feedback on how they're writing things. If it's in other languages, that starts to drop off pretty quick just because I don't actively write in other languages. Um, but there's still things I can pick up on. But primarily what I'm doing is just drawing attention to things that they could potentially improve. All right. Hey, readability here could be improved. Like, you know, nitpick, nitpick, nitpick for the most part. And uh, nitpick and awareness, but pretty rare that I am just like all out gating things.

So, I think that's another thing when it comes to feeling bossy is like I think you need to ask for yourself like do I actually give a like that I need to stop the entire code review for this or is this again like a a teaching opportunity just to be like hey like for next time this might be a better way or for next time like um you know more clarity in the naming or whatever it happens to I would say early on, uh, this is just my opinion. If you have like a newer member to the team or they're more junior, uh, I would, my my perspective on this is like I would be pretty critical on the first reviews, right? The nitpicks should like almost shouldn't be nitpicks. They should be like, "Hey, like go change these things." And the reason for that is like setting an expectation pretty early.

Again, this is just my opinion on it. I think that's helpful to be like, "Hey, look," and and give people a heads up. It's like, "Hey, your first review is probably going to be loaded with comments, but like don't this is like literally so that we can teach you about how our code base looks and is structured. So being more critical and like hey like you know naming convention we have is this obviously if you have linting tools like please like use linting tools but you know readability here's things we do for this uh this pattern like we have it in a couple spots but like try not to use that whatever it happens to be I would say like be a little bit more critical in the first one so that they do go back they do make the changes and that they have this opportunity to have that that pattern, the the different learnings and stuff reinforced.

Come on. You're this person's trying to merge, but they can't make up their mind if they can fit. Come on. And then from there, right, like there might be things where you're like, "Okay, like in the future that's probably a nitpick kind of comment." But, um, in terms of sounding bossy or not, like sometimes I find that people come across as bossy on reviews because they in instead of like adding what I would call value to a code review, they are the llinter and it's not a nitpick to them. They are the llinter and it's like loaded with just like these small things that I'm like honestly the value add to that versus the time that everyone's spending on this is like basically zero in my opinion. And that starts to feel kind of bossy because I'm like you're very focused on something that I think is not necessarily adding a lot of value.

Um, let's see. What else do we got for not coming across as bossy? I would say being open to like conversation about things. So throughout this I've been saying like you know you can use it as teaching opportunities but um like I don't know maybe just taking the perspective where when someone you're leaving the comment especially if it's going to go back and forth like part of it is like when you're feeling bossy it might be that someone disagreed with you and you're like no you need to go do it this way and you're like how do I make it seem like like I'm the right person here and I don't want to I don't want to come across as bossy but I still need you to do it. I would say like yeah like maybe take it offline from the code review and be open to the conversation about it, right?

Um there might be patterns that um let's just make up an example, right? New person the team is saying uh you know they've done something and you're reviewing it and being like hey we don't use this pattern and they're like well no we should. Instead of just being like, "Listen, newbie me, you're wrong. Like, do it my way." Um, hopefully no one talks like that, but instead of getting into a mode like that, be like, "Hey, cool. Like, let's chat about it offline." Um, and then be like legitimately be open to their take. Don't just use it as like a grilling session. Um, I mentioned like the learning opportunity thing, but this might also be a learning opportunity for you. Nissan 370Z trying to tailgate me and now racing through traffic. Excellent. Did I say 370Z? Did my Canadian come out? 370Z. Is that better? Yeah.

I don't know. Like I don't I just I feel like the the bossiness thing is relatively easy to address when you start treating people like people is my take. Like that's maybe the the overall point with all of this, right? is like I like thinking about things as coaching opportunities and learning opportunities. People have feelings on things. being aware of that and ultimately like if there's some weird battle between like you feel that really strongly that something needs to be enforced and you're getting push back on it like I think that becomes the sort of the hardest conversation but I I think you need to figure out like is is it actually worth it at the end of the day? If it is, then like I don't know. Like you want to think about how to address this stuff earlier is kind of where I shift to.

How do you how do you keep someone like from falling into that pattern? How do you what's the other way to say this? Like how do you get like push them into the pit of success? Right? It's it's easy to fall into the pit of success like that. You want to make sure that they're guided into that. So instead of uh like falling into these different patterns that aren't good and they happen late and now you're creating these situations where there's going to be conflict. How do you you know it could be even in your code design. How how do you have your architecture set up such that you know you're guiding people into these right patterns? So something to think about, right? It's I'm not saying it's trivial, especially if you're in a big old code base, but something to think about. And the same thing happens with the processes you have, right?

I've had conversations I have conversations about this like on a regular basis with every single team I've ever worked with for over a decade, which is it really sucks when I feel like I'm done and I've worked so hard on this code and it goes up for review and then people are telling me to rewrite it, right? some some flavor of that. And in my opinion, the answer continues to be if you're going to get that feedback, I think the only reason it sucks is that you got it so late after doing all this work. So do less work to try and get the similar feedback because I don't think a lot of the time that people complain about like they're upset that they got feedback in general. I feel like that's a pretty rare thing that comes up. People usually are like it's not not so bad, especially if you get it early.

But the problem ends up being like I just busted my ass on this and now so and so is like hey go change all of it. It's like, no. Like, it works. It's been working. I've proven it works. It's tested. Like, I'm not changing this, man. Like, that's I find usually why people feel pissed off about it is because so much effort went into it already. So, again, how do you try to get feedback like that sooner with less work? This is where like not I'm going to rock some rock some boats here, but um when people talk about like agile and all that, like the one concept that I just really like in general is this idea of early feedback. In this case, it's early feedback with your developer peers. You shorten that feedback loop, you can get agility Otherwise, you wait till the end.

You get feedback and you better hope you got it all right or else you're going back and doing it all again. So, anyway, I hope that helps. I realize it's not I don't know like a simple answer. Just don't boss people around, but some some things to think about. So, see you next time and hopefully in the next videos I get back to some of the comments. Take care.