I am not a developer myself, but for the past ten years I am working in development teams doing one thing or another. Over time, I have seen that one of the factors that makes a team effective is that we need to bring everyone along (if you are interested, you can find the other four in this older blog post). Nevertheless, each team finds its own way of collaborating in a way that makes sense for them. Here are the ones that I have encountered the most
BY THE BOOK Pair/Ensemble programming
There are developers that like working together following a structured approach when collaborating.
Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.Wikipedia
This can be extended to more people, an ensemble, who observe certain rules to make their work go more smoothly. This downloadable cheat-sheet gives a quick overview of how ensemble programming works. Usually, pair/ensemble sessions are planned but of course they might happen if the need arises.
Freestyle Pair/Ensemble programming
Sometimes, two or more developers decide to pick up a certain topic and work on it together to bring it to the end. They don’t necessarily follow any rules of how to get the task done, they just see it through. This might involve both of them working on the entire solution at the same time or each of them focusing on smaller tasks that they later integrate. No matter the way they work, a single person is not done with their part, until the entire task is finished.
Tapping the team
Another pattern I have noticed, is someone starting a task on their own and then pulling-in colleagues to finish the work. The trigger for the pull-in varies. Sometimes, it is an obstacle in finding the solution, so more brain power is required to generate different ideas. Others, it is a decision point of how the implementation should look like. What if one approach is easier but creates more technical debt in the future? Instead of making the decision on their own, they evoke the collective understanding and knowledge of the team to agree on a path going forward.
Using a pull request mechanism, this works well when people are not collaborating in real time, but still find value getting another view on their work. The reasons for not collaborating in real time can vary, from working in different time zones, to simply not being comfortable coding together with someone else. In my experience this type of collaboration is more meaningful, when pull requests are not used as an approval/quality gate mechanism but as a tool for learning what is being worked on, how it is implemented and challenge it if necessary.
So far, I have not found any clear boundaries between these practices. Someone can start something on their own, tap the team for help, run an ensemble session and then involve a single colleague to finalise the work with a pull request. Nor do I believe there is a “best practice” that needs to be followed every time. Teams are made by people who have their own needs and preferences about the way they work. As long as there is a common understanding that sharing the knowledge and the expertise is a good thing that helps both the team and the quality of our product, people find a way to collaborate that works best for them. We just need to trust them and allow them the time to find that way.