How to handle teammates pressuring me (even publicly) to redo my work after I already explained my reasoning?

The original component had multiple issues and was not built with reusability in mind. I reused what was technically feasible and built clean, decoupled modules to support the updated use case.

Let me give you a different perspective on this: The team had one problem: the old component wasn't reusable. So you wrote a new one that is reusable and used it for your part. Now the team has two problems, the old component is still not reusable and you have duplicated logic in your code base.

So from a team perspective, you made it worse.

The correct way would be to go from one to zero problems, by writing the new copmponent and then making sure the old component is replaced by the new component everywhere. This takes more work and more time, but it is up to you, to tell that to whoever gave you the task. That is the solid, good quality way to fix it. See one problem, work on it, leave zero problems when you are done.

What you did is half the job. It might be a high quality half, better than what they did half, but it is still half.

I have worked in projects, where people always had better solutions, but didn't care to refactor all the project to use the new better version. It was hell. It was worse then just having a single not-so-good solution.

Talk to your team members. See if actually refactoring the whole project to use your better solution would be okay with them. If so, do it. If you do not have the time, talk to your lead that that is what the team thinks should be done. If you actually estimated only your half of the project, next time think about the whole project and give that estimate.

There are really two questions here - one that is specific to your scenario (which I have asked in the comments for additional info) and the more broader general question.

I am going to answer the general question:

You and other team mates have a difference of opinion about what should be done - what happens?

Well, imagine you are two opposing lawyers - what happens? You sit in front of a Judge and Jury, make your cases and then get a ruling.

And for the general issue - this is what needs to happen.

You need to have a technical discussion with Management about what needs to happen.

Then, you put forward your best argument as to why it should be done your way...

Then you let Management make a ruling on it and you abide by it

The above is the hardest part. Sometimes Management, whether for rational reasons or irrational reasons, won't rule in your favor. Whether it is because there are other factors that impact a decision that are outside of your scope (Costs, Security, Business reasons etc.) or simply because they don't like your idea - you have to stick with the decision.

Sometimes that will mean later on down the track you get to utter the 4 magic words, Sometimes it means that what you feared will happen doesn't - and they were proved right.

And as someone who has had to do that several times in my corporate life, I can assure you... It suuuuuuucks when your solution is rejected, but you have to put on a professional face and carry on.

Even worse when your manager is non-technical and clearly doesn't understand what is happening and so picks the solution that sounds like less work for them... (ask me how I know...)

I also don’t think a full refactor of the shared component is urgent - the current implementation works and is maintainable for the near future.

From that, I'm getting the impression that your teammate is correct in their review notes. You believed that using the component was not feasible, so you've created a replacement. However, you also don't want to go through a full refactor, so you've left the existing component in place. So you now have two different bits of code that are meant to support the same technical requirements, and you are hoping that the rest of the team transitions things over to your new code as new features are implemented.

That sounds to me like you've introduced duplicative code and your teammate is right to question this decision. You may be correct that the current implementation is bad and needs to be refactored, but the solution is not to do half of the work and call it good. At the very least, people should not be learning about this decision in a pull request. If you think that there are design flaws that require a major change (especially if you believe that implementing the full change requires more work than you can currently justify), talk to your team about it. If you believe that the work needs to be done before you can complete your task, convince your team of that and formalize it in a new task in the backlog.

It's possible that your team would still have opposed this, but at least you'd have learned that before doing the work. And if they agree that it's necessary, they would also be aware of what's changing and be able to reprioritize their other work accordingly.

The team lead is also new and still onboarding, so I haven’t raised this yet. I don’t want to appear difficult or as if I’m resisting feedback - I just want to maintain quality without being overloaded with work someone else doesn’t want to finish.

I can understand this fear, but if you have an issue with the way that your team is operating, you need to talk about it with your lead. At the very least, talking to them ensures that they at least know your perspective rather than inferring it from what your coworkers are saying. You're not going to build a good reputation with them by not communicating with them.

I gathered that despite their use of technical jargon my teammates are not as technically savvy as they want to appear to be, and they try to dismiss my feedback.

Try to stop thinking this way. You may be correct about your relative skill, but technical skills only get you so far. You also need to be able to work with the rest of your team. If you keep thinking about them in a "me vs. them" mindset, you'll entrench yourself against them and further these divisions.

My main problem is that I am feeling pressured and stressed out by their continuous messaging. I don't think a meeting will be more productive because they don't seem to want to understand my reasoning.

Do you expect this situation to resolve itself on its own? I suppose it could if you just set aside your thoughts and go forward with the plan that they are pushing for, but you obviously don't want to do that. If you want to go forward with your planned changes, you need to meet with everybody and work through the issues. Right now, you don't think that a meeting will be productive. Well, why don't you find out if that's true?

In these two cases I don't want to take their suggestion because it would be triple the work - I have already done an implementation, they want me to redo it introducing technical debt, which will have to be fixed down the line. Now it is working and the code is in better shape though it's still needs refactoring on their old component down the line. I don't want to fall behind on my tasks because of them. I don't want to be perceived as slow and not prepared because of them.

It is understandable that you don't want to redo the work, but take some personal responsibility here. Part of the reason that you may need to redo this work is because you tried to avoid communicating with the rest of your team earlier. You screwed up, and now you are dealing with the consequences. If you want to build a good reputation, own your mistakes and work to move past them.

Here's an answer of me being the devil's advocate. A lot of what you say applies to my experiences and I think we think alike as developers, but I think you are approaching the situation unproductively. One of the main issues here is that you seem to blindly assume that being right means that everyone should be playing ball, but that's just not how the world works.

So let's start off with some devil's advocating to show you the other side of your experiences:

How NOT to approach this

To me, it feels like I’m being pressured to rewrite my code
Separately, another teammate recently pressured me

It seems to me that you are interpreting "someone has a different opinion than me and voices it" as "someone is pressuring me". I would very much caution you to not make that leap. This advice is coming from someone who, like yourself, is starkly in favor of refactoring and continuously re-evaluating existing logic to keep up maintainability.

Be careful about "to pressure me", which has a negative connotation of someone knowingly doing something to you that they know is wrong to do. This phrasing will be taken as an accusation of unsavory behavior on your peer's part.

I gathered that despite their use of technical jargon my teammates are not as technically savvy as they want to appear to be

NEVER say this out loud or let it be the driver behind your argumentation. I cannot stress this enough.

If you said this out loud within earshot of the person you're referring to, I would expect HR to be involved at this point (by that person you're referring to), even if your lead believed your technical position to be 100% correct. This is truly beyond the line of what is appropriate in the workplace that if you say it out loud, your technical point becomes entirely moot.

The team lead is also new and still onboarding, so I haven’t raised this yet

I would offer the suggestion that your interpretation of pressure is in absence of your shared lead's ruling on the situation. Your choice to not bring this up to the lead should not be used as a way to argue that the other person's suggestion is therefore pressure put onto you.

You have so far decided to not involve your lead to help resolve the conflict. The absence of an authoritative ruling on this conflict is caused by your decision to not involve the person who can rule on this.

I don’t want to appear difficult or as if I’m resisting feedback

But you are resisting feedback. I'm not saying you're wrong, but I am recommending that you don't pretend to not be doing something that you are in fact doing.

I can be flexible - but in these two cases, the pushback was about avoiding poor-quality outcomes

Flexibility is not about what you agree with, it's about what you agree to. If the only flexibility you allow is within range of what you personally believe to be correct, then I would label that to be inflexible behavior from your end.

I find the situation stressful and unproductive, especially when the pressure is applied in front of leadership.

Based on the role I've inferred you are in by reading your question, I do not believe you are in a position to expect that person who disagrees with you to not speak their mind to others. It would also be incredibly restrictive for a workplace to restrict open communication like that, where someone is effectively not allowed to voice disagreement with someone else's proposal except to that specific person.

I don't want to appear argumentative and difficult to work with

Much like my earlier point, I'm not saying that there is no technical merit to your work, I very much believe there is; but you are being argumentative and you are being difficult to work with.

especially when I am relatively new to the team

You can't have your cake and eat it. You cannot first assert that you know what is better for the company/project, and then hide behind being new when facing scrutiny for your previous assertions of what is better for the company/project.

I don't think a meeting will be more productive because they don't seem to want to understand my reasoning.

Here's the flipside of that experience: a further meeting will not be productive because you don't seem interested in changing your mind or finding common ground; instead favoring accusing the other party of pressuring you and not being technically savvy enough to understand why you are right.

The most egregious flaw in your argument

In these two cases I don't want to take their suggestion because it would be triple the work - I have already done an implementation, they want me to redo it

Hey, do you want to see what you complained about with your coworker? Have a look at your own words:

Despite my explanation, the teammate continued to continuously message things like: “Why don’t you use the component, it’s already built?”

Here's some more cake that you can't have and eat at the same time. Is refusing to redo something on the ground that it has already been done problematic behavior (which is what you're complaining about others doing), or is it the right way to respond when you disagree with someone (which is what you're doing)?

Pick one, and then revisit your opinion about the other one so that it is consistent.

How to approach this

An inescapable fact of life is that unless you work in an empirical science, objective truth does not exist, only subjective truth. In other words, you can argue how right you are until you're blue in the face but if the people with actual authority do not believe you, then you are for all intents and purposes wrong. Antagonizing people is not the way to getting them to agree with you.

So how do you navigate situations where someone disagrees with you?

Firstly, discuss it with them, ideally in private. Don't tell them why they're wrong, because it will make them antagonistic and it will take you further from a resolution to the conflict. Instead, ask what their suggestion is, and what goals they are prioritizing.
If you spot a contradiction in that statement, or you can display why your proposal actually meets those goals, then that is your opening to convince them that your proposal aligns with their point.

This will work unless you strike on a point where both of you explicitly disagree about a fact, or a subjective call.

If this is a disagreement about a fact, then you pursue how to validate this fact and resolve it that way. If you say something causes an exception and the other person says it does not, reproduce the issue and confirm the behavior. There, now you know who is right and the other person should have explicit confirmation of that point without you having asserted whether they were or weren't savvy enough to understand what you were telling them.

If the disagreement is on a subjective matter, e.g. whether you should prioritize runtime performance or code readability, there is no way to objectively confirm this. This is something that needs to be escalated to a higher authority to make a judgment call about what the more important priority is in the given context. In this case, that means involving your team lead to help arbitrate the different goals that you and your coworker are trying to achieve.

If your coworker does not engage you in the conversation to help resolve the conflict, then you take that to your lead so that they can help navigate the conflict because that means they're being unproductive and this needs to be addressed, not by a peer but by their direct manager.

Calling others' competence into question, willfully not involving your manager for an ongoing conflict, restricting others' speech so that they are not allowed to publicly disagree with you, claiming correctness without being willing to prove said claims, ... are all deeply problematic behaviors that I would recommend your coworker escalated to the lead in order to address an unproductive (and sometimes downright hostile) attitude in the workplace.

I didn't say you were wrong.

Just to be very clear, at no point during this answer did I say that your technical opinion is wrong. It's very likely that you are right about the technical nature. You didn't provide any specifics but I would put the odds in your favor about the technical concerns you have with the old/existing implementation.

But this is mostly irrelevant for the workplace issue at hand. You are wrong in how you communicate with your coworkers and it is a significantly bigger problem than the technical hill you are trying to die on.

It seems that there is an extremely unprofessional culture around code reviews in your team. Code reviews are ideally self-contained - that means any discussions happen there, in public, for the entire team to see, interact with and learn from (this has a nice side-effect of making people be polite). Private messaging review feedback is the exact wrong way to do this.

You need to suck it up, tell your lead what's going on, and let them do their job. The fact that they're new is irrelevant, the fact that you're being pressured by other team members who are behaving unprofessionally very much is. This is a good opportunity for the new lead to exert their influence by reminding the team how code reviews should work and that private messaging is not the appropriate avenue to provide feedback.

This seems to be not about the code, but about power. The reviewer tries to make you do what he wants you to do - I'm just guessing the reviewer is a "he" and you are a "she", right?

Go to your team lead. Tell him or her that you are stuck because your reviewer is entirely unreasonable. He wants to force you to reuse code that cannot be reused for your purpose. As you said, instead of reducing technical debt you are making it worse. And your reviewer is stopping progress, making him entirely unproductive. Tell your team leader that maybe the problem is that you don't like to speak loudly, but that you can if that is needed to convince your reviewer.

Since this is not a software development site but a workplace site: Basically, the strategy is to make everything the reviewer's fault. Your code and your change are absolutely fine, it's the stubborn reviewers fault. If he says "Zaara could adapt the code", your answer should be "you know as well as I do that this code needs to die, and the sooner, the better. Or do you want to keep this code around? Are you telling me that, with a straight face?". BTW. The way to remove technical debt is not to completely wipe it out in one giant change that breaks everything, but replacing bad code with good code and then removing uses of bad code one by one.

Having stated

My new lead told me separately that he'll ask me to be one of few required approvers of their PRs but I don't see how that will work if my teammates continue with this pattern of pressuring me.

it does seem you do have management support.

Try to get the architect on board as well. Ask to discuss the issues you have presented here and see if they agree with your reasoning or if you should have done things differently. Maybe you will arrive at the conclusion that you shouldn't have done the rewrite for reasons X, Y and Z which the other team members cannot articulate. But now it's done and it may be worth keeping instead of throwing it away. At this point, it won't matter that you are new. You and the architect agreed about this approach and it's no longer just the new guy speaking.

Similarly with other issues. What is expected of you here? Do you need to fit in more with the existing culture, or are you expected to push against the status quo to establish practices and culture that will achieve better results? What you said about being a required approver would indicate the latter but I suggest you discuss this more and get a clear idea of the scope in which your management is willing to support you.

You should openly discuss these issues with your team lead even if they are quite new. Leaving them blindsided won't help them. And it may actually make you look bad since there are issues and you are either oblivious to them or unwilling to address these issues with the lead. It's up to the team lead to decide whether and how they want to address this, you shouldn't decide this for them (unless they are incompetent which doesn't seem to be the case).

That being said, I suggest not to involve management in deciding technical issues. Unless the managers have relevant technical background, they won't understand technical arguments and will quite probably side with your coworkers if they can make you seem like a blocker to progress. The management should determine the technically responsible person who will have both business and technical insights and should decide here. I assume that's the architect person. But it may be someone else - you should find out who it is.

If they discuss PR issues with you in direct messages, redirect them back to discuss this in the PR so that the discussion is recorded and visible to everybody. Not just in a chat between you two. This will also provide a trace for cases when someone blames you for blocking a PR and therefore not getting the work done. There's a significant issue with the code that's a simple fix and the author keeps arguing about it instead of getting it done? It's obvious who's the difficult one.

Do not let others push you around by discussing the same issue over and over. State that the issue was discussed, the decision was made and if no new information is available, there's nothing more to discuss.

Listening to arguments of the other side is important. Even if you find them completely moot from the get go, listening may help the other side also open up and hear your perspective. I am sure you know and did this. I'm stating this because it's quite easy to write someone off and stop listening completely. And it's also quite easy to end in nonsensical discussions going in circles. Know when to stop. You are the senior person, they have to convince you that their idea is better, not the other way around.

Honestly, I do think that being more direct and authoritative could help you here. Just say no. Don't be afraid of appearing difficult. It's exactly this fear that allows all of this to happen. Please be difficult to people who disrespect you, otherwise they won't stop. Anyone with sense will understand.