The best thing I can say is that when interacting with other people, subtle course correction early on has a big effect in the long run. When I've tried to infl

The best thing I can say is that when interacting with other people, subtle course correction early on has a big effect in the long run. When I've tried to influence other people to change practices (in my case it was building more testable code), I've found that making the right path the easiest path is the best way. There are a lot of ways to do this. Code review is an easy one if you're not doing it already. It gives everyone the power to have influence over the code before it lands in the repository [1]. Building tools that make the right thing easy is also useful. I spent about a year making development tools to enable rapid testing of some of our JS modules, as well as doing a little bit of static analysis to automatically detect and fix certain classes of errors. By doing these things, every engineer gets guided to the right path without needing to reach out to anyone and without a huge cognitive overhead (like reading an interface guideline or something like that). [1] http://www.phabricator.com/docs/phabricator/article/User_Guide_Review_vs_Audit.html#advantages-of-review http://www.phabricator.com/docs/phabricator/article/User_Gui...