It is important to be able to keep track of the control flow of a program and that is again why it is useful to have clear names that determine the sequence of method calls within a program. The various ways this is done is described in the next chapter of Implementation Patterns that I am currently reading.
One interesting thing that Kent Beck mentioned in the chapter is that he has previously come across methods whose main purpose was to clearly define behaviour of a piece of code, wrapping a variable that sets a value in a method that explicitly says this.
I would not have thought about doing this as it seems to be adding more code than is sometimes necessary, but again this is a trade off, and he admits it could sometimes lead to more complex code than is necessary.
When I build on top of relatively simple code, starting with a degenerate idea , keeping track of all the different parts and control flow as the program gets more complicated. Going through the names and thinking about if I should create methods and classes for behaviour is probably a good idea and something I should do as I go instead of deferring the refactoring which will just get more difficult.