Ideas for working with a teammate not following team defined standards?

Question

Working in a team environment how would you handle a developer that refuses to follow team defined standards?

1) Developer is at a junior level

2) Developer is at a peer level

3) Developer is at a senior level

I know this is suggestive but I feel that it would benefit developers by making them more professional. Thanks!

Answer 1

If there is a standards document in place, then simply point to the document and tell them that they need to adhere to the standard. If there is no document in place and it is sort of ad-hoc "this is de-facto how this team has been coding", then organize a meeting to create a consensus on what the team standards should be and create a standards document. I think it is fairly hard to argue with the need for a consistent style for the sake of readability and maintanence, and when there are rules in place saying "do it this way", it is much harder to diverge from it than if it is merely established practice.

Answer 2

1) Developer is at a junior level - Mentor; be kind & gentle. Explain the need for standards in general and then explain the need for the particular standard which is not being followed. Do this with an open mind; if you cannot justify the standard then perhaps it ought not to be a standard?

2) Developer is at a peer level - this ought to be easy enough – if you can keep it technical and not let is dissolve into a clash of personalities. Again, if you can justify it, it probably ought to be a standard, but if he has an equally compelling argument against, then maybe not. However, do not accept that there ought to be no standard. Ask him for a suggested standard to replace the one which he does not like. If he will not comply, then escalate. If you don’t like it, then put it to the vote/ escalate. Try to avoid escalation, but try to ensure that there is a standard.

3) Developer is at a senior level Try to reason. Listen carefully, he may be right. If in doubt, then put it to the vote/ escalate.

Caveat: standards are nice (imo, absolutely required, but ymmv), but they are difficult to “enforce” unless reached by consensus.

Exception: “cowboy coders” need to be slapped down hard; no expectations.

Do not feel bad about “tattling” to the boss. When it comes to a cowboy coder then follow the cowboy motto “this team ain’t big enough for both of us”; either he stops cowboying or one of you has to get the hell out of Dodge.

Answer 3

Pair programming may be my best suggestion as this can help ensure everyone gets up to the same level and help foster a sense of community within the team. This does shift responsibility to some extent but the idea is to have someone try to get the other person to do things the way others do it. How to Win Friends and Influence People has the following points that may apply though these are general:

Fundamental Techniques in Handling People

1. Don't criticize, condemn, or complain.
2. Give honest and sincere appreciation.
3. Arouse in the other person an eager want.

Six Ways to Make People Like You

1. Become genuinely interested in other people.
2. Smile.
3. Remember that a man's Name is to him the sweetest and most important sound in any language.
4. Be a good listener. Encourage others to talk about themselves.
5. Talk in the terms of the other man's interest.
6. Make the other person feel important and do it sincerely.

Twelve Ways to Win People to Your Way of Thinking

1. Avoid arguments.
2. Show respect for the other person's opinions. Never tell someone they are wrong.
3. If you're wrong, admit it quickly and emphatically.
4. Begin in a friendly way.
5. Start with questions the other person will answer yes to.
6. Let the other person do the talking.
7. Let the other person feel the idea is his/hers.
8. Try honestly to see things from the other person's point of view.
9. Sympathize with the other person.
10. Appeal to noble motives.
11. Dramatize your ideas.
12. Throw down a challenge & don't talk negative when the person is absent, talk about only positive.

Be a Leader: How to Change People Without Giving Offense or Arousing Resentment

1. Begin with praise and honest appreciation.
2. Call attention to other people's mistakes indirectly.
3. Talk about your own mistakes first.
4. Ask questions instead of directly giving orders.
5. Let the other person save face.
6. Praise every improvement.
7. Give them a fine reputation to live up to.
8. Encourage them by making their faults seem easy to correct.
9. Make the other person happy about doing what you suggest.

Answer 4

We use TFS and Code Check-in policies as a way to enforce code standards. The other responses I agree with completely for the people part of it. For some coding standards like variable naming standards, you can spend a tiny bit of time (maybe the dev in question can write these) and write these. If you incorporate them into your build process, then part of the validation of a build involves checking the source for correct code standards. We use MSBuild with Visual Studio 2008 and it works great. That will help somewhat when a system has been developed to enforce standards as it's harder to argue with a build system sometimes. Also, it helps to have the builds treat those violations as errors in visual studio rather than just warnings for further enforcement. Above all, the "why" part of the standards are most important for a developer of any rank to udnerstand. If they understand why standards are useful and understand the right forum/opporunity (monthly dev meeting?) where they can voice reasoning against a particular standard, hopefully they can begin to follow them alongside the successful team.