1. Add comments that explain why. This might be a technical reason (like, this query is structured in this weird way to convince Postgres to optimize it correctly) or business reasons (e.g. users outside the US sometimes put the street number at the end of the first line of the address)
2. Keep each method at a single level of abstraction. Don't mix high-level business logic like send_email() with low-level logic like constructing a SQL query.
3. Break out separate functions just to give a block of logic a name. This results in more context when reading the code, shorter functions, and better stack traces.
4. Don't work too hard to avoid duplication. A little duplication when two codepaths do something similar is much better than having a weird abstraction that exists just for the sake of deduplicating a few lines. (But do work hard to make sure that there is a single source of truth for important values and decisions!)
5. Prefer many functions to a few, configurable functions. When you have a function with, say, 5 boolean options, that's 2^5 = 32 cases you need to support. In reality, the function might only be actually called 6 or 7 different ways, so you don't actually need all those combinations. Having more functions that do one thing makes it much easier to tell what a particular piece of code is actually doing.
6. Start by explaining what needs to be done as though you are telling another person, and then transform that into code. It tends to result in more readable code than starting by explaining it to a machine.