Sometimes it just doesn't really help you to be technically right. It seems that software developers more than most act as if their time and what they work on is sacrosanct. In the past, I have been one of these problem developers. This is especially prevalent in large-scale corporate situations.
Devs seem to have a higher incidence rate of stubbornly doing what they want rather than just doing what is asked of them. I know I have been guilty of this myself. Egos can get in the way and they see some work-items as not worthy of their time. As engineers our operational priority is to enable focus and get stuff built and iterated on. When we do work we should work with the grain, rather than against it.
There are a few things I've found useful as cues to remind myself how to get better at my job while also working within the system built for me.
Everything Should Be A Ticket
Every task you handle should correspond to a ticket. No matter how big or small, you have to consistently track work or your JIRA board is useless. Make it easy for your superiors to understand that you're getting shit done.
Focus on the Ask
Oftentimes there will be the desire to do a refactor as you go with some piece of work. This is scope creep. Make a ticket for that work and do it separately. Feel free to submit the two work items at the same time, but keep the PRs separate to minimize errors and enable the tracking of work.
Personal Standards and Realism
You're going to introduce errors into your code. You can minimize errors by writing your own unit and integration tests. Let things simmer and write up a testing plan for your work. If you can, work with another developer to make sure all your UIs are manually tested. If you consistently hold your own work to high standards the likelihood that it will be bogged down in peer review decreases dramatically.
Become A Code Chameleon
Any repository you work on is going to have its own linting standards, commit formats, and other idiosyncrasies that you are going to need to respect. Review other PRs that have been merged and pay close attention to the common mistakes made. Provide exhaustive notes in your description of your PR and make sure you respect any contribution guidelines given in the repository. Leave any repo you touch just as clean as you found it, but be weary of trying to introduce any refactoring. Remember, "focus on the ask".
Always Establish Context
When working in a large org it pays to always establish context of what exactly it is that you're working on when communicating public channels. Remember that you are not the center of the universe and people may not be familiar with what you have been working on and need to be brought up to speed. Always err on the side of over-communicating.
When and When Not to Rage Against the Machine
Sometimes you'll run into corporate bullshit that makes no sense that you just need to fix and forget about. Rather than debating why another team's request seems like a waste of time, sometimes it pays to recognize that it doesn't always pay to be "right". Just solving the other team's problem (no matter how inane) can save a lot more time than debating the merits of the work. Try to recognize un-winnable battles and avoid them. As a rule of thumb, only try to politely defend your positions when what is asked of you forces you to lower your personal standards in order to get the work done on time.