> "Trying to persuade people to avoid technical debt at all costs" - put in a linter and concrete rules (even if a rule is loose, note that in writing) or devs will get upset and think you are singling them out.
I went from a company with no linter or style guidelines and PRs were an absolute nightmare. Eight devs, eight completely different styles, each insisting theirs was right. I wasn't able to turn stones into loaves (i.e. I wasn't a Senior Dev at the time), so my style was categorically incorrect. I switched to a company with an aggressive linter, and all that superfluous debate over tiny patterns and "personal preference" went out the window. I no longer dreaded PRs.
I think that's the main benefit by far - avoid useless debate. The icing on the cake is that I can write code in my style (tabs instead of double spaces, parens on new line, whatever) and then have my IDE or a CLI command refactor to the team style before putting up a PR, so it's really not an issue.
I usually default to some large company's style guide so it's difficult to argue against. For example, for .NET we use Microsoft's style guide for React we use Facebook's, etc.
I went from a company with no linter or style guidelines and PRs were an absolute nightmare. Eight devs, eight completely different styles, each insisting theirs was right. I wasn't able to turn stones into loaves (i.e. I wasn't a Senior Dev at the time), so my style was categorically incorrect. I switched to a company with an aggressive linter, and all that superfluous debate over tiny patterns and "personal preference" went out the window. I no longer dreaded PRs.