[FroshKiller]

I've had success with two techniques, though they require patience.

First is setting a few short, firm rules about the specific implementations in a project's code. For example, one of my commandments is, "Do not log from library classes that query the database." Its main purpose is to maintain separation of concerns, but its secondary purpose is to get developers to ask why.

The other is similar, just more general, and that is (in the absence of formal coding conventions) picking two or three minor, common coding mistakes and being a dictator about them: declaring a local variable that's only read once, returning true or false in an if-then-else block instead of returning the evaluated expression directly, that kind of thing. Look for them first in code reviews and require changes on the spot. It gets folks to slow down a little and consider what they're doing, which makes a lot of difference in the long term.