Recently there was a post at the 37signals blog Signal vs. Noise about the question why programs become territorial. The reason is simple: Programs become territorial because programmers naturally consider their code as their territory. Your code is your work and your creation based on your ideas, right? Therefore as a programmer it is natural to think that your code belongs to you. It is the world you have created. And in his own world the programmer is a little god who knows everything, while everyone else is a mere mortal without superpowers. The own world contains only cities and places the programmer has built himself – so the programmer is the creator, architect, ruler, general, and governor all in one. A programmer which tries to understand the code from someone else has not only lost his superpowers, he is completely lost. It is a bit like being a tourist in a foreign city – you will feel lost in the beginning. Maps in form of database diagrams and UML models help to a certain degree, but even with a map it remains difficult to understand a foreign territory.
Software engineers tend to own their creations. It goes well in two cases: if everybody knows and owns his own part, i.e. if everybody has his own territory, or – if if the territory belongs to the team. This means everybody knows and can change everything, everything is well documented and the team agrees on certain coding standards, policies and guidelines. Unfortunately, working in a team is not easy, because it is difficult to create useful documentation, and programmers do not like giving up their freedom. They like their superpowers. Developers want autonomy, mastery and purpose. Working in a team is difficult, because it means to have a team ego instead of an individual ego. Agreeing on standards does not mean that everyone in the team has to accept tools, libraries and plugins you prefer, rather it means to accept things others prefer more than you, and to abandon personal habits and likes. This is not easy, because programmers are often very opinionated. So the two extremes that work are:
- The individual rules: team has no strong ego, territory belongs to the individual
- The team rules: individuals give up their ego, territory belongs to the team
Between those extremes it gets complicated. Code changes can lead easily to personal conflicts if code is owned by people. Therefore developers tend to avoid changing the code from others. Programming well with others is difficult. It certainly requires good communication. Most programmers know how to communicate, but they don’t want to. They want to do it themselves, and they see others as competitors. It takes indeed a bit the fun out of programming if you have to justify and explain every decision to others. To find the right balance between cooperation and competition in a team is not easy. In general, the golden rule helps: One should treat others as one would like others to treat oneself. Do not ignore them, ask others for their opinion, show them your respect, include them in important decisions, explain your architecture, show them your achievements etc. Communication is the glue that keeps groups together. This is the reason why most programmers have difficulties when it comes to programming well with others. They lack social skills, and the only languages they really like are programming languages. They are used to work with machines and not with people.
Ben Collins-Sussman and Brian Fitzpatrick give us some hints how to program well with others. Documentation is important: document your design decisions, your architecture, your goals, your failures, for example on an easy editable Wiki. The ability to communicate is also an important aspect. They argue in this video (and their forthcoming book with the same title) that collaborating and communicating with others is at least as important as having great technical skills. According to Ben and Fitz, the right attitude is important in a team. You should be thinking about “how do I work with a team” and not “how do I present myself as a genius”
4 Lines of Code 