Many, many pages have been published on programmer psychology. Here is my own boiled down summary of what I think are the salient points:

1. Getting people to agree on what "good software" is goes a long way towards being able to cohesively work together.

In my view:

2. Programmer Psychology in a Nutshell:

A certain form of survival dominates a lot of programmer psychology.

Comfort zone and workflow are everything.

3. Team playing and leadership are all about getting past the cognitive dissonance of other's (often less than perfect) programming styles and design approaches - in order to get the job done in a finite timeframe.

"'s such a large project... There will be so many people involved, each with authority, each wanting to exercise it in one way or another".

People generalize based on predisposition, education and experience, and it's only natural to want things YOUR way so YOU can more easily understand them (Everyone does this. I admit I do). And when we're looking for help we'd all like to find a clone of ourselves. But in my time as an IBM Team Leader, under schedule and budget pressure, I learned to back off and only insist on two things from my team's coding: (i) that the code work, and (ii) that someone (anyone!) else can follow (but not necessarily agree with) its internals and act as a support backup.

4. The more your computer training, the more abstractly you approach problems