Will They FIRE Me?! Keep Reworking My Software Deliverables [360 Video]

Will They FIRE Me?! Keep Reworking My Software Deliverables [360 Video]

• 186 views
vlogvloggervloggingmercedesmercedes AMGMercedes AMG GTAMG GTbig techsoftware engineeringsoftware engineercar vlogvlogssoftware developmentsoftware engineersmicrosoftprogrammingtips for developerscareer in techfaangwork vlogdevleaderdev leadernick cosentinoengineering managerleadershipmsftsoftware developercode commutecodecommutecommuteinsta360 x4insta360360 video360 camera360 vrlayofflayoffssenior engineer

A viewer wrote in to ask about a situation they're in: They are nervous given layoffs and the tech landscape, but they also feel like they're constantly having to rework their deliverables.

Is this... normal?

📄 Auto-Generated Transcript

Transcript is auto-generated and may contain errors.

hey folks I'm just getting ready to head home from work here um says about an hour drive because there's a ton of traffic which is lovely I'm going to go to a question that came in on Instagram and this person goes on to say for a little bit of background um they landed a job they were looks like they were laid off they were laid off they got a new salary that's almost double which is great uh they said their job is great they've been there for almost five months they're learning a lot smaller company but they have a fear that they're going to be laid off again which I don't you know I don't blame people for having that kind of a fear um I find they're always working late to try and prove their worth um I feel like they're starting to get

the hang of things or when they feel like they do uh sometimes I have to scrap hours of work because my senior wants it done another way and then another way and so on um and then he's asking or he or she I think it's a he asking if that's normal so that's part one I guess and then they did want to express like that person the senior is actually a super nice person so they're not saying like oh it's because they're an like they actually you know really appreciate them they're saying but that seems like it might look bad from their manager's perspective if they constantly have to go back and ref Factor things feeling kind of guilty about it um and again the kind of expressing they don't want to lose their job they feel like it should be progressing faster so I

wanted to talk about this um number one because I want to answer this person number two I think there's actually something here for a bunch of people so insta 360 is going let's see what we get um okay so if you want questions answer just a reminder for folks please leave your questions in the comments or do as this person did look for Dev leader which is my main YouTube channel uh look for Dev leader on social media send me a message or if you want to message me on LinkedIn my profile should be open so you can send me a message to Nick centino on LinkedIn um just going to get rid of this parking lot here okay cool so um I think the first part here uh is it normal right so is it normal to have to go back rewrite refactor things

um not it's hard to say like yes or no uh because I think there's a lot of factors that we don't know in the context here ideally this isn't something that you're constantly having to do right if you have to keep going back to something um probably means that we when I say we like as a as a team kind of missing something the first time around now that in and of itself is not like you know like a punishable offense or something there's it's not um it's not unheard of to have to go back and change things um there's times where people explicitly make decisions like that to go back and then have to refactor stuff because they were trying to reach a deadline or for whatever other reason unblock a team right like we'll get it working this way unblock a team go

back and and fix it up so like it's not it's not wrong right and I think the other thing to keep in mind in this particular situation is that um as someone who is significantly more Junior to this senior developer that's helping like that's it sounds like my understanding here is like they have a senior developer signing off on this stuff and um kind of working in the collaborative way and a huge ywn oh my God I felt that one coming for a while let's get some caffeine in the system um still feel like I'm dead for my crossr workout in the morning but you know it's the the the Comfort I don't know like I think that's the word I want the comfort that I'd like to try and instill to this person is like look if you're working in isolation Okay you're working

completely in isolation and and you are pushing stuff up and no one's reviewing it and then later someone's like hey man like don't want to do it that way like do it this way and then you push stuff up again and no one's reviewing it or signing off on it and someone comes across it later they're like hey man no um I think that's a process that we can we can fix pretty pretty easily right it's like have someone look at your your before you you commit it to production right but I don't think that's what's happening here I think this person is getting sign off from this more senior developer um getting their input that kind of thing and if that's the case like I don't think that you should be like taking like blame for the whole thing and feeling bad about it

like it might be something that you know this other developer doesn't have quite the foresight or there's unforeseen circumstances whatever like things that they didn't catch and again like could could we improve this scenario sure I don't have enough context for this scenario but the point is like that's not the end of the world necessarily right it's just something that you want to improve so to the first question is this normal right it's not necessarily super common but it's not unheard of right if you the first time you do something it might not be exactly right ideally we try to minimize that but um I I wouldn't kind of look at this and beat yourself up over it um so as we get into the next part of this that was a pretty quick pretty quick uh coverage of the first part there's a long

drive ahead of us um if I end up flying through this I'll just end the video early but um I think like one of their concerns right I don't want to look bad to management another God oh my God I'm so sorry it's like I I can't hold it in or else I'm going to be making funny faces the whole time um the uh I don't think that that alone looks bad to management and I let me let me add in the disclaimer if you're new to the channel I am a engineering manager I've been managing engineering teams for almost 13 years I'm a principal engineering manager at Microsoft for almost five years this isn't something I would look at on the surface and just be like Oh Billy here must be an idiot uh so unfortunate that we hired him and I'm GNA have

to figure out how to get this person out of here like like certainly not um and certainly not just from like looking at things on the surface like that now if this came up to me in a one-on-one conversation with Billy I'm just calling this person Billy bil by the way if Billy was you know telling me hey like you know feel like I spinning my wheels a little bit here like I have to go back and do this work again um we're revamping things we're revising the code again and again um that would be something I would ask about for sure but um I think there's a difference between being like Curious and asking and and being like just assuming that Billy must be dumb or something um and so what I would want to be asking this person that we're calling Billy is

like hey like okay so um I would be asking for the context around like okay so so and so is telling you to um to rewrite this again or to refactor it or it's not right um since the first time uh you know have you have you been talking with them beforehand and if the answer is you know no like I'm just pushing up code then I would say okay well I think if they have feedback on this kind of stuff and you're getting it repeatedly I think this is a good opportunity that we could go earlier in the process make sure that they're looped in right like I feel like that's a pretty quick wind um and kind of coaching that person through hey like if you want to reduce the friction with this kind of stuff it's just uh more helpful to have

earlier touch points really same thing goes for design docks right uh designing things in general uh code I'm a big fan personally of like um instead of if you even if you know that you're going to be doing a bunch of work and potentially having a big poll request or whatever I get sometimes it feels like a little bit contrived to try and break up pull requests into like smaller pieces I understand I encourage it but I understand when it's feels a little awkward um but you know if you're going to have a big poll request I would say like try to get some eyes on it earlier even if it's not done right if you have to go touch a bunch of code get eyes on it get something started have people look at it talk about your approach before you get started so

having an earlier touch point is a huge opportunity for reducing waste right because if you're going to go through this process and have to do it again like let's avoid that so that would be the first thing that I want to talk to this person about is like hey if this person is coming back to you and they have feedback and this keeps happening can you have an earlier touch point with them and they might say instead of oh no I haven't done that now they're saying yes like I actually sat down with so and so we talked about it ahead of time and um I actually you know had them review the the poll request and they're they were good with it okay so now now I know or at least I have reason to believe it's not that this person either uh this

person has in Billy in this case or Billy that wrote this I think we were calling them Billy um it's not that like Oh Billy doesn't understand the process or or Billy is incompetent and is unable to to do this kind of thing it's like okay no Billy is not working in isolation Billy is trying to do the right things here um and actually has someone that's more senior signing off on this stuff okay so what's up right um to me and then I'm not going to go oh well so and so let's I don't know I'm not good with names Sally is the other engineer right um Sally's the senior engineer I don't immediately jump to oh well then Sally must be incompetent because they're telling Billy you know that this code is good then changing it blah blah blah um like I I

don't personally my style is not to jump to just blaming people or assuming that they're incompetent or whatever it's like okay well I would be just curious like hey like what's what's up if we feel like we're we keep missing something here and it's not a I just go back to like it's not a blame thing like hey if you you know the first time you guys did it and you're like hey it feels good and and then later you're like oh we're going to have to change it that's not like I said it's not unheard of so what are you going to like how would you learn from that is what I would ask how would you learn from that to go okay well that was a gap we missed it like you know no harm no foul but you want to learn from

it and if it's happening again I would say okay like is it the same thing because if you're having the same thing happen and you're not learning from it that's where I start to say okay like what like what are we going to do differently here because clearly it's not it's not working we're not learning but if it's something different altogether it's like it's just another learning opportunity right it's so for me as a manager I'm not looking at this kind of stuff like oh these people must suck right and then especially like blaming the more Junior person and it might be for me as a manager it might be a good opportunity for for to talk to Sally in this case and say hey like I know you've been working with Billy on this stuff sounds like you guys have been having a bit

of back and forth having to go revisit some stuff and I would just be curious like any you know what have you learned from going through that like is there is something up with the code base did we not have clear requirements like did something come up and we had to Pivot and it's like only kind of after the fact and we didn't plan for it like again just being curious because at the end of the day my job is not to go around ber raing people and make them feel like for messing up my job is to help people like engineers in this case my job is to help software Engineers on my team do their best work possible from my perspective if you have to keep going back and revamping things and rewriting them and refactoring them constantly I feel like that's not

you doing your best work possible so how do I help you with that and for me in my opinion to help you with that I have to be curious I have to ask question I have to to listen to what you have to say about it so then I can help navigate that with you so to this person that wrote this whoa I guess we're going to be sitting in traffic in the fast lane uh sorry I had to had to hit the brakes pretty um to the person that wrote this like no uh as a for at least for me as a manager it's not like a a red flag or something but I would probably want to talk to you about it to make sure that you're supported now we can flip this around a little bit okay because I know that at

least the way it sounds the way this person wrote this in is like they enjoy working with the other engineer like the more senior engineer that I called Sally in this case is like they are a nice person it's not like there's a a conflict there and they're difficult to work with I'm assuming based on what I heard so what happens when that interaction looks different and not maybe not that like they hate Sally or something but um what happens when you know that that working relationship is more difficult right so Sally's always getting in the way or you know they're Sally's not being supportive in in all of this because you know again based on how I read what was said it's like the senior Engineers being supportive and being like Oh like not blaming the junior it's like they signed off on the

stuff so they were part of that decisionmaking process but um you know what if this looked different what if this the more senior engineer was just blaming the person and being like no no you screwed it up you should have known um I think that's a very different situation and again I'm not immediately jumping to oh well this junior person must just be an idiot I would want to go dig into it and understand and that's where the source of slowness is I I see you okay maybe things will get better who knows so it's not unheard of to have you know situations like this where people have to go back and keep revisiting code uh certainly would not make me think oh better get rid of this person um but again like let's I want to try to take a different angle sorry a

little distracted because that's the trying to see if the traffic is going to open up and we got people getting frustrated weaving in and out of cars and stuff so just paying attention um we can have situations where uh like we can we can comp I know it's not going to be identical to what this person's describing but I wanted to take a different angle so imagine you have a situation where you have an engineer that's working on something and they're getting signed off from a senior engineer so they kind of got on the same page great trying to make forward progress but then another senior engineer comes along and they're like nope like that's not okay right then this more Junior engineer is kind of like oh well okay well I mean I worked with so and so on this and now you're telling

me it's not okay like okay like I'll change it to what you want and then you change it or sorry the engineer in this case changes it to what the more senior engineer wanted and guess what happens now the original senior engineer is like whoa whoa whoa what's this where did this come from why do we change this now you have a more Junior engineer that is caught between the strong opinions of two more senior engineers and they're kind of like you know I I don't know if you've been in a situation like this but it sucks because no matter what you do someone's going to be unhappy it's it's not a winning situation right there isn't a a you know a side you pick and you end up winning there's a side you pick and then it ends up making someone disappointed or uh

unhappy so but there's Alternatives which is nice so if you're kind of caught in this situation I think the best thing to do is try to bring in both of the people or if there's multiple beyond that bring them together in a conversation and have a like a discussion about it right I can't stress that enough because you were you're going to remain caught between them and it's going to feel like you're going to l lose engagement on the work you're going to feel like you don't own it at all because what do you own right you can't you can't make the decision clearly and it's not your fault because you have other people that are going no no no like you can't do it that way you have to do it this way and they don't agree so get them together and on the

same page now going forward if that was in a particular area of code or a particular domain you might say hey next time I like based on my experience I know that uh you know person a and person B had differing opinions on this stuff I should probably Loop in person a and person B from the beginning right and just at least get you know pick their brains on this stuff make sure that they have some agreement um you know just like kind of again like learn from these scenarios where you're like that didn't feel good what what what I do different because being caught between two people or more that are the ones that are responsible for signing off on your changes is like like I said it's you're you're losing no matter which direction you go so you you pick a third Direction

which is get them on the same page so what other advice can we offer this person because I don't think that they're in that situation but um I would like them to keep that in mind because it's uh a very plausible one that can come up um the the more disconnected a manager is in the situation I just described or the first one um the more disconnected the manager is the more likely it is that they're they're going to take or going to what's how do I want to say this like they're going to take it at face value so if uh in even the last example I gave right like someone has to keep doing something back and forth between two Engineers it might be like hey like to the person that's kind of caught between like do you just not get it like

do you just not know what you're doing if you're very disconnected as an engineering manager right which is why I said like I want to make sure I'm asking questions and being curious I don't go into accusing or assuming like oh they must just not get it it's well they're clearly having a challenge so let's let's go try and understand it right not all managers will do that I'm not trying to say that I'm better the best or something like that but trying to explain how I would navigate that and I think it's important like context is is key here uh and your scenario may be very different than scenarios I've lived or someone else so if you feel like your manager is that kind of person who's disconnected and not willing to like seek to understand things that and yeah I could maybe imagine

why that might be um another reason for you to be kind of like nervous or concerned but again I think that I don't want to say there's a solution uh that fixes the problem but I think there is a a path forward that helps and if you've watched my previous videos you know exactly what I'm going to say if you haven't welcome to welcome to code commute and other videos and Topics by Dev leader but uh I will always say make sure you're trying to have conversations with your manager right like you could be proactive in these situations and raise awareness to your manager and say hey like you know um when if the manager like hey what's top of mind for you this week or like you know what's going on you could say hey like I'm feeling like uh in some cases I'm

uh I'm feeling like I'm doing a bunch of rework and kind of uh concerned about that or feeling disengaged or or whatever you know however you're feeling about it and like proactively raise awareness so I feel like if you have a good manager they're going to ask you questions and say okay like tell me more like trying to understand you and even if you have a manager that might be trying to like say you know take taking their mental notes like oh I guess this person's not as productive as I thought you can still use that as an opportunity to try and highlight like hey look like I've been working with this other person right it's not me working in isolation you're trying to bridge the gap in their understanding or the bridge the gap in their visibility right I don't like to just assume

that like um that managers are like malicious right I you know I like to think that I hope I'm a good manager I try to be um I think that there's other managers that maybe they're not great managers but it's not because they're malicious right they just might not do coaching very well they might not listen very well uh and then I think that there might be some people that uh I don't know I must admit there's probably slightly malicious or just like pretty awful managers um maybe very controlling whatever however you wanted to find a bad manager but I think that people can have good intentions and still not necessarily be good managers so bringing awareness of this kind of stuff and saying hey like here's uh because I've talked about this in other videos like you don't have to make your your uh

your 101's like a pure status update like here are the lines of code I pushed and here are the tests I wrote and here's you know you don't have to do that um but it's okay to talk about your work and I think this is honestly like a really great topic for a one-on-one to be able to say hey I feel like I'm doing a bunch of rework uh I'm I'm concerned that that's not as productive as I'd like to be um I've been working with so and so they've been very supportive right you're not throwing that person under the bus they've been support based on what this person said so you know I've been supported um but we keep finding some things and have to go back to the drawing board and you know clean things up um and you know I think you

need to ask yourself what's your goal here because you clearly have concerns right and uh you can say just I wanted I wanted to bring some visibility to you on that can ask your manager if they have any thoughts um if you have some more like specific requests around feedback then you can bring that up right but my point is that I would much rather encourage people to go talk to their manager about this kind of stuff versus just like I don't know like sitting back and being like Oh now I'm now I'm nervous that uh layoffs are are coming because because I had to go rework some code a couple times right like I said I'm not trying to blame this person for having a a response like that but um instead of passively waiting and then feeling that like you could be more

proactive in trying to raise awareness take ownership of that and say like this is a thing that doesn't make me feel good do you have thoughts on this or you could talk about what you've t uh tried through talking with the other engineer the more senior one because maybe you guys have had conversations and said hey like we don't want to be in this situation again what like how are we changing things up so proactively share your learnings but uh ultimately I don't think that that's like I don't see that as like a a deal breaker or something like that if uh if this is something they just continue to happen all the time I would like as an engineering manager I'd be trying to to get to the root cause of it because it's like to me something would be off if every time

you push stuff you're like oh like got to go rean the whole thing um now I'm done videos on Tech dead but like maybe um maybe another whole angle on this is like do we know why maybe it's a good question to ask do we know why the the more senior developer wants things Rewritten what is the reason is it because there were um the pattern is brittle and there's bugs and it's hard to test is it because you were using an old pattern and someone else called out in the code base you actually use a new one like what's the what's the reason here I think that might be helpful to understand but I think that's probably it to be honest um yeah I don't know like I I probably said it too many times now I I wouldn't and it's I don't know

it's very it's easy for me to sit here and say it and be like I I don't know I wouldn't be concerned for this person and being laid off and whatever else like I I understand that like you've gone through it once at least that's probably pretty awful to go through so I I I hear you but I also don't want people like creating um I don't know like I don't want people to create anxiety out of something so another thing you could be doing is going back to the conversations with your engineering manager this person said like I feel like I could be progressing faster so that's your expectation what's your manager's expectation right like have you had the conversation about that that's another easy one and the more specific you can be in asking for feedback the better so you could say like

hey like I know um I was working on this project even and you know you would know that you had to go back and rewrite stuff and you could say like you have any feedback on it because their perception might be like hey things are going really good but instead of like creating this anxiety for yourself where you're like it's this unknown right I don't I don't know if I should be ramping up faster you can ask them hey like you know I was able to to work through this project I had to do maybe a rewrite or two uh some part of it and like uh bring bring up some other things and just say like you know with someone who's uh ramping up uh do you feel like I'm making good progress or do you have any suggestions for things that you would

want me to change and if you can be kind of targeted with your your request for feedback you can probably get much better answer versus just like keep doing what you're doing so terms of easing anxiety that might be another thing I layer into there but um I think I'll wrap it up there so I appreciate this person sending in a question a reminder for folks if you want a question answered of course course leave in the comments or send me a message to Dev leader on social media that's my main YouTube channel as well and speaking of the main YouTube channel if you want your resumé reviewed uh please consider submitting your resume um you can see the instructions on my main Channel if you go to the playlist that is for rum reviews uh at the beginning of each resum review I explain

how to submit your resume so um you can go check out one of those videos and then if you like I'm not forcing you to go watch the whole thing but if you want to see like the style of the review um then you're absolutely welcome to do that and I I would appreciate it and I'll remind folks that like those resume reviews are not um it's not a roast I'm not there to make fun of you or make you feel bad and say like hey look look everyone look how dumb this person is because their resume is not perfect um it's absolutely not the case I've had a request to to roast a resume and I told the person I won't because I said I don't think that's really helpful it might make for good video content right like maybe I'm being stupid and

that would drive more views but like I don't I don't want to do that it makes me feel bad like I feel gross when I'm um like insulting people so definitely check that out if you're interested at this point in time it's a it's a free thing I'm doing so uh would try to help and it's you know it is my perspective it's not going to be a universal truth or something so important to keep in mind but I uh I think that's it folks I'm just getting off the highway here so thanks so much for watching and I will see you next time take care where's a stop button

Frequently Asked Questions

These Q&A summaries are AI-generated from the video transcript and may not reflect my exact wording. Watch the video for the full context.

Is it normal to have to repeatedly rewrite or refactor software deliverables based on senior developer feedback?
I think it's not necessarily super common but it's not unheard of to have to go back and change things. If you have to keep revisiting something, it probably means the team missed something the first time around. It's not a punishable offense, and sometimes refactoring happens to meet deadlines or unblock teams. So, I wouldn't beat yourself up over it.
How should a junior developer handle conflicting feedback from multiple senior engineers on their code?
If you're caught between two senior engineers with differing opinions, it can feel like a no-win situation. The best approach is to bring both seniors together for a discussion to get them on the same page. This helps avoid confusion and ensures you have clear guidance moving forward. It's important to communicate and facilitate collaboration among seniors to reduce friction.
What can a developer do to reduce the need for rework and improve progress on software projects?
I recommend having earlier touch points with senior developers before finalizing work. Getting feedback early, even if the code isn't complete, helps catch issues sooner and reduces wasted effort. Also, proactively communicating with your manager about concerns or rework can help them support you better. Being specific when asking for feedback and sharing learnings with your team can improve the process and your progress.