A common definition of a "Code Nazi" is something like "a programmer who rigidly enforces arbitrary programming standards for their own unexplained reasons." Personally I think this definition misses the mark. Most of the time there are very good reasons for enforcing programming standards. Over time though, the explanation as to why may be lost in the history of an organization. The point here is that you have to have a set of guidelines that apply to the code that's written in your organization. Understanding the "whys" of these guidelines is in my opinion what separates the master from the apprentice. In addition understanding the intent of a particular rule allows you to make a solid determination as to when to break or bend a rule. This is what practical programming is all about. In our case where the rubber meets the road is in the handling of licensed technology. I have chosen an extend instead of replace methodology that in some cases creates additional up-front work but should generally make our interactions with the underlying technology easier to deal with.
I think at this point in time most people would agree that the maintenance cost of a piece of code is often times the vast majority of the cost of the code. This implies that correctly writing any piece of code upfront, even it if takes significantly longer, will give you future cost savings. This has to be tempered by a realistic view of what the future of that particular code is going to be. In practice this often takes the form of using your most senior programmers to handle the most important pieces of code. This probably does a disservice to those who are new to the craft as they often end up writing one-off or throwaway type code. So getting your more experienced people working side by side with your best people on your most difficult problems seems like a good idea to me. If you can get everyone on the team hitting the high notes (to paraphrase Joel http://www.joelonsoftware.com/) your team will do better work. There is no better way to understand a difficult problem than to explain it someone else in enough detail to have them implement the solution.
So, understand the lifetime of the code you are writing. Engage others on the team when working on hard problems. Mentor and invest in your more inexperienced people. Look at things from a practical perspective and don't lose sight of the big picture.