1. Start with data and objectives. Document how different approaches impact maintainability, performance, and business goals. This moves discussion from personal preference to measurable impact. 2. Pick your battles. If it's merely stylistic, consider adopting the manager's preference. Save pushback for architectural decisions that significantly affect code quality or maintainability. 3. Present alternatives constructively. Show working examples of your approach alongside pros/cons. Focus on project success rather than being "right." 4. Seek compromise through style guides and automated tools. This removes personal preference from ongoing discussions.

From my point of view, it's essential to discuss the matter openly and respectfully. Take the time to hear their perspective and explain your preferences, using specific examples to highlight the advantages. Seek common ground and consider proposing a trial period to assess which style is more effective. Always keep the project's objectives in focus and be open to compromise. Involving the entire team for their feedback can also be beneficial. With mutual understanding and collaboration, you can effectively manage these differences!

When I ran into this, at first, I explained why I code a certain way, but if he doesn’t accept that and still insists that for whatever reason his strategy needs to be adopted, I just cooperate, because better to make him happy than get fired.

It is a good idea to understand the reasoning behind the Manager's preferences. There might be a good explanation for doing things their way. Next step is to find the intersection between both our preferences. That will allow me to start a healthy discussion by talking about what we agree. Then I can show my arguments in favor of the things we disagree and build my case. This avoids conflict and show I can be flexible with my own preferences as long as I understand the reasons behind the Manager's.

I was in a situation like this once. My manager wanted me to use a certain library I had never used. Not a problem; I could learn to use the library. The challenge was that the project was time-budgeted for 3 months. No extensions. I knew how to use another library that did the same thing that my manager's proposed library did. I suggested that for the sake of the time frame of the project, I should use the library I was experienced in instead of spending time from the 3 months making mistakes with the suggested library. Time was of the essence. He saw the wisdom in my suggestion and he agreed. Moreover, the library could be changed. The delivery of the product and the needs of the client was more important than coding preferences.