This is just some assorted stuff that's been on my brain the last couple of weeks, which probably everyone knows already, but I feel like saying anyways. And, hey, it's content, right?
1. Use continuous integration
Every single person on your team should be doing continuous integration. Added a few lines of code? Make sure they compile and function correctly, check them in to source control, and continue. Tweaked a few textures on that model to make it look a bit better? Check it into the asset repository so everyone sees the updates live.
This has a few benefits. First, it's a great motivator - everyone sees constant forward progress, which is good for team morale, and great for making your managers and other stakeholders happy. Second, it forces you to have an infrastructure in place that can handle it. No source control? No asset management system? You can't do CI. And if you aren't doing CI, I promise you that your project's development is a lot more painful than it has to be.
As another perk, it keeps your programmers from taking huge chunks of code and breaking them, and leaving them in a broken state for days - or, worse, weeks. Most development shops have a policy against breaking the build - if your code causes the automatic daily build to fail, you're in trouble. This should go beyond just compiler errors or invalid data; if you break a feature or cause the overall level of "finishedness" of the project to regress, it's a bad sign. People should get in trouble for making things go backwards instead of forwards.
2. Tell everyone what's going on
A mistake I've seen a lot lately (and, consequently, am very sick of) is limiting the scope of knowledge. Games are big projects, and obviously no one person is going to know every detail about everything. However, it's far too easy to overly restrict the flow of information.
For example, suppose Bob and Fred are working on the sound system, and they decide they need to change the way sound files are loaded. They tweak a few things, which, incidentally, requires a change to the assets. They fix the three or four assets that they're using, but forget that Joe has a couple of his own that he's using to test the link between the physics engine and the sound system.
Joe shows up to work the next morning and suddenly the physics isn't making sounds anymore. He fishes around a while to find out what broke, and finally notices that it's because his sounds aren't loading correctly. Depending on the quality of your codebase, this might mean it took Joe 30 seconds, or maybe he wasted all day - either way, he's lost valuable time for no good reason.
Bob and Fred should, at the very least, send out a team-wide email that says, "hey, we changed the way sound files load, make sure you do blah blah foo to them so they still work." This spares everyone a lot of trouble. Suppose Joe hadn't tried his physics stuff the next day, but in fact came back to it six weeks later? Now the odds that Bob and Fred even remember the change have dropped severely, and it'll take even more time to solve the issue.
Keep everyone up to date when significant things like file formats, code interfaces, and so on are changed. Yes, you should try and get these things nailed down as early on in the dev cycle as possible; but changes are more or less inevitable, and they must be handled cleanly.
3. Before solving a problem, always ask if someone else has solved it yet
As code bases get large, it becomes increasingly hard for people to track what code has been written and what hasn't. This means that, as code base size and number of programmers increase, the chances of duplicate code appearing increase as well. Right now, our project is plagued by this nonsense.
What's worse is that usually someone has done a really good job solving the problem because it's in the part of the code they are most familiar with - and then someone else comes along who is less familiar and reinvents the wheel, except their new wheel sucks for whatever reason. When you get to the point of having three or four wheels in the same codebase, you have a serious problem.
The first and best defense against this is to have more or less clearly defined "areas of expertise" for each programmer. That is, everyone should know that Bob and Fred are the audio guys, Joe knows the physics engine, and George is in charge of graphics. So when Ed the AI guy wants to have his little bots play scream effects when they die, he should go talk to Bob and/or Fred and see if they have a good way to accomplish what he wants.
There is an important corollary to this: If you have a programmer who is just reimplementing things whenever he needs them without consulting the knowledge of anyone else on the team - or, worse, changing code without understanding the designer's intent - he needs to be slapped around.
Of course, past a point, you're going to get some accidental duplication anyways. And there's always the cases where you only realize in hindsight that two things can be collapsed into a single solution. For those cases, your team should have at least one programmer - preferably one who is known to have good design skills - who is more or less dedicated to factoring out such duplication and cleaning up the code overall.
Some teams are tempted to just do this kind of refactoring "between projects", and only worry about code that carries over across products. This is not really wise. Never underestimate the value of cleaning up code while you are still working on it. You may spend a week getting things tidied up, but that may well save you a month's worth of ugly debugging.
4. Keep a cool head
There will be someone on your team who is markedly less skilled and/or sensible than yourself. (Of course, the standard poker-sucker rule applies here: if you don't know who the dumb guy is, it's you.) You will have to deal with this person, possibly in a close capacity.
Whatever you do, suppress your urges to stab him through the eyes with a rusted spork and spit on his corpse repeatedly. I know it's tempting - believe me, I know - but it's not really all that useful.
If you have enough patience, try and help train up his skills and get him to improve. This way, you gain (eventually) a more valuable team member. If you don't have that much patience, just stuff a sock in it and find a good stress-reliever for after hours.
So how do I know this stuff?
Why should you listen to me? How can you trust that this advice is good, and will guide you away from the thorn-choked path of failure and doom?
Because I can tell you, from experience, that not doing each of these four things leads directly to lots of pain.
Ditto!!
Also, to expand upon #4, there will be others on your team with more experience than you, and you have to be very, very careful about accidentally talking up to them. I was once on a team project when I was like 19 that had me programming alongside a 40-something software engineer who wanted to make games. I was designing the game framework and he was utilizing it. He sent me an email asking me why one function was broken and another was returning bad data. I looked at his code and realized he was using both functions improperly. I then proceeded to inform him of this and told him to go read the documentation explaining the function's proper use. He decided to take my tone as some kid who thought he knew better than him and got on the phone with me to say he got paid to put up with people like me at his job and that he was off the project.
5. Speaking of tone...
That's another thing. Email sucks as a communications tool unless you and the rest of the team have been friends in real life for years, as tone in emails can be horribly mis-interpreted by people who don't know one another well. If you're strangers working on your first project together, use Skype or something so that you can talk and make good use of voice inflections. If you can't picture in your mind the other person saying what's in an email as if he were talking to you face to face, then you shouldn't be using email at all.