I have a Fred on my team. He recently took a few weeks to refactor a large part of the codebase which consisted of about 200 file changes. The problem with this

I have a Fred on my team. He recently took a few weeks to refactor a large part of the codebase which consisted of about 200 file changes. The problem with this approach is that he never discussed his changes with the team, leaving the discussion until code review time. Some refactoring doesn't quite need a discussion, but large changes should. It should go without saying that I think refactoring is super valuable. The way to go about it is to: 1. Recognize what in the codebase you see an opportunity to refactor 2. Discuss with the team (more experienced developers can have some useful suggestions) 3. Write a separate ticket for the changes (you can prioritize this after your required work) Obviously, #3 won't work if your group doesn't value refactoring. In that case, you should bring up the conversation. You'll probably find many/most of your coworkers will be in agreement.