While you're at it a style guide may be in order. Try to convert your team's current patterns into the set of new patterns that you think are better. This would

While you're at it a style guide may be in order. Try to convert your team's current patterns into the set of new patterns that you think are better. This would help to give others a sort of rosetta stone while they're making the switch. I always try to add a why after each good vs bad code comparison. Having a document external of your brain helps others to feel like they have a tangible set of goals instead of some arbitrary set of goals that nevon wants to have happen. I made my team's style guides repos on github so it's super easy to edit since it's straight markdown. Keep the pedantic discussions to a minimum. Sometimes it's just best to choose something because it's a single way of doing it.