If your development team is larger than 5 developers, it is likely that you have at least one developer with high quality standards. As your team size increases, there's a good chance, you have yet another, maybe even more demanding developer.
Considering you have two developers demanding high quality code, there is a good chance they have a very different opinion about what makes good code. Somehow, this does not necessarily cause conflicts however. In many cases, both colleagues appreciate each others demanding attitude and they are willing to learn from each other.
The question is whether they actually copy each other's habits though...
There are roughly two ways you can handle your code: you can consider code as a list of instructions intended to make the computer do what you want it to do. Or you can use code as modeling tools to describe the real world and make it come alive. The resulting computer program is considered an implicit result of the working model.
Instructing the computer is done on Infrastructure level. Building models on Application level requires a working infrastructure . In an ideal situation, your infrastructure logic and your application logic fit together well but are clearly separated.
If you have developers with different quality standard, the chances are that one is more interested in infrastructure level and the other is more interested in application level. This could be a perfect team.
More problematic is the tendency to mix infrastructure and application, not being aware of the potential problems of this approach. In my drawing a few posts ago, this tendency can be seen in developers with a preference for the Sun cluster:
Technology in the IBM cluster offers more options to make a clear separation between infrastructure and application. More about such technologies in upcoming posts.