in reply to Setting boundaries in software development

Here is what I always suggest:

The best “trick of the trade” is peer review, yet the primary benefit of this is not to enforce (arbitrary ...) “coding standards,” but rather, to catch mistakes.   Mistakes in code-writing are rare.   What isn’t rare?:   mistakes in the understandings that led up to the design/writing of that code.   Stuff that might easily pass one pair of eyes is very unlikely to make it past two pairs.   People who are looking over each others’ shoulders are also talking.   Cubicle walls can become silo walls, and ... careful, now! ... if you are both “a coder” and “a manager,” the very-worst offender just might be you!   (Sure, you know the system inside and out, but does everyone else in your team know as much as you do?   Uh huh ... go fix that.)   If people are in agreement about “best practices” for your their shop, and if they are genuinely aware-of and involved in what their peers are doing alongside them, then high-quality code (and a high-quality total development environment) will be the result.   In all my years, I have never met a “genuine slacker” who did not care about what s/he was dong, nor a “genuine incompetent.”   Never.   Software developers as a breed know how vital their work is, and strive to do it well.   You just need to maintain an environment in which everyone including you can succeed.