Working alone makes it harder to get early and continual design feedback, thereby decreasing output quality. A tight feedback cycle is critical to achieving a productive state of flow 2, and the earlier that you can get feedback, the less likely that you’ll waste time going down the wrong path and earlier you’ll know to correct your course. In practice, one place where this shows up in software development is that it’s significantly easier for someone to review your code and to give good feedback if they actually work on the same team as you and share the same project context as you; it’s much harder to for someone on a different project to give you code. Brian Fitzpatrick and Ben Collins-Sussman capture this notion well in one of their taglines in Team Geek: “software development is a team sport.” 3Working alone reduces learning. One part of this is related to the first point, where there are fewer people with a shared context to challenge your ideas.

Another is that because the project takes much longer to complete, each individual working along works on fewer projects over time.Working on a team increases the bus factor for a project. The bus factor 4 of a project refers to the number of team members that can be hit by a bus (or gets sick, leaves the company, goes on maternity leave, etc.) before a project comes to a complete halt; a higher bus factor reduces risk on a project. It also helps prevent obscure and undocumented shortcuts taken by a single individual and forces team members to spread knowledge and to do things in a way that other people on the team can pick up if necessary.