*Don't program defensively in private procedures. Your code size will explode, because it will be mostly one piece of code checking against the faults of another piece of code.
*If you want to convey what a class does, it should name something that anyone could recognize, preferably a domain object. "Managers," "adapters," and "mediators" are a bad sign.
*Sequential is better than concurrent.
*If a class is getting big, you can break it down by thinking "processes" rather than "objects." You can encapsulate all the actions in some common sequence in one class. Even better, each action could register an event listener for the next step in the sequence, which unregisters itself when called.
*Consider encapsulating common patterns in a ''monad'' OnMonads.
*"Premature optimization is the root of all evil." You can spend a king's ransom and still solve a problem "efficiently" (as long as it's polynomial time, you're good). Then optimize.
*Too much coupling is bad, but too little coupling is also bad.
*The StatePattern is your friend.
*Source code should expose and explain the critical path. Guess which paradigm is good at concealing the critical path?
*FormalMethods are not cost effective, so don't tell anyone you're using them.
*If a program is going to second-guess your intentions, it had better be based on machine learning.
*...

CategoryProgramming