1. Factor for domain concepts rather than abstract 'machinery' in an effort to be DRY. DRY doesn't reap its value unless the thing you're avoiding repetition of

1. Factor for domain concepts rather than abstract 'machinery' in an effort to be DRY. DRY doesn't reap its value unless the thing you're avoiding repetition of are domain things. Be very intentional and consistent in naming, only using different naming when it makes sense for different contexts. 2. Don't be eager to concretize your abstractions. e.g. It may be the case that you need to use a state machine (SM). If you already have state types/objects, you can add what's necessary to clearly document and enforce transitions. What isn't always necessary is extracting the state machine portion to an abstract set of nodes/edges. Such a thing is useful if you have either dynamic SMs or multiple similar ones that are hard to maintain 'in place'. You can easily tell which path you're on if your class names don't have any domain terms in them and instead layer mechanism names. i.e. A class/object can implement a mechanism without having it extracted to being its own class/object. The above could be summarized to saying write "clear code" (domain level thinking) rather than the shallower "clean code" mechanical refactoring.