I have grown to learn to choose my battles when the PR is in a corporate setting. There's a lot of incentive for performative optics there, which makes people t

I have grown to learn to choose my battles when the PR is in a corporate setting. There's a lot of incentive for performative optics there, which makes people to prioritise "looking good" than "delivering good software". If the reviewer wants me to add an unnecessary `try... catch`, I simply do that. No point arguing with someone's ego, which takes way more time. If the reviewer is asking me to code for the eventuality that Google will suddenly change their the JSON model in their API response? You got it bud. You want to preserve some convention without explaining how it applies here? I will squish my code to it, keeping it correct. I know it makes my code less readable, more complex. But I care about delivering the value as early as possible. Also the code is not my baby, it's the company's baby. I try to fight comlpexity in the design phase, while also ensuring the ego folks get to have their optics.