I tend to disagree but this might be my biases at play. Refactoring starts from first principles, almost all examples include the reverse refactoring as often

I tend to disagree but this might be my biases at play. Refactoring starts from first principles, almost all examples include the reverse refactoring as often you need to undo optimisations a few steps before you can move forward in a different direction. I was recommended working effectively with legacy code by the same types of managers that expect forever returns off the same code. They like to point out how that book encourages small patching without refactoring as refactoring is often fruitless in short term money terms, whereas Fowler tends to advocate refactoring as a healthy and necessery part of software development. I can't say I hated working effectively. I found TDD by Beck more useful, and working effectively with unit tests to also be worthwhile. All of these books cover a lot of similar ground. If you're going to read only one or two I suggest TDD > refactoring and avoiding the others. (Just my opinion based on what I got out of them reading after 10 years on the job, I suspect juniors might have a different take)