This blog posts describes the conflict as "providing value to other developers" vs "providing value to users", but that's false dichotomy. Refactoring isn't about providing value to other developers, it's about reducing the complexity and investment necessary to make future changes. That's valuable to the other developers, sure, but it's also valuable to the business, and also valuable to the users.
While there's certainly something to be said for assigning people responsibilities that work well with their personal strengths, that won't compensate for misunderstanding the purpose of refactors, how and when to apply them, and how to prevent the need for them in the first place. It's essentially hiding the problem rather than identifying the problem and introducing a relevant solution.
While there's certainly something to be said for assigning people responsibilities that work well with their personal strengths, that won't compensate for misunderstanding the purpose of refactors, how and when to apply them, and how to prevent the need for them in the first place. It's essentially hiding the problem rather than identifying the problem and introducing a relevant solution.