Best practices in a game team environment

There are many ways to build a sense of friendship and intellectual honesty when working in a team environment and some of those come down to basics like honesty, accountability, taking responsibility, and helping others where possible. The following is a natural way to build trust and honesty in a team environment. There are other suggestions.. but these are the most important in my opinion.

• Always assume that a reported bug is yours unless it is clear that the bug is not in your domain or you've identified that the bug belongs to someone else. This means that someone is taking responsibility, you. It also means that you learn a little about a system that you don't know much about. Lastly, don't spend too much time on it, especially once you learn that it is someone else's bug. Find the problem, identify who owns it, and move on... you have plenty of other things to do. Unless the person isn't around: then you should own it unless you feel out of your league and then involve others.
• Buddy builds. When you have a big change, and you are unsure whether or not it runs, tell a buddy that you'd like him to check it. If he's in a position to try it out, then make sure he's ready, and check in and have him sync up your changes immediately and build. If there is a problem, you can revert before the build breaks or anyone else notices. Even better is if you have an offline way to give him your changes like a P4zip file or using a branch can help too. This practice is time consuming for both you and the buddy, so use it sparingly.
• Peer programming. XP does not mean that you're a bad programmer; it means that you're a good programmer because you recognize that you reduce your error rate by as much as three times and reduce waste and rewrites by about one half but XP will slow you down by 15% (this is historically accurate, even though it seems twice as slow). This practice is not widely used in the game industry, but where it is used, the code is nearly always more stable.
• Unit tests add tremendous stability to any code base. You can't always do system tests, but unit tests are vital to a long development cycle where code changes frequently and systems are constantly rewritten like in games. Write the test first, then write the code to match. This is called TTD (test driven development) and has been shown to be highly effective, especially long term if you can integrate unit tests into your build process.
• Never point fingers. Even when Joe breaks the build, forgets to run the application before submitting, or makes the mistake of going home after checking in, council him when he arrives. Find out why Joe did what he did. Why didn't he run the game before checking in... lots of pressure to submit and the network was down? Why did he break the build... bad PerForce integration didn't pick up the new files that he added to the projects? Almost nobody wants to do a bad job and finding the root cause of problems means that something can often be done without demoralizing your coworker. This is called root-cause analysis. Then, maybe you can talk to him about how hard he made your job by what he did and then talk to him about ways to improve. Basically, stay positive and focus on ways to make Joe's job easier to avoid mistakes, not on making Joe look bad.
• Stop making excuses and change the system that is causing you problems or change your behavior. I hate whiny people as much as the next guy. We all want to hear "I'll see if there is a way for me to not do a bad checkin next time" or "I didn't realize that I need to run that tool before submitting. I'll add it to my process." With that said, always help others with their process errors if they are willing to listen and you don't beat them over the head with it. Mentoring or helping that person will make your life easier.

Lastly a note about an anti-pattern I have seen too many times to not mention:

Poison people blame the system, the build, or other people for making mistakes. Worse are people who deflect blame by quickly pointing out what other people do wrong, often inflating reports of the damage that others do by their an innocuous checkins that causes a minor problems, or by exaggerating facts, or even lying. This is destructive to others, the company, overall morale, and finally to themselves. It is often best to avoid poison people if you can identify them during the interview process, but if you have some working for you now, insulate yourself and surround yourself with positive people. Eventually those people move on or realize that their finger-pointing is ineffective and stop.

Make sure that when he says negative things about others, that you offer to go fetch the person about whom he's complaining so that the victim can "explain the situation" which always shuts up the complainer. Mostly, stay positive in the face of adversity.