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:

def start_queued_imports

def start_paused_imports

These might become one method where the callers are responsible for what is being 'started'.

def start_imports(collection_of_imports)

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.