Getting WRECKED When Working In Other Team's Code

Transcript is auto-generated and may contain errors.

hey folks I don't have the insta 360 going because it's kind of raining outside in hindsight it's probably going to be raining literally all the time because it's Seattle but I've been finding even with rainex uh it's not doing so well and uh really just kind of takes away from the video when you have water droplets on the entire surface of the front camera so I'll have to come up the better solution but uh on a day like today where I know it's wet out I won't use it we're going to go to Reddit for a topic this is one uh I'm surprised I haven't talked about this yet so I think it'll be pretty helpful for at least some people because I don't think that this situation is that rare and the situation that this person was writing about is in their case there's

a a geography discrepancy and uh that's going to sort of amplify the challenge that they're facing but I don't think it's the root cause of it um some people I scan the comments some people were saying oh this is absolutely this type of situation and I disagree but we'll we'll talk about it so the idea is that there is a person and this person is in a foreign country doesn't matter which country but uh their main sort of counterpart is based in the United States like I said I don't think that this part is actually the root of it but um then this person goes on to say that you know they're on this team they're relatively new but things are going pretty well for the first like you know six8 months or so so they're kind of getting in the groove of working in

the code base being productive and then the next project that they're on for their team they actually need to work in uh someone else's code base so a different team essentially like owns this code base and uh for this individual they are going to have to do work directly in that code base and again this is where we have the cross Geo thing coming in because that other team is in the US now apparently what had happened was they put up a pretty big poll request and um I guess was reviewed and ended up breaking a bunch of stuff um that's pretty critical but now it's not shipped to production it's not like everything in prod went down and users were everything's on fire kind of thing but I think there's still this situation where they're feeling like oh man like I really screwed up

um and the part that I was kind of glossing over because I don't think that it's the the most important part about what I want to talk about is um I think they they might have been saying right now they feel like they're in hot water with their manager and I don't know if that's how they feel or if they had feedback on this but um I made plenty of videos about trying to like you know have clear open conversations with your manager it's not what I want to focus on for this one so what we're going to try and focus on is how can you be productive when your expectation that you've been given is that you need to go do work in someone else's code base okay that's what we're going to focus on so a quick reminder before I dive into my

perspective on this is that if you want your questions answered leave them Below in the comments I'm happy to try and get to them make videos on it uh and if you have something that you want to be kept Anonymous or you want to write something lengthier please look for Dev leader on social media that's my main YouTube channel as well and uh you can feel free to write me there uh or Nick centino on LinkedIn my profile should be open to send messages to uh plenty of people have taken advantage of that um and I feel like based on their responses that they're they're thankful that they had the opportunity so I'm trying to make that available for folks and one more little plug if you want your resume reviewed uh my main Channel Dev leader has a playlist for resume reviews currently it's

not paywalled or anything uh I suspect if the demand keeps going up eventually I will because it will bankrupt me because it costs me money to review resumés uh because YouTube ad Revenue doesn't do it okay so for context I actually have experienced in this type of situation not a cross Geo situation but like I said uh I don't think that this is the the root cause um a quick note that based on now that you've heard the scenario I a lot of people were saying oh no look what's Happening Here is like the US company is like trying to sabotage this person because it's very clear that the sort of the company itself is trying to Outsource all the dev work to India or wherever and therefore it's like the devs are trying to like push back on it and I simply just like

think that's far too big of a leap to to start making assumptions about I'm not saying that's not in the realm of possibility but like you know we could literally take this exact scenario and remove the geography discrepancy and this would still be a problem that people encounter and we should talk about which is why I'm approaching it that way so in my experience uh I had before Microsoft the startup that I was working at one of the teams I was managing had gotten through our backlog of essentially everything that needed to be done for our product at the time that was a priority and there was a larger company initiative that had a lot more priority and we needed more help on it so my team was brought in to help assist with that so we basically parked all of our uh efforts in

the work streams that we were doing and because literally the biggest priority was helping ship um this big product launch so our team was brought in we were we were named The Expendables like the movie um and it was kind of I don't know supposed we thought it was fun uh because it was like we based on our uh humor and stuff it was like oh I guess artw work doesn't matter right like okay put us in like toss us into the fire like you know we are truly the Expendable team uh but like we all work really well together and uh the thing that motivates us the most or that team at the time when I say us I'm talking about that team is uh you know basically give us a hard challenge that like we don't think can be solved so in this

case how do we help ship this product that's you know on a tight schedule like give us Mission Impossible and we're going to go do it um so in this case what we had to do was go build inside of another team's code base that the other team primarily owned and I've actually I think I've told this story before on code commute so if you've watched all of the episodes which I find hard to believe if you have uh but if you have you might have heard it uh and essentially what had happened was very similar to what this person described which is you make changes in someone else's code base and even if they review it you end up breaking stuff and then what happens is uh well at least in our case what was happening was we would go land features and then

between us landing it and the next Sprint for that team like when they had to go do work building on top of it they would be like oh you broke a bunch of our stuff so our next Sprint we would spend fixing bugs while they were making changes and then they would break our feature so we kept every other Sprint we were basically just repairing the work that the other team did so you know in terms of being productive it was extremely counterproductive uh in terms well at least in terms of efficiency because we were spending so much time fixing each other's broken changes So eventually and this is kind of like a I don't know like in hindsight this should have happened far sooner but eventually what we did was we said look like this is getting ridiculous we're wasting so much time going

back and forth like this uh even with people signing off on the changes it's not like we were like stealthily trying to like sabotage their code base but we said how do we help make sure like this is the mindset how do we help make sure that other people can touch our code and not risk breaking all of it and for us we added a ton of test coverage in then and for some people you might be saying well that's not going to work they'll change the test blah blah blah but one of the things about having more test coverage and especially when it goes up for review is if we see the tests changing right so someone makes changes to the code and then we see the test changing we know that if we had really good uh when I say coverage you don't

just mean specifically lines of code I mean enough coverage that gave us confidence on the critical things if we see those tests changing then we're going they're changing expected Behavior now based on everything we've discussed do we expect that behavior to change because if not there we go like you're about to introduce a bug now this isn't a bulletproof solution because for anyone to claim that just having enough tests is going to mean you never have a bug it's a false statement there's always possibility for escape and if that's the case like you know you just can't make that claim but it's for us it really really helped to make sure that we could build uh confidence in letting other people touch our code base it got to the point where we adopted that mentality Beyond just The Expendables team that we had and we

said when we build code like anyone should be able to come into our code base not that we're not going to review the code or try to make sure it's a with our vision but anyone should be able to come in and not have to worry that they're going to break absolutely everything because all they should have to do is run the suite of tests and at least know what's being affected if a behavior is changing that's expected so that was something that we truly adopted and tried to live by uh it's not that we had that scenario happen often but it's something that like it was such a painful experience for us that we were like we have to make this better so um to go beyond my experiences and address what this person's going through uh it's right that they're I I mean

in my opinion it's right that they're feeling frustrated because it sounds like and we don't have all the detail but if this was a big first of all it's a big change um I think we got to come back and revisit this for in just a moment but when this code lands and it's been reviewed by a team they've signed off on it they've said we agree that this is okay like what we don't know is like well what did the test coverage look like did they go make this like you know multi you know change it's like 1500 lines in total and then no tests were updated they only added tests uh there were no tests in the first place so there was nothing that could have uh showed regression like we don't have any indicators of that but my guess is that if

this was a critical thing that broke one once this code landed is that there are insufficient tests and I say that again not to to talk about like lines of code that are covered necessarily but I mean the scenarios that are critical to cover with Automation and regression tests are simply not covered adequately unless it's a completely fluke chance that how this person made a big change like that happened to touch some Edge case and happened to show up which I think is going to be pretty unlikely so in my opinion number one here is like this is why I told this story my own experience is that people need to be in this position where um they're building in a way that other people can come into the code base and make changes again I'm saying this not to be like hey like we'll

just cover our eyes you do whatever you want no it's going to get reviewed it's going to get reviewed but it's that people should have confidence when they're making changes in the code base that's what you want to be able to support not that you're always going to be having that happen so I'm just trying to explain why it's a I don't know like a a a team philosophy that I I like to adopt so I think that's lacking in this particular case uh number two and this is maybe what I should have started with is like when you have a really big poll request like that it's, 1500 lines this person's new to it um I think that there was probably a lot of missed opportunity um and so I'm going to put you know in terms of blame air quotes here um maybe

blame I all skip that word I'm going to put some responsibility on the person that wrote this post on Reddit and say look like if you had A500 line pull request go up um what I would have recommended that you do is basically have someone on that team that you could have been designing stuff with or getting their sign off along the way so there's different ways to do this it could be uh whether it's a design dock to get feedback early if it's draft pull requests so basically you keep a draft open and you keep upda it so that someone can see the changes coming in before it's like okay it's finally grown to 1500 lines now let's add a few people from the team and hope to God that they understand all the stuff I'm touching uh for people that have been on

poll requests that are large there's a there's memes about this right it's like you know two line code change you get like 50 comments about people picking it apart but then when it's like you know a 2,000 line code change it's like you get a comment that's like you know you're you got extra white space here like no no one's no one's spending the time to go review these really big things because they're like the the cognitive load is too great for me to do anything meaningful I'm not saying that's a good thing by the way I'm just saying like there seems to be this uh this skew towards that so I would recommended something like a running draft pull request to get some feedback as they're going pick any other mechanism you want if you don't like that but some way to be getting

sign off or agreement visibility along the way uh what could have happened too is if there were early conversations about this and this isn't again it's not a bulletproof solution is how do we take something that is potentially going to be a very large change potentially and making sure that we can break it down into something that can be delivered in smaller increments right not always like one could argue that yeah sure if you put a lot of effort into every change you can make this happen uh it's not always feasible it's not always going to be optimal to do it this way I would encourage people to think about it this way smaller granular commits yes uh but you know I've certainly done big re factors and I'm like well this is a monster and for me to have gone and broke it down

into smaller pieces would have been would have almost felt like more work uh sometimes though and I'll just say it sometimes it is worth it to to have done the extra work right instead of trying to do it all at once to like save time in terms of how much you can land or how much rework you do sometimes it's worth breaking it into smaller pieces it might take you a little bit longer to do but now you have um a setup where you know if you need to revert parts of it or incrementally you can go to uh having more you know things being executed in production or in other environments or whatever it might afford you better confidence as you're building okay so the other thing and this is another huge one I guess is like this this overarching theme of like it's

a it's a different team right soft skills um I can't say soft skills enough on this channel or on dev leader uh it's something that the people I don't know like we I feel we don't pay enough attention to these things so you'll if it feels like I'm a broken record talking about it it's because I think it's so important and doesn't get attention that it deserves but in this type of situation if this person's not feeling supported by this partner team whether that's not timely reviews on things whether that's not engaging on uh designs and stuff like that to get sign off early and they're just like well man I have to get this stuff done like and I'm going to keep moving making sure that you can find ways to make that happen right that could be uh you know building some sort

of trust with the other team finding a person that you can start to build that with so you have a good contact there that could be you know if that's not working and you're struggling with that having a conversation with your manager about getting that support on the other team there are so many things that we could explore here but my my takeaway because I'm pulling up to CrossFit is that if you're in this type of situation and you're struggling to get that buy in from the other team bring visibility about that to your manager it's not necessarily that they're going to be the ones that solve the problem for you they might give you some tips or coach you but bring visibility to it because if you need help this is the kind of support that like your manager can guide you through they

might say you're going to go figure this out but here are some tips or maybe they're talking with you for a while about this and it's not progressing and your manager is like okay I have to go talk to their manager or I've been in situations where we literally need to go through leadership on either side because it's across organizations and they have different priorities so it's not for lack of trying it's just that like they have literally different priorities and they're not going to align so um I'm a CrossFit so I'm going to sign off here but I hope that helps uh if you have questions about this type of scenario or you've experienced it let me know in the comments um it's a challenging one but I hope I hope some of those tips help so I'll see you next time