Can't Deal With It! This Software Developer Won't Follow Standards!

Transcript is auto-generated and may contain errors.

Hey folks, I'm just headed to the office. We're going to go to Reddit for a topic. This is from experienced devs. It's titled, "How would you deal with a dev that doesn't want to follow standards?" And then the post, it's pretty short. It says, "Developer publish a pull request which removes a standard such as a response model and uses another format. This is highlighted on a review comment. The dev sets this comment to won't fix, removes the commenter as a reviewer, and completes the PR. How would you handle this situation? Firearm. No, I'm just kidding. Let's talk about it. Uh, I'm going to get on the road here. Um, if you are new to watching videos on this channel, uh, I take generally questions in the comments and otherwise if you want to submit them on social media to dev leader, which is also my main YouTube channel, um, then I will answer your questions if I can on software engineering and career stuff.

Otherwise, when I don't have a backlog of questions, I like going to Reddit for some topics. And I would just remind folks that if uh you find this helpful, if you think it's an interesting perspective, if you would be as so kind as to share it back on the Reddit thread, uh that would be awesome. People will say, "Hey, Nick, can you share the Reddit thread?" Uh I could, but honestly, if I crowdsource it, that would be way better. if only takes one of you to also do it. Um, that would be super awesome. And I realize that might sound like not trying to put the effort into it. Make a lot of videos. Um, and quite frankly, the more things that I stack up, the less likely it is that I am to be consistent. Um, if it sounds like it's a minimal thing to do, it is.

it is a very minimal thing to do which is why it's so great if other people share the load. So thank you so much for doing that. Um otherwise honestly like uh I've talked about this before. I ride this like fine line of like being uh over capacity and sometimes it only takes something as simple as by the way when you post the video can you go back onto Reddit, find the link, put it back on this like yes I could. I'm not going to do it. Sorry. Um, but I do have a perspective on this. Um, I figured we can talk about maybe a couple different angles for context. I've worked at a startup for 8 years before Microsoft. Uh, and then at Microsoft now for just under 5 years. So, um I want to share maybe some things that I've seen uh and and work well or maybe not and then like how we've navigated things or yeah, maybe just kind of share my experience on it.

Um but I would say that at a high level with this kind of thing, um one of the most important things is alignment, right? So the reality is regardless of you know different arguments for um hey like everything has to follow a standard or everything has to be perfectly consistent or whatever um or even like your your review process right like someone leaves a comment and then you review them cuz or sorry you remove them because you don't like the comment like I feel like that's probably not in the expectations of code review standards but I think it's important to get alignment. I think that is like one of the meta points that I want to talk about here because when you don't have alignment then there ends up being a lot of friction in in many of the things that you do and then you have all this energy put into like instead of just like progressing things.

So for example, the fact that this person is experiencing some frustration because there's misalignment in this situation. I'm suspecting probably other people are uh either they haven't observed it yet or if they have they're also going like this is probably kind of weird behavior. Um like the whole point of a review well I shouldn't say the point but one of the things that you get is like alignment on what's going into the codebase and if someone has a different opinion if you're if the action that you take is just to say well just kidding I don't care about your opinion and like you're no longer involved. Uh if that's consistent, like I think there's a problem. Um and if there's no discussion, I think that's a problem. I would absolutely say if there's a situation where someone makes that suggestion and then you discuss it and then you go and therefore this is the reason why we're not moving forward with some other standard or whatever.

Like there there needs to be some reason and some discussion. Sorry, I'm stopped here and I'm kind of distracted because this road has been under construction for forever. But now they have traffic stopped both ways and I can't tell why. Like nothing's actually happening. So it's Oh, they're letting the other side go. They're letting this cyber truck come through. So cool. I wish I had a cyber truck. Just kidding. I think I would rather drive almost anything else. So dumb. Anyway, um yeah, I think alignment's really important. Uh and when I'm talking about alignment here, it's like on two fronts. Like one is that you ideally have alignment on the direction that your code is going. And that doesn't mean that things cannot change. That doesn't mean, hey, we have a standard. This is the only way that it can be. This means that like there's an understanding of the direction that things are heading in.

This person holding the stop sign's walking away and I can't tell if they're still holding the stop sign or not. No. Okay. I feel I don't know. I've never been a sign bearer. I feel like I wouldn't want to be cuz I don't think I would enjoy it at all. Oh, there we go. I was going to say I feel like the complexity is not not there. But I feel like if you're holding a sign and that's the and that's the point of your job. If uh if the people that are needing to observe the sign are unable to tell what you're doing with the sign and it literally just has slow or stop, I feel like you're not doing your job properly. I I don't know. I feel like the complexity is not there. Not saying it's enjoyable. Not saying it's easy. I definitely wouldn't want to do it and stand out in all the crappy weather.

Don't get me wrong, but the complexity is not there. you should be able to make it pretty obvious uh what you want people to do based on the sign anyway. um alignment in terms of how you want the code base to be moving in like the direction and that might mean that you have some patterns that maybe are more legacy, right? They've been used for years and you're like, "Hey, we have better ways of doing things now. Let's like move in this direction." Um so like that's alignment, right? Like there's an understanding among the team. This is the direction we're heading in. And then on a particular code review or even the process of the code review that's even two parts right there the the code in the code review is kind of same type of thing I was saying alignment in the direction of

the codebase but the process itself right like it sounds like there's misalignment in the process if someone's just like hey that's a that's a comment I I don't like see you like that's probably not supposed to be part of the process so we should get alignment on that as well. Um, alignment is like an underlying theme you'll hear me talk about on on this channel, right? I always talk about like aligned expectations with your manager, that kind of thing, but this is same thing. if you're trying to communicate effectively like at some point there's uh this concept of like reaching alignment because if you're not aligned on things uh it makes things really difficult. So um alignment is sort of the meta point on this one. I think that people got to got to reach for that. So, I was trying to back up from saying like the only the the main point of a code review is alignment.

Like there's a lot of different opinions. Some people say don't even do code reviews. Um not going to get into that, but um I think if if you have a code review step in your process, uh taking the opportunity to get alignment on what's going in is probably one of the reasons that you're doing it. Okay. Um, I do want to talk about some different experiences, but I think one of the things like that I'd like to kind of maybe jump into right away. Don't turn some people. This is a This is a good day for a 360 cam and I didn't stick it on the top of my car. There's a lot of stupid people today. But um it's almost Friday, right? Woo. Um I think it's important to try and talk about like how do we go address this because that's the main reason this person wrote this.

Uh I wanted to share and I hopefully will share context on previous experiences. But this Canadian geese, my boys, Canadian geese are a pain in the ass. They're so territorial. And if you haven't been around Canadian geese, you might not know this, but you could go if you if you haven't done this yet, um if you're like, "What's a Canadian goose?" or "I've seen them, but I don't like I don't know anything about them." Um, search Canadian geese territorial and just like look on YouTube and watch videos. Um there's even like where I went to university uh and I've talked to people here in in Seattle that uh that went to university and they said the same thing happened on their campus um and what happens is they're so territorial that if you're in the vicinity and you're trying to like walk through like a open open area or something.

I've even seen people they get like kind of stuck in their house because there's a goose that's outside or you know a couple of geese and um they they will basically attack you. Now I feel like I don't know an adult human could probably fight off a goose, but like you probably don't want to have to do it. Uh I like I certainly wouldn't want that to be in my daily routine is like fighting off a goose that's attacking me. So, uh, bit of a pain in the ass. They're very, very territorial. So, if you have no idea what I'm talking about, go pause this or watch it after. Go look for, uh, Canadian geese territorial and just watch, uh, YouTube videos. It's funny. Um, not funny if you're the person that they're chasing. But anyway, what do we do in a situation where we have a person like this?

Um, I think this depends sort of on your role because that might change how you address it. Um I would encourage anyone on my team if they observe this happening. So say this is happening and I'm not aware of it. Um my first recommendation to anyone would be like uh is like have a conversation about it, right? Um it doesn't mean and people get weirded out by this because I think it's only like as as uncomfortable as you make it. And that's way easier for me to say than than to go do it. But let's think about this situation, right? So there's a review. Someone clearly didn't agree with the comment. Remove the person. It's based on what was written in this post. They didn't even comment back. They just said won't fix and remove the person as a reviewer. Um I would honestly if you were just a developer and if you're like concerned about seniority, maybe this person's more senior than you and you're like, I don't want to stir the pot.

This is too weird. Um, be curious, right? Like I think if you go into situations being genuinely curious instead of being like, "Hey man, screw you." Like, "What the hell are you doing?" Um, being curious is a really good way to make progress on things. So, for example, let's assume that you're more junior than this person who's re uh removing I keep saying reviewing people. Removing people from the review. Um, if you feel like intimidated or you're like at speaking out of line, got to sneeze. Holy crap. Oh my god. That might be the first triple sneeze on the on the channel. Sorry. um can't do anything about it. It's it's done already. If you're if you're more junior and you're concerned that you're like, you know, out of line by asking about this or it's uncomfortable, being curious, right? Reaching out to the person and saying, "Hey, like, hey, was just just curious like I was on this review with you and um you know, uh was seeing some of the comments coming in.

I was curious about how um you know, you use this new approach. it seemed like someone else on the team was suggesting this other way. Um like I see that there's at least two ways to go do this right based on the patterns that were proposed. Um is there any reason why you're going with that one? Like not even you can start by not even addressing the fact that they dropped the other reviewer, right? Like be curious. Why is it that there's so, you know, so much in line with this one approach? I would be very curious personally if you're going to go out of your way to be like, "Nah, screw you." And then like not take any feedback or not even respond to it with like a message saying won't fix and not saying anything is a bit weird. Um, also we don't know the full context here, but I would be curious like why why is this person like this approach so much?

Um, so I would start with that, right? And then get that conversation going, trying to learn about the other side of it, and then saying, "Okay, like cool. Now that you've kind of broken the ice on it, you're having a conversation, and you've been genuinely curious, now you can be genuinely curious about the next part. Hey, it seemed like Billy from the team was recommending that you take this other one. I didn't see that it was discussed, though. Um, and then I noticed that uh it was marked as won't fix, but I don't know if we actually like clearly communicated that. Like I I didn't really get that from the review. Like was just curious like you know why did you know why did you take that action? Right? You can pick your own words. Obviously I'm just making this up on the spot. Um, but like pick your own words.

But I think the point here is the the more curious you can be and genuine, not like facitiously or like in a condescending way. Um, if you're acting genuinely curious, then it's it's a lot more difficult to be um perceived as like an attack where someone has to get defensive about something. Right? If you're curious and it's a teaching opportunity, sometimes people will really lean into that. Oh, you really want to know about like this thing that I'm doing? Cool. Like, yeah, I'm I'm passionate about that. I'll tell you all about it. Right? But if you lead in with like a, hey, man, I saw what you did. You shouldn't do that. Obviously, I'm exaggerating a little bit more. Then immediately someone's going to get defensive and the way that your interaction goes is going to be a little bit soured. So, um, just like these are just communication things, right?

I'm I'm giving you an approach. My my point here is that I think I would recommend people start by addressing it as team members to start. If if the positions the other way, if you're more senior than this person and they're more junior, you can still approach it the same way. But there is um probably a more implicit like level of either respect, I don't want to say control, but like because there's seniority kind of built in, you might be in a position where you can say, "Hey, this is a teaching moment for this other person. I will like I observe this thing. I would like to give you feedback on what the team's perceived way of doing this is." And it's not dropping people off the review without discussing it. For all we know, right? I'm just going to play devil's advocate here because I think it's important to do this because when you read something online, you're getting one perspective.

There's always more than one. For all we know, this person might have said won't fix. Remove the person as the reviewer. But what actually happened is they discussed it offline off the review. They discussed it, got on the same page, they agreed on it, and then the other person was like, "Cool. And by the way, like I I don't have more time to review your stuff. Like I got other stuff I'm doing, so like just remove me." Like it could have been a very mutual thing. I have no idea. But now I'm not saying this is likely. I'm just saying that when we talk about these things, we're we're only ever discussing one person's perspective, right? So, it's kind of unfair. There could be other going on. Um, so, pardon me. We talked about from the perspective of like junior talking to someone more senior, senior talking to more junior, which could be a teaching opportunity.

The other thing is like if this is a pattern where you have people on a team that are trying to like address this and it starts becoming a problem and like no one's able to get some movement on it, then I would say this is probably a good uh opportunity to like bring it up with the manager. Right? Now, what I'm not saying is if you observe this and you engaged, say like I'm your manager, right? If you engage me right away on it, I'm not going to be like disappointed in you or being like, "Oh, that's the wrong thing." Like I appreciate all visibility, right? Um I also be like, I don't know if you can tell this, but when people bring stuff up and they're like, "Hey, I observe this and it's not good." Uh, I I never or I try not to ever perceive it as as like tattling, right?

Hey, so and so did this and like go get them kind of thing. It's like I need to number one, again, it's one person sharing one perspective. Number two, uh I've had situations where people are emotional about something or they're whatever state of mind they're in because they're stressed. Like they might be expressing things in a way that's not how they intend. And it might very much sound like they're tattling on someone for something. And I'm like, I I know this person though. I know that's not their intention. They're just trying to bring awareness or they're asking for help on it. They're not trying to throw someone under the bus and be like, "Screw you." I don't know what's happening with my voice. I think my body said, "You need more caffeine, so I'm just going to turn off your voice." Anyway, I would, you know, I would be fine if someone wanted to escalate it with me.

My my like I said my first recommendation would be hey have you had a conversation about this yet. The reason I like doing that is because I think that um when people can work on their their working relationships with their colleagues then they can solve way more problems together versus it being like a thing of friction. like you can address things before they become a bigger point of friction. The other thing is that it can be a really good coaching opportunity, right? Um I've worked with employees where I'll say, "Hey, like I understand that this is a challenging thing. I'm happy to step in and try to help you work with this person on whatever the situation is." But then I will say, hey, I I do think that you're going to in your career work with different styles or people with different styles of communicating how they approach things.

And I'm not telling you it's right or wrong. If they were also reporting to me, then I might say like, you know, maybe it's a coaching opportunity I have with them, too. There's different sides to this, but I do see this as an opportunity where you can practice something here. If you're interested in that, let me coach you through it. then you can go have this conversation and then we'll see how it goes. And if you need more support person was going like 30 in the fast lane. Unreal. Uh that's not very safe at all. Um but yeah, it it can be a coaching opportunity is my point. So it doesn't mean that I'm like, "Hey, screw you. I'm not going to help you." It's like, no, if you want this to be something that you can go try and it might be a little uncomfortable, let's work on it.

If not, you need me to step in, let's let's approach it that way. But I like giving someone the option. So, these are ways that I would address this. Um, if I need to go speak with that person, I would kind of approach it the same way that I um was saying as a senior talking to someone more junior. uh even if that person, you know, is also principal, I would just kind of start by being curious. I don't like going into stuff accusing people of like having behavior. I think that's kind of unfair, right? Like I haven't heard their side. Why would I like go on the offense? Um there's always multiple sides. I would like to understand and then kind of dig into it and say hey look like you know the way that our team operates is like we need to have

alignment and if that's not happening it's not to say that situations can't get vetoed but like you there needs to be communication about it at a minimum right so sorry I'm trying to move over lanes Um, so if that's not happening, like let's chat through that. Um, because my expectations of people on the team would be that they have clear communication. If that stuff was discussed offline, right? And let's let's again devil's advocate. Every time this happens, this person's like, "Hey, I just don't want to have a back and forth on the review. Like, it's not a good spot for it." Which I agree with. I don't think it's great to like write novels back and forth and debate things. Like go have a conversation like humans. So if they're like, I'm I'm discussing it offline with other people, I would say that's great. Like awesome for doing that.

Now that you've reached a like a consensus, put it back on the review so other people can see it and it's documented, right? Um that's fine. But I think you know what this person who wrote this Reddit post is observing is a kind of you know the way that it's painted and it might be very true is that someone gets a little bit of push back and they just drop people off the review which if that's what's happening like I don't I don't think that's great. Um okay I'm getting on to the last stretch of highway. I was thinking I was going to try to go through some uh some previous experiences I guess. Um I wanted to talk about um not like not individuals being crappy or anything like that. More like code alignment I guess.

Um, one of the things that I've seen as a pattern in my career is that is if you're working on code bases that are growing over time, which um, probably going to happen if you're not at a company that's falling apart. Um, most companies that are, you know, shipping products or they're paying customers, the code base is going to be something that keeps growing. You're adding more features. You're adding more support over time. Probably it's getting messier and messier over time. Not saying there's things you can't do to slow it down or to try making it better, but odds are it's going to get a little bit crappier over time. But what's happening along the way is that people are learning or patterns are emerging. And that could be patterns in how things are architected. It could be smaller scale like smaller design patterns for how things are approached.

It could be um based on on user feedback, right? Like the way that the the actual feature set has evolved over time. Don't come over in this lane. I almost had to lay on the horn. We're not having a good morning. I mean, it's been okay, but just a lot of stupid people. Um, as your code bases are evolving, you're going to find that you have inconsistencies. Now, you can not do that by every single time that people are deciding, you know what, this is going to be the new pattern we follow. You could stop everything you're doing, go search the entire codebase, and go correct it. But I would speculate that this kind of thing would slow down development so much that it would become unrealistic. You might have different opinion. That's mine. Uh I actually think just a bit of a tangent something that will be super awesome and I'm going to be talking with a friend more about this so stay tuned.

Um but I think this is the not the one of one of the most interesting use cases for uh agentic AI that I can see is like let me as the developer keep pushing forward on building the new cool stuff and as I'm going oh you know what this is the pattern that I want to start using everywhere but there's 50,000 lines of code in this codebase So I I adopt this new pattern that's immediately checked that in every every other spot that's using the old pattern. Hey AI, go convert all of that code. Oh, there's no tests on it. Great. Report back or write the tests on it. But like you go refactor my code. I don't want to do that.

or if I if I do want to do that because sometimes it's enjoyable to go refactor things like I'm trading off building new features and that's not a good use of time uh a lot of the time right um because if that other code has been stable and it's not actually broken it's just like this is a preferred way to do it it's uh it can be not not worth your time to go touch the entire codebase to address something like that so I think uh you know using agents for that could be wildly beneficial in terms of just like continuously uh modernizing code bases. But anyway, um I've seen this kind of thing happen where you have these patterns kind of uh evolving in a codebase, right? So you might have, you know, three or four ways of doing things if you were to look across all of the files.

Um so I would say like a couple things, right? one, if we're taking this review example, if someone's using the older pattern that we've said, "Hey, no good." Um, that could be a really good like teaching opportunity to say, "Hey, by the way, that's not the one we use anymore. It's this. You probably copied it from this older file. Sorry. Yes, we should go clean that up." Um, but like this, you know, refer them to the new pattern. Explain why that pattern's used, not just like being a jerk about it. So do that. And then the other thing is like maybe you're the one coming up with the new pattern. And if that's the case, if someone's like, "Hey, we already have a pattern for this and you have a new one." Like is it because you didn't know? Or is it because you do know very well and you're trying to iterate on it?

Um because if you're trying to establish that new pattern, that might be again something you want to go discuss offline with your colleagues so that your review isn't just like people debating this pattern and like you know maybe that's one part of your review and now your your entire feature or bug fix is blocked because of this. It's like, hey, maybe go have a discussion about this so people can go get on the same page, kind of agree on it, get get alignment, and then move forward on it. So, I wouldn't say like the reason I'm bringing this up is because I've seen it happen so many times where either wrong old pattern was used or someone's trying to kind of move um move things forward and adopt a new pattern. Um I think both of those things happen a lot because code bases evolve over time.

So instead of like what is my point I guess is that this type of thing I think is a common situation and so instead of maybe looking at the scenario like oh that's a weird thing like whatever like seems like a one-off kind of thing I'm trying to say no I think it's a very common thing that comes up and that's especially it makes it especially important to make sure that uh you know you feel comfortable navigating situations like That's the point. Took us a while to get there. I'm sorry, but I tried my best. Okay, made it to work in one piece, I think. I don't know where my my voice is going. I wasn't yelling and I don't I don't think I'm sick anymore. But that's that. Thanks, folks. I'll see you next time. Take care.