Refactoring large methods into a collection of small aptly named ones has its drawbacks too. When reading the code the reader has to keep a mental stack going maintaining what each sub function means/does. Sometimes this is worse than keeping it inline. There is definitely a good balance to be had between the two approaches.
You shouldn't need to keep a mental stack since as you say the small functions are aptly named. You just check once whether the function really does what it suggests and then you don't have to throw it on your stack the next time.
Exactly. Naming and proper design is very important. Tracking state changes through numerous "DoStuff" and "HandleThings" methods definitely represents additional intellectual overhead.
I think that if you follow the "One level of abstraction per function" tip from the "Clean Code" book, and you do a proper naming of your functions this problem disappears.
In extracting code into a method, you're intentionally obscuring what it does. Most of the time this is a good thing because you want to only focus on the details of the routine you're in. Thus, if you follow the "make your method do one thing" rule, you should be ok.
If your methods have no cohesion to them, then you will have problems breaking them down. But then again, I would argue that that's the least of your problems.
