Programming in teams

I have a lot of experience hunting bugs that make no sense, sometimes in my own code and sometimes in other people's. I usually find it harder to find those bugs in my own code, and it certainly isn't because my code is particularly “clever”.

The common pattern that I find in “bugs that make no sense” is that I am believing something that isn't true. Once I identify and challenge that belief, the bug becomes obvious. The reason that these bugs are harder to find in my own code is because I believe my code is correct (in general, and in lots of specifics), so I don't question it so closely. When I'm reading other people's code I have less belief that it is correct, so less hindrance to finding the bugs.

Put another way: finding a bug in my code is both a success and an admission of failure. Finding a bug in someone else's code is pure success. This sounds like a strong case for pair-programming!
—Neil Brown

• Common sense
• Science supports common sense
  Woolley, Chabris, Pentland, Hashmi, Malone
  Evidence for a Collective Intelligence Factor in the Performance of Human Groups, Science, DOI: 10.1126/science.1193147
  Psychologists have repeatedly shown that a factor called “collective intelligence” emerges from the correlations among groups of people's performance on a wide variety of cognitive tasks. In two studies with 699 individuals, working in groups of two to five, we find converging evidence of a general collective intelligence factor that explains a group's performance on a wide variety of tasks. This “c factor” is not strongly correlated with the average or maximum individual intelligence of group members but is correlated with the average social sensitivity of group members, the equality in distribution of conversational turn-taking, and the proportion of females in the group.
• Our personal experience at the school
• That is how human civilization works!

• Communicating
• Planning
• Distributing
• The psychological factor: the humble type, the assertive type

• meetings (presentations/progress reports), online (mailing-lists, IRC, Wiki), commit messages!
• listen, consider every idea, think before you speak
• give and accept feedback, only constructive criticism, self-criticism, ask and offer for help (no need to be ashamed)
• don't bypass team-mates, no blaming – look for a solution instead
• thanks and tributes
• learn from your experience

• deadlines, milestones
• identify work packages
• identify skills and preferences in the team
• check progress
• identify bottlenecks
• flexible use of resources

• do you need a leader?
• a tyrant? a benevolent dictator? a release manager? a spokesperson?
• plutocracy (rule by the wealthy), aristocracy (rule by the best), democracy (rule by majority), do-ocracy (Debian ), anarchy (flat society – no authority/hierarchy)?