You can lead a horse to water, etc. What worked for me wasn't so much a mentor telling me xyz was good / bad, but metrics and quality gates - Sonar (idk when it

You can lead a horse to water, etc. What worked for me wasn't so much a mentor telling me xyz was good / bad, but metrics and quality gates - Sonar (idk when it was renamed to sonarqube or what the difference is) will flag up these issues and simply make the merge request unmergeable unless the trivial issues are fixed. Because that's the frustrating part; they're trivial issues, unreachable code and unused variables are harmless (on paper), just a maintenance burden and frustrating for whoever has to maintain it later on. But because they're trivial, the author doesn't care about them either. Trivial issues should be automatically fixed and / or checked by tooling, it shouldn't cost you (the reviewer) any headspace in the first place. And it shouldn't need explanation or convincing to solve either. Shouldn't, but here we are. But yeah, the next decade will be interesting. I'm not really using it in my code yet because idk, the integration broke again or I keep forgetting it exists. But we integrated a tool in our gitlab that generates a code review, both summarzing the changes and highlighting the risks / issues if any. I don't like that, but the authors of merge requests aren't writing proper merge request descriptions either, so I suppose an AI generated executive summary is better than nothing.