Name methods after what the method does, don't name methods after how it works.
Examples are given in IntentionRevealingNames since the concept applies in any language.
I think the pattern name is a misnomer. The pattern, as given above, is good. But "what the method does" is not necessarily its "intent", but its "essence" (for a lack of better word). The what must not be confused with the why.
Nor should the why complicate understanding of operations within the method. The why can often be transient or abstract, changing with time or in application.
Perhaps such things as overriding and overloading can be useful in illustrating the difference.
Name services after what they do, and postpone the why until the point of usage