My Teammates Don't Keep Their Branches Up To Date!

Transcript is auto-generated and may contain errors.

Hey folks, we're going to Experience Dev subreddit. We're going to talk about this post that was asking about unmmerged pull requests and who owns the unmmerged pull. Well, it's not even unmerged pull request. Sorry, it's a feature branch. What am I talking about? It's a feature branch. Unmerged feature branch. Maybe there could be a pull request with it. Who knows? But this person is asking about the ownership of branches, a feature branch that their peers have. Whose responsibility is that for maintaining it, making sure it's up to date? If this is already sounding a little bit confusing to you, don't worry. Um, so the, you know, they're walking through this kind of like hypothetical scenario where they have a colleague that has a feature branch that they were building and then they they stopped working on it. It could be for any reason, right? So now there's this feature branch that exists and it's a week behind the main line.

It's two weeks behind. It's three weeks behind now. And this person is saying, "Well, what the heck?" like this seems wrong to me. Like why why isn't it this person's responsibility to go keep their feature branch up to date? and they add in that what they're doing is they're building on top of this unmerged feature I guess with their own branch and saying like it's really problematic because obviously as things are falling behind the mainline they can't uh you know things aren't going to work properly and like they shouldn't be the one that has to uh you know rebase it and keep it up to date. So they wanted some perspective on this. Um I when I was reading through this my first like set of reactions were all around like confusion I guess. Uh like why is like what what's actually happening right here? Like uh I I just I feel like this workflow something's weird about it.

Um so I'm like okay I need to like sanity check myself here. So, I scrolled to the first comment and I was like, "Okay, uh I I'm not I don't think I'm I'm missing something." And the first person basically says like, "I think the actual problem is that you're that you're building on like, you know, unfinished features." Like, that's basically it. Like, that's the problem. And then I look at the next comment and it was a similar type of thing like you know maybe the issue here is not you know whose responsibility is to keep a branch up to date but the fact that like you're relying on you know something that's unfinished uh and in this state and then trying to like use that as a base for building on top of um and kind of suggest it even to the person like you know if if there are things you need in that like perhaps it's your responsib ability to to be the one to drive those things forward.

So, I wanted to to talk a little bit about this for a couple reasons. one is like we could talk about this specific scenario, but number two is like maybe a little bit more meta and it's like um I don't even I was trying to think about how I even say this, but like I think one of the common themes where we see issues in software engineering and I talk about this in a lot of videos is around communication, right? And I don't think it's I think this is an example of of that. And um it's not limited to to feature branches and stuff like that. It could be uh pull requests, code reviews, different things like different different processes that we that we do.

Um, and really coming back to communication being one of the issues like the like spoiler alert when we get into it, but like maybe one of the issues is that instead of talking to your colleagues about how you have this issue is that we go to Reddit to ask like I don't know, right? Like I don't mind because I'm reading it and I get stuff to talk about. I don't care. But uh when I think about this, I'm like, don't I don't like don't you think it would be good to talk to your colleagues about this so that you can you can solve the problem together? I don't know like that. Uh, I know it's easier said than done because uh any any type of conversation that feels like it might be a little bit confrontational. It's it feels easier to avoid, but um then you're stuck writing posts on Reddit and having the internet give you uh random advice.

So um in particular with this this feature branch building stuff, um first of all, there's going to be people that are saying like, well, you know, this is why you don't have feature branches at all. Um there's uh you know different ways that you can go develop software right some people are violently against branches like this uh personally I like feature branches I like being able to uh as I'm working on something literally just you know if if my brain is like I need to snapshot this before I make another decision I just like being able to commit um and have that on a branch Right. And maybe where I need to wrap up because I have to go do something else physically is like maybe I want to push that branch up and then it's, you know, it's available. Like I I like having the flexibility of working off of a branch like this.

But um, you know, then people will say, well, obviously if you if you're a good software engineer, you should be able to like, you know, get your get your commit or two in and just get that on the main line right away. And like this is the only path. And I'm like, "Look, man, I get it. There's a lot of stuff that I do build that's like that where I'd like to do a one-off commit and get it onto mainline." And I'm like, and realistically, there is just so much that that doesn't work that way. And it's not for me. It's not slowing down um or does not feel inhibiting at least for me to build software that way. It actually works really well for my mental model. So, I have no issue with, you know, having feature branches and and this kind of thing. Like, it's just not not an issue.

Like, I'm very familiar with rebasing to keep my stuff up to date and and building on things like I don't know a lot of the things that people complain about where they're like, "No, trunk base only." Um, like I just I don't feel like I have those sets of problems that you're talking about. With that said, of course, like if you're in a perfect world, if you're able to make every change that you're doing a nice little, you know, nice little commit on top of main without having to branch, like, excellent. I think that is that is a lovely ideal. But I don't know, like I'm not going to like try to hyper optimize my workflow to do that versus just like feel effective at what I'm building. And it for me it happens to be with uh with branches. Now with that said to this person's kind of question in the in the Reddit post um do I have feature branches that build on top of each other that aren't committed?

It does happen. It's rare. But I'm also the owner. So uh when this person's saying like who needs to keep it up to date like surprise it's me. Um, and so that doesn't really help this person. But conceptually, I don't I don't love building features on top of uncommitted features. Um, this act to me personally, this actually happens more often by accident. Like I forgot to switch back to main and I started building. Um, in which case it's almost no issue at all. It's like just look where I started committing again and go okay like new branch pull that over on top of the main line and it's usually fine. The only time it comes into a a challenge uh is if I like was like oops I'm accidentally using some new API or uh I've refactored something and now I now I'm kind of caught in a sticky situation.

Of course that does happen too, right? Um so there are situations not only where it happens by accident like that but um I have an unfinished feature that uh especially maybe feature is not a totally great example. Usually it's some amount of I needed to reorganize code, right? and I needed to change some API service and um so to support a feature a hiccup to support the feature there was some other work that had to get done and uh maybe maybe there's like a bug or something that comes up or there's something that feels more urgent than the feature that I was originally working on that's not finished uh and I end up trying to uh build on top of it. When that happens though, uh again the the way that I often try to write software and again it's not perfect, but I try to make sure that if I'm like, okay, I have to refactor something or redesign something to build the feature on top.

I try to, you know, use the feature as a a guide for how I'm going to clean up that code or reorganize it, but I try to commit the refactor first. It might live on that feature branch but I try to make sure there's a point in time where like from here on we have refactored or we have you know changed the API surface we got we got to a good state let me commit that and then I will go build the feature on top. So again, most of the time if I've been writing code the way that I usually intend to, um, if I need a feature branch to build on top of, um, I can usually, uh, do a little bit of Frankensteining work where when everything's working on that feature branch except maybe one of those features, I can cherrypick over the

refactor work and then I can cherrypick over the um, the new feature I was building on top um get that like get that working have it uh integrated into the main line then what's kind of interesting is I can take that feature branch where things were being developed rebase it on main and what's left is almost only just that feature uh one of the first features a little bit easier to explain with a picture so uh I realize driving in a car and trying to explain uh you know moving commits and stuff around in kit is probably not obvious. Watch that back in slow-mo and uh it might make more sense. I apologize, but yeah. So, for me, it's it's not usually that big of a deal, but not not my favorite situation to be in because there's more opportunity to have things coupled. Okay. So, I'm going to shift a little bit and kind of talk about the other flavor of this stuff, which is like around communication.

Okay. So the answer here is like like who owns it? I don't know. Like give you an exaggerated example. If I had a branch of code that I was writing in and experimenting with something, then if I had no intention to even merge it, but I like pushed it up so that I wouldn't lose it, and then you decide to build on top of it, like am I now accountable for for your problem? like it it doesn't make sense. Now, I what I think we're probably missing a little bit of context on is that I think there this person has probably been set up this way to go build software in this way. Perhaps it's like in a sprint, right? I'm making a lot of assumptions here. In a sprint, it's like, okay, Bobb's gonna work on on this feature and Sally's going to uh also build some other feature.

So, feature number two, and it happens to use uh did I say Bobby? Can't remember the first name. Bobby's feature. So, in the sprint or something, it's like someone was set up to go build on on top of something and I guess we stop communicating about it during the sprint or something. And then Bobby, you know, has to pivot to some other work. So, his features not getting done. Could be some other dependency. Could be uh you know other priorities came up mid-sprint and had to kind of jump over to it. And now this uh this second person I'm terrible with names this morning apparently. Now the second person's like, "Okay, well I'm kind of screwed here cuz I needed this feature." But like I don't know. Like again to me this doesn't seem like it's a a problem of of git and branch ownership. To me, it seems like this is a problem of like dependency ordering.

Like why are you why are you planning to do that work in a way that's not going to work out? Like you're kind like this is an avoidable problem if we talk about the dependencies. I feel like because truly if the work of the first person was needed for the work of the second person, it's not a matter of like oh you got to keep your branch up to date. It's like h how are you planning on landing feature number two if if feature number one is literally a dependency? It's like someone needs to talk about the priorities that you know the engineering team is is focused on like it's just it's out of order. I should have went man let's go.

Um, so yeah, I I feel like the reason that a lot of this conversation kind of or the question is kind of like irking me is I think if we go back to communication, a lot of this kind of stuff, uh, I I find if you're really effective at communicating, and I mean this within a team, that a lot of the problems that I see people posting about on Reddit or these conflicts and stuff. It's like I feel like a lot of that gets reduced significantly um to more like we have differences of opinions. Do do other people have like some thoughts on like how to weigh these things? Whereas sometimes these people post things and it's like it's it doesn't even feel like a difference of opinions. It just feels like I'm stuck in this bad spot and it's like why how did you get stuck there, man?

like did you talk to someone about this? So yeah, in this scenario, my recommendation would be like backing up a little bit and I I think I feel like whoever is the product owner or however this is structured. Uh we got to go back and talk about the actual dependencies and make sure that the people who have dependencies on each other are talking not only with each other but with whoever is trying to help organize around dependencies and priorities. So if that's a product owner, that's a project manager, that's an engineering manager, whatever. Um or I don't know depending on the team structure, maybe there's a there's some sort of lead or whatever. But basically, if there could be a third party, if there is a third party that's helping organize priorities, keeping that person in the loop, too. Um, it just feels like there's a disconnect in in communication here that's keeping this person from being able to work effectively.

And uh, I wanted to give you like just a quick example of like this not just being feature branch work, right? I've seen this kind of stuff happen even with code reviews where people just have a different sort of working style of how they use their poll requests and code reviews. um sort of like uh people leveraging draft PRs, right? Someone puts a draft PR up. Sometimes here I maybe this is the part of the issue. Sometimes people just use a normal like a PR in a non-draft state to still be a draft and they're like, "Hey, it's up. I want you to have an initial look at this." And then some people are like, "But I can't review this. Like there's no tests and it's not done and whatever else." And then instead of talking to the person about it, they get more like frustrated that their time's being wasted because like why should I be reviewing this this code change that's not even done, right?

Like you don't even have the test. Did you even run this? And the person's intention was really just like, hey, I'm just looking for initial feedback before I get too far. Um, so who's right? Who's wrong? both and neither like talk about it, right? If if you if you're expecting someone to go review uh your some of your code that's like an initial view of it, tell them like, "Hey, like this isn't done. I'm just I'm trying to get something up so there, you know, we can see some initial feedback if this is the right direction." And if someone does not tell you that and you're reading code and you're like, "What the heck? Like, where is all this stuff?" Maybe send them a message and be like, "Hey, I noticed like it doesn't seem complete or there's no test or whatever like or clearly

this isn't going to work and like I don't know why you're getting me to review it." Instead of instead of like assuming that they've just forgotten or messed up or whatever that they're trying to waste your time, like maybe ask maybe say like are you just looking for some initial feedback? Right? If we if we just try to do a little bit more in engaging other people to be curious and communicate overcommunicate I think a lot of these types of issues get reduced. So that's that quick video. Uh thanks for watching. If you have questions about software engineering career development, leave them below in the comments. Otherwise, code.com. See you next time.