Yes. I think that instead of saying "Stop thinking!", this might inspire us to respond with a more positive tone, like "Great idea! Let's write it down on this list, and get back to it when we've finished this sequence of moves." IE: Finish one thing before going off on some tangent.
Fully agree and actually had a similar experience some years ago. We were faced with a larger piece of code, which was starting to become a big ball of mud not with no clear separation of concerns. We started by defining new boundaries for these concerns and in a first step just moving the respective pieces of code to these new contexts, without too much thinking. After that we had least had separated the code according to the different domains. Only then did we start to explore and think about how to couple them, which was the much harder part. But at least we could base the decisions then on a much clearer picture.
Don’t Cross the Beams
Yes. I think that instead of saying "Stop thinking!", this might inspire us to respond with a more positive tone, like "Great idea! Let's write it down on this list, and get back to it when we've finished this sequence of moves." IE: Finish one thing before going off on some tangent.
("Squirrel!!!)
Fully agree and actually had a similar experience some years ago. We were faced with a larger piece of code, which was starting to become a big ball of mud not with no clear separation of concerns. We started by defining new boundaries for these concerns and in a first step just moving the respective pieces of code to these new contexts, without too much thinking. After that we had least had separated the code according to the different domains. Only then did we start to explore and think about how to couple them, which was the much harder part. But at least we could base the decisions then on a much clearer picture.
Great post on refactoring well, Kent.
Loved the in-depth example and the thought process every step of the way