Should I Give Honest Feedback To My Software Engineering Peers?

Transcript is auto-generated and may contain errors.

Hey folks, we are going to experience dev subreddit. This one's interesting, especially given the time of year. Um because this one's saying, "Hey, it's end of year performance review time, which I mean this is kind of different everywhere, but whatever." Um I think there's this kind of thing generally happens a couple times a year. um main intervals for a lot of companies, but their main question is like is there any point in being critical and this is regarding peer feedback? So they're kind of asking like they understand that you know their feedback is going to be seen taken in probably have some type of effect on someone's um performance right and a lot of the time I would say this isn't like the number one deciding factor or anything like that with promotions, rewards, that kind of stuff. But it is a a factor.

So, just to give you an example, like if I had someone um who had a lot of really positive feedback from their peers, that could make it, you know, uh potentially an easier conversation for me to have with like my manager, my skip level manager and uh other peers if we're trying to figure out if there's, you know, uh push to kind of stretch our budget kind of thing. It could work the uh the opposite, right? And it's kind of tying into what this person's saying. So, if if uh myself or another manager was like, "Oh, I have this employee. They're so amazing. Here's all the awesome things they do." And then it was like, "Okay, well, how are the you know, how do they work with their peers? Like, what's that look like?" And then, well, all all the feedback is like, you know, got to work on this, got to work on that.

Uh that could be something where it's like okay well hold on like we should talk about those things right like what is your plan to work with this person on those but I wanted to talk about like a couple different angles of this because yes I I do think that peer feedback uh is important in those conversations. I do think peer feedback, you know, I don't think that it should all just be like, you're the best person I've ever worked with because it's also not helpful, but I understand why this person's kind of like, look, man, like I don't want to screw anyone over kind of thing. How do you balance it? And so the the thing that I would say to this person kind of super high level is especially because uh you know I scan their post.

I I kind of wanted to talk about it in general but from scanning their post I think that they're like I kind of think I need to give some people some some critical feedback but I don't want to screw them over. And I would say like, does it feel like you're about to give them this feedback for the first time? Oh my god, this truck is huge. Okay, he's got lots of space. Um, does it feel like you're about to give them this feedback for the first time? Because if so, that might be kind of shitty, right? The first time you're ever going to give them some type of feedback is like around performance review time. I don't know how how long you've been sitting on this feedback. Like, did you literally just wrap up a project and it's very timely still, in which case maybe that's not so bad.

But if you're like, "Yeah, you know, like 4 months ago when I was working on this thing with you. Oo, I wish you would have." And then you're going to go dump that. Like that's kind of right? So, I would I would think about it less from the perspective of like I want to give this person some feedback and I think it needs to be constructive. I don't want that to wreck their promotion opportunity or rewards opportunity, but I think they need to hear this. I would look at it more like is this timely relevant feedback? Because if it's not, do you have other ways like going forward that you can do that so that when you do need to have it documented and written down, it's not a surprise?

Because I would certainly hope that if you're giving constructive feedback to someone in a forum that their manager can see that their manager does talk to them about it and they're like, "Hey, you know, like some of your peers or one of your peers said blah blah blah and let's talk about that." If that person's like, "Dude, what the hell?" Like, "Where is this even coming from?" That's probably like an indicator that you need to be trying to share feedback earlier. This is the exact same kind of thing when we talk about managers and employees being aligned on things. You know, imagine it's uh rewards time and for the first time your manager is like, "Oh, I know we've been saying throughout the whole year like yes, you're on track for promotion, but and like here's all the things that I wish you were doing for the last 12 months." And you're like, "Well, why did you not bring that up with me?

Why would you tell me I've been doing good and I'm on track if there was like six things that that you think that I should have been doing differently?" Right? Why is this the first time? Kind of the same idea just coming from peers. It's a it's crappy to get feedback that is um that feels very delayed. Uh it's already difficult for many people to take feedback constructively, right? And uh most of us in general like when you first hear feedback, your reaction is you want to be defensive. It's I think it's like a normal human kind of thing, right? We want to kind of protect ourselves, but for some people that could be like seconds of feeling like that that's not a good feeling. And for other people that could be longer. So, I think at the end of the day, if you're able to to allow yourself to hear some of that feedback and digest it, it can be very helpful.

um a whole other conversation about whether you agree with it or not, but like the point is if someone's sharing feedback like that, that's there's something that they've observed and there could be something uh helpful for you to learn from that. So, is it worth giving constructive feedback in these forums? Right? Are you screwing people over by doing this? And I at least tell the people on my team, and I will remind all of you like I am not your manager unless I literally am and you're watching this video and you actually do work on my team. But I'm not your manager. I can't speak on behalf of your manager. I can only speak about like my lived experiences and that's it. But I do tell the people on my team like we have this thing at Microsoft called perspectives which is a documented way to share feedback.

And so perspectives are a way that you can write feedback for someone and the manager can see. And most of the time, most of the time perspectives are framed in a very very positive way, but they're built into the the template is literally things like consider rethinking this, right? So, you have this opportunity to give constructive feedback. And that doesn't mean you have to write it like I think you suck at X. Like, it's like, hey, you do this thing and it's great. And it could be in a way that you could do even better with this is like try this out. It could be hey you focus really uh you know really strongly on this area and that works well but like maybe in the next project like give this some consideration cuz that would really help. Could be a million different things but the point is that they they try to bake into the template some opportunity to share constructive feedback.

And I tell people on my team that at least if you're giving feedback to other people on the team that report to me, do not hesitate about giving constructive feedback because I don't use that as a weapon against people. Right? I do want to encourage people to give feedback. I encourage them to give it, you know, directly. Um, you know, if you have things that you want to write in a perspective that's going to be documented, I think it would be great if you also had that conversation with that person ahead of time. It shouldn't feel like, oh, I can use a perspective to write this stuff down because I could never say this to this person's face, right? If that's if that's how it feels, there's probably some other things to work on for for you as an individual giving feedback. Like you should be I need to make an environment where you can feel comfortable doing that.

So if you're not um if you're not comfortable doing that like we should talk about that, right? Like what is making you nervous? Is it just you know I think most people it's kind of uncomfortable even to give feedback. So how do we work through that? But it shouldn't be a surprise to the person you're giving that feedback to. And I also let them know that like sure, yeah, we'll talk about that feedback. And I'm not, like I said, I'm not going to weaponize it, but I will talk with them about it. We will work on feedback together. Uh I always think that things like feedback have multiple sides to them, kind of like any story, right? So, you might say, "I was working with this person and um sorry, I have to sneeze and it's really distracting me." Um, here it comes. My goodness. Are we good?

I survived. Okay. Holy moly. Um, yeah. So like feedback is you know stories they can have multiple sides. So if you're saying that you're working with someone on something and your feedback to them is like um the way they were doing code reviews like wasn't helpful or whatever. Um maybe like if I you know if you report to me and that person also reports to me I might hear a very different angle for how they were approaching their code reviews and maybe that they were approaching them in a way that works really well for them and they're trying to be helpful to you but they're not communicating it. So instead of telling that person, hey you had feedback that you know do your code reviews differently, therefore you better go change, it's like maybe it's not about doing your code reviews differently. Maybe that structure is fine.

Maybe you need to communicate the intentions and expectations more clearly. Right? Just to give you a little bit more of a concrete example. Some people like using code reviews uh more like a draft to get uh very early feedback on the direction and other people they expect that when they see a code review that they the time they're spending on that is to get that to a point where they feel like they can they need to be signing off. Right? So some people will say hey the way they write code they're like I don't want to go update all these tests and stuff. um until I I've shown you that how I want to design this in in the rest of the code like is on track with what you're thinking and you know put put your thoughts on TDD and stuff aside like this

is that's a whole different conversation if someone's trying to get feedback on the direction of the code sometimes they don't want to go update 100 tests or something that are going to be broken and other people might be expecting that before they even review. So they're like, "Why am I reviewing this if there's no test changed? Like clearly you're not done, right?" So in this example, you could have two people that have very different approaches for things and if you're not communicating that really that's like the feedback in my opinion is not that, oh, you're, you know, someone says you're terrible at how you do code reviews, go change it. It's like there's a probably a gap here in expectations for how you're doing this and you should communicate that. By the way, I don't know if a lot of you know there's a lot of flooding in Washington where I live right now.

Um, so it's very interesting like uh I'm not driving through flooded areas but they're like not very far from me. like I don't know like 5 minutes off the highway. There is there's roads and stuff completely underwater. Uh it's pretty nuts. But um the other day when I was filming, I was driving on on this highway and uh was hydroplaning like significantly. It was probably the worst I've I've had in years. And so it's raining pretty hard today and I'm pretty pretty nervous about driving through more spots where there's hydroplaning. So I do apologize for being like obviously when I'm driving I'm pretty focused on my driving. But uh even more so like it's almost distracting because I'm looking for shiny parts on the road where I can't tell it's water until I'm a particular distance but it's kind of scary because it's uh it's pretty foggy which you might not be able to tell.

So pretty foggy and then I'm driving and then I can see like almost right before I drive into it I'm like oh that's pretty shiny. Like that's actually water. And hopefully we're going straight. Oh yeah, it's uh it's pretty nuts. And fortunately, we're not affected by the flooding. Um very fortunately, but it's it's pretty scary. And I got to do a couple lane changes here, which is the worst part. One more to go. Sorry. and then I'll get back to back to talking software engineering stuff. I promise. This is part of the part of the code commute experience. Okay, I knew that was going to happen. This was some pooling. Okay, we're good. Um, so yeah, like when it comes down to, you know, this person's question like, should I be doing this? Uh, I think the answer is, you know, it's not super black and white and, you know, just this is the way, but I do recommend giving constructive feedback.

I think that's really important for people to be able to get better. Uh, personally, as a manager, um, I don't weaponize it. I really value when people have written constructive feedback for their peers and uh you know those the the people can see the feedback that you've written but I like I said I always let them know uh it's not weaponized and I work with them on it cuz I like hearing their side of it too. I think it's a really good conversation starter to be like hey have you talked to this person about that like if so or you know if you haven't you know what are your thoughts on these interactions like you know what's your perspective and then we go back and forth on it and then we try to tease out if there's a lesson from it and then say cool

like maybe that's a good thing to try and focus on right not oh well you had a peer say that you could have done better so sorry like you'll never be promoted now um obviously say I'm exaggerating, but like it's not it's not how the conversation goes. It's uh I really like working with people on like what are the opportunities for getting better, not not framing things are like here's all the things that you suck at. Um this I mean it's still I was going to say it's not the same when it's more of like a a performance improvement kind of plan, but uh even so it's not here's all the things you suck at. It's just a lot more direct like really have to see some of these things improve. But um these types of conversations in my experience are a lot more rare. So I I do think that giving constructive feedback is helpful even at you know performance review time.

But I don't know your org. I don't know the temperature of this kind of stuff. I don't know uh what this person's manager is like. I I don't know all these things. You might have managers that are like, I haven't been paying attention. So, if there's any peer feedback, like I just I kind of got a rock with that because that's the only only real evidence. And I would say like I don't know, that's a shitty situation to have managers like that, but I don't I'm not saying that doesn't happen. Um, so sort of the the meta thing here is like if you're in an environment where where that kind of stuff's happening, like is there a way that you can be part of a change for that so that there is space to give feedback without it like crushing people? And a lot of the time I think that just starts with like have those conversations early, right?

It's um could you imagine um take that scenario where it's in my opinion a bad manager, right? Who's not really been paying attention. All they can do is rely on some type of peer feedback. Hopefully, they got something so they have something to talk about. Not a good situation overall. But could you imagine if um if you had good working relationships with your colleagues and you actually gave them some of that feedback early and you said, "Hey man, it was good to work on this project together. Um you did this well, you did that well and I think that you know this thing over here like there's some there's some cool opportunity there. I think if you try doing this a little bit differently, you get your design docs out uh I'm just making this up. you get your design docs out earlier for us to have more time for review or you do this differently with your code reviews or uh or whatever, right?

You make more room for some of the junior engineers to speak up, blah blah blah, whatever it is, you give them that feedback early. Could you imagine when they go to have their conversation with their manager and their manager's like, "Well, you got to go work on this." and you're like, "Actually, yeah." Like, I talked to Billy about that and for the last like two and a half months, I've been kind of uh here's some things I've been trying, right? I've been trying to work on these areas from talking with Billy because we've already, you know, had a conversation about this. Like, how cool is that? In my opinion, that that really can make a huge difference when you have a situation like that where even with a bad manager who's not paying attention that someone can be like, "Look, already on top of that, man.

Like already trying my best, already working with the person on that." Like, you can be part of changing culture around this stuff. The culture is not um you know, people don't get to tell you what the culture is. you get to be part of changing that. I'm not saying it's easy. I'm not saying it's trivial. And I'm not saying it happens overnight, but you can be part of changing that. So, um, just a reminder. Okay, that's it folks. I'm at CrossFit. Uh, if you got questions about software engineering, career development stuff, leave them below in the comments. You can go to codekame.com, submit stuff anonymously, or message Devleer or Nick Cantino on any platform, and I will try my best to make you a video. And hopefully it helps. See you next time.