Why are some devs so insistent on doing a change one way when another works perfectly fine, is readable and maintainable and properly tested

Time pressure to finish the code as fast as possible!

@max19931 I'm the one in pressure, the other dude wants it in a different way using some other tech, both achieve same goal 🥲

Ask them. They have more context than us.
Isn't an unreasonable question for them to justify their request

@MammaNeedHummus yeah true that

One man's switch is another man's if/else.

@donkulator underrated comment. lmao.

@donkulator for real XD

One possible reason is consistency. When you introduce a new framework, new design pattern, new architecture, new naming convention, new whatever, than it’s worse than to have another solution which does the same, but keeps using the same tools and conventions as the rest if the code.

@Lensflare I was actually being the consistent one in this case XD I was being consistent with the pattern he himself had written, albeit ages ago

Some guesses of the top of my mind

1) They have been burned before. For example - this year my team had 3 issues caused by people adding code to the end of functions and not noticing some nested condition with a `return` in the middle of the function. So I now advice against those `return` placements

2) Code review culture. Some devs have the idea that they approve a PR if it works. Some struggle to just approve a PR and seem to actively hunt for some detail to object to. This is probably also because they have been burned some time in the past - for example they might have complained about some old code and someone did a git blame and said "LOL - you moron - you approved this code!" so now they feel super-protective over every line of code that goes into master. At this stage you should have a discussion about how your want your PR approvals to work and say "Please consider if your suggestion really is CRITICAL or just a stylistic detail that's a matter of opinion"

@jiraTicket I think your both scenarios are perfectly valid. Mine sadly was like using the frameworks other aspect to accomplish something that I was doing with yet another tech, but the other aspect had never been used in the entire code base, and I can't tell you how bad it actually is, it leads to a lot of redundant fields and an explosion in unnecessary files