"PEOPLEWARE"

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:

Design and Code should strive for ease of understanding. This is much more important than performance, reuse, generality, terse coding,...

The ultimate test of "good software" is whether it lives on (to be used, useful and enhanced) well past its originators.

Simplifiers vs. Optimizers

Scott Adams (author of "Dilbert") has an excellent discussion of "simplifiers" vs. "optimizers" in his book "How to Fail at Almost Everything and Still Win Big" .
This dimension of personality features VERY prominently in software. Here are some illustrative quotes from the book:

An optimizer looks for the very best solution - even if the extra complexity increases the odds of unexpected problems.
People can follow simple systems better than complicated ones. If the cost of failure is high, simple tasks are the best.
My wife, Shelly, is a world class optimizer. I, on the other hand, cling to simplicity like a monkey on a coconut.

2. Programmer Psychology in a Nutshell:

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

Comfort zone and workflow are everything.

For lots of very good reasons (like working quickly and efficiently, having a "workflow", knowledge is power, etc.), people like working deep in their comfort zone and heavily resist being forced out of it (which software is famous for). If you don't buy this - try getting out of your comfort zone and learning something like a foreign language someday. Then go overseas and have some genius of a little kid treat you as if you were an idiot.

Whether you're introducing a new system to users comfortable with an old one, or dealing with programmers - it's good to appreciate that that's often the scenario which accompanies change.
This is how companies like Adobe and Autodesk (Maya, 3DS Max) keep their revenue streams flowing. Once market share has been captured and users have learned to be productive with their software, it's extremely hard for them to then switch to equivalent, less expensive products.

Programmers tend to be contrary (e.g. Why are you even doing it that way?), but underneath it - they are often just pushing for their own workflows.

Debates are unavoidable among team members, and are an inherent part of software development. To resolve them, authority should accompany responsibility as much as possible, since:
THE major cause of low programmer morale is when the person responsible for making it work does not buy into how it is to be done.

For my part - I state my best case then go with whatever the team seems to be coalescing around.

Over the years, I have known a number of people who never worked on more than one major application. When the application went away, when the languages and operating systems changed - they did not stay in software development. And it wasn't like they were not smart enough. The (very real and humbling) stresses of starting over were too much.

Whether it's introducing a new system to end users or handing off code to another programmer - there's a lot of beneficial spillover when you yourself have also recently tried to learn something new.

German, Spanish, 3D modeling (Modo, Carrara, Poser, DAZ Studio), and Chess are my own personal challenges. And frankly - I'm pretty mediocre at all of them. I envy people who are good at them. By comparison, they make me wish I were a whole lot smarter. But show me a programmer who is difficult to work with - and I'll show you someone who hasn't struggled with much outside of their comfort zone lately. These are people who have trouble following anything that they themselves did not structure.

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.

"...it'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".

Ayn Rand, "The Fountainhead"

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.

In my experience - micro managing how coders code is a project death knell. Software (like language prose) is an art form. There's always a better way to do it; and even if there isn't - someone else will still think that there is.

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

An engineer writes a program to solve a problem.

Con: Their code tends to be a collection of point solutions. They don't generalize when they should.

A programmer invents a language, class library, or pre compiler tools to solve a problem.

They sometimes get more hung up in how code is constructed - than in the end user functionality they are delivering.

A computer scientist writes a specification for a language to solve a problem.

If they're witty they write books and lecture, or become software methodologists.

A PhD writes a grammar for a specification for a language to solve a problem.

Abstraction being what it is, a PhD Computer Scientist can be compared to a theologian who knows some math.