That's why I thought it important to highlight when we do it wrong.
I've also had the experience where I pulled out a lot of the refactoring tricks from Martin Fowler's book applied them, then looked at what I did and found it had made it worse! Instead of good code, I had an "anti-pattern" sometimes called "Macaroni." Things were done, like replace conditional with polymorphism, which one would expect to result in well factored code, but instead we just chopped up the code into little pieces that didn't make much sense and fatigued us when reading and debugging.
Refactorings are experiments. Some of them need to be thrown away.
A surprise asset to my refactoring process has been git with its ultra-lightweight branches. When I start thinking that maybe this refactoring was a bad idea, I check my changes so far into a new branch, go back to trunk and start again.
Then an hour or a week later, when I realize my idea wasn't so bad, it's easy to switch back to the branch and continue from where I left off.
Refactorings which have unlimited "Undo" and "Redo." There's also the "Change Log" which is like a DB transaction log for your code state. You don't even need to think to check in a new branch. (Mostly, you save images when you're done for now, or you want to save log-replay time.)
I've also had the experience where I pulled out a lot of the refactoring tricks from Martin Fowler's book applied them, then looked at what I did and found it had made it worse! Instead of good code, I had an "anti-pattern" sometimes called "Macaroni." Things were done, like replace conditional with polymorphism, which one would expect to result in well factored code, but instead we just chopped up the code into little pieces that didn't make much sense and fatigued us when reading and debugging.
Refactorings are experiments. Some of them need to be thrown away.