Refactoring code is good, hard work, especially at first. It takes a lot of time and energy just to make small changes in code to make it more readable, testable and usable. It is hard to keep up; sometimes you might think to yourself "Well, It will okay if I just ignore this potential refactoring, the code seems to work". But more then likely, that kind of thinking will turn around and bite you right in the bum. But with some patience, perseverance, and blood-sweat-and-ov, you will hit a few watershed points in refactoring, and start to see some major benefits.
I think that there are some major watershed marks in ones progress in refactoring. The first of which is knowing what to refactor. Knowing what does, and does not smell good. Some of this is pretty easy to figure out, the
Arrow Anti Pattern is a perfect example. Other code smells are more difficult, because they may have more to do with your particular language, problem domain, or even the coding style of the originating programmer.
The next major watershed in refactoring is being able to actually do the refactorings a lot easier. You know, or have a good idea of, the steps need to be taken to get the code to a better point; like using
Guard Clauses to eliminate the Arrow Anti Pattern.
And the tastiest watershed of all: the code you write is good enough so that refactoring it is basically painless. This is where refactoring comes into its own. By learning to identify bad code and knowing the steps to make it good code, you also learn the steps to writing good code in the first place.
