Sure, I've written a book "Social Architecture" on this, and many articles. You can read the book freely at https://www.gitbook.com/book/hintjens/social-architecture/de.... It's also in print and Kindle from Amazon.

The psychology of collaboration is (in my model, which is of course wrong, just accurate enough to be more useful than ignorance) based on emotions that we've evolved to work together. Most of what I tested and documented over the last decade came from study of failure (most projects fail and you can learn a lot by looking into why), and experience of how to make communities that could survive the kinds of conflict we see. Actually getting a full model for the emotions took a lot longer, finished that a year or so ago.

You can see the results in e.g. the C4 process, our RFC for working together in the ZeroMQ community: http://rfc.zeromq.org/spec:42/C4/

My articles are on http://hintjens.com, starting in 2010 or so.

Thanks writing and sharing those. Very good insights there. Also sorry, didn't recognize your name at first as Pieter Hintjens (I wouldn't have asked as already had the link to the book in my bookmarks). I periodically refer to "The Toolbox" when discussing development practices at work.

In professions which are considered more rational and intellectual like programming, there is a danger of discounting the effect of emotions. Emotions are always there under the surface guiding and controlling things.

The more rational the person thinks they are the more they will rationalize their decisions. So when someone proposes using say Protobufs as a serialization mechanism, instead of Thrift, for example, might be doing it because the person who likes Thrift in the group offended them somehow. But that will never come up in the official reason, there will be some benchmark or list of point why Protobufs might be better.

Or maybe they had a fight with their family and they come to work and start shutting down a project and shuffling developers around to feel empowered, and there will always be a seemingly rational reason for it.

Thanks againg for writing that book and sharing your experience. There is just not enough of that, especially focused on open source projects. Some projects naturally converge and discover some of those principles from the toolbox, but having them written down from someone with experience is priceless.

Yes, we tend to discount emotions, our own and others'. It is amazing in retrospect given how important these are in driving us. What I learned with groups was to explicitly ask people, "how do you feel?" and then to insist until I get answers that match what people are showing, rather than saying or claiming.

Especially, "how do you feel about what person X is doing?"

It's not a gender thing or even a nerd thing, really. It's the same with musicians, for instance (I used to jam a lot), they can be really reticent about saying what they actually feel about other people.

Basically our fear of being rejected by the group, and shame at having feelings that no-one else is expressing make us unable to speak up. Since few people can debug their own emotional stacks, the fear and shame dominate, and stop the (e.g.) anger at an asshat messing up the project from coming forwards.

So actually asking people the specific question can change a lot. Mostly, I'll start with "are you enjoying this (the way things are going)?" knowing they'll admit "no" and then we can work it out from there.

This is a good observation. I've seen this happen in work situations multiple times, and I've felt those feelings as well. Which is why one of my life goals is to learn the skill of objective judgement without being influenced by emotions unrelated to the technical merits of a decision.

I believe the correct name for that personality attribute might be 'mature'.