I spend most of my coding time reading code others have written. I think one of the easiest bits of leverage that programmers miss out on is writing great method names. Unfortunately it's an art, not a science, but here are a few things I'm pretty sure about:
Signposts for the next programmer
The main goal of these names should be to create clarity. Can I skim through your class and tell what it does by reading the method names? Will this name be helpful in a year from now? If you can avoid having to read your implementation to figure out behavior you will save MANY people a LOT of time.
Information over brevity
When in doubt, load everything you can into a method name. I'd much rather be refactoring a verbosely named method than one that gives me no hints.
Bonus: the long string is more searchable.
This does not give you free reign to break the single responsibility rule! Methods with 'and' in them are often a code smell. Short methods rock and are easier to name.
Speaking of code smell...
Implicit argument in function name
I picked this one up recently from Eric Normand's book 'Grokking Simplicity'.
This smell occurs when there is a value in the body of your function that is also in the name of your function. Often it will result in methods whose differences are in their name. This is a good clue that you can change part of the name into an argument and clean up some code. For example:
These might become one method where the callers are responsible for what is being 'started'.
Our new golden rule, if it is not immediately clear what your code is doing: then name it!
Be shameless about giving your method names clarity and packing them full of information and you will have code that is more maintainable, and a pleasure to read.