Software development is often seen as a solitary endeavor – a lone hacker typing furiously at their keyboard until they have that eureka moment. But that’s often far from the truth — software development is a team sport. Even when you’re working in relative isolation, others are online helping with articles, videos, code snippets — and the very code you’re building upon. In this article, we’ll go through some of the reasons why you should increase your productivity with pair coding (working towards a solution with one other person) and swarming (working towards a solution with multiple people).
Why you should embrace teaming up:
Two heads are better than one
Many of us have heard the expression, and it’s certainly true for software development. Nobody knows everything – it would be impossible due to the breadth and depth of programming languages today. Teaming up increases the chances that one of you recognizes an issue or has encountered a similar problem — it also means you’re less likely to pursue a dead end or an inferior solution. Sometimes, working through the problem together, you realize the potential solution has outgrown the initial scope your client agreed to and needs to be reevaluated.
Team building
Building trust with teammates, learning each other’s strengths and weaknesses, and understanding your team’s particular dynamics is like exercising a muscle — you’ll get so much stronger and better at using it. Some of my team members like banter, others prefer to get right to the point – everyone has their own style, and understanding each other’s differences makes us more productive and collaborative.
Team rapport also makes it easier to challenge each other and share constructive criticism (making us all stronger and smarter individually and as a team). These dynamics also facilitate cross-functional collaboration – for example, a backend developer working with a designer to better understand objectives and expectations in preparation for work that will need to be handed off.
Rubber ducky
Have you ever started to ask for help after poring over an issue only to have an epiphany as you’re explaining the problem out loud for the first time? It’s called “Rubber duck debugging,” a phrase coined in The Pragmatic Programmer. It originates from a programmer who used to carry a rubber duck around with him so that he could attempt to explain issues to the duck one line of code at a time. This process forces you to step through the code, provide context, and articulate the issue at hand.
Coding standards formation
Sometimes we run into a problem with multiple solutions, or we’re not confident that our approach is consistent with the existing codebase. Working with a team is a great way to ratify your proposed solution and ensure your code is highly readable and transferable to a future developer.
(It doesn’t always make sense)
Smaller projects with limited budgets don’t always have the capacity for pair programming. Meanwhile, problems that require unique or rare knowledge don’t necessarily stand to benefit much from the process (although pair coding could help another person gain some of that knowledge). And in some situations, a solution might just be a Google search away, making it unproductive to pull in additional team members.
How to get started with pair coding?
Communication is key
You can implement pair coding and swarming through an intentional process (i.e. selecting a ticket each week for swarming) or take a more ad-hoc approach (teaming up on larger or particularly complex tickets). In either case, open lines of communication are the best way to effect this change. Make sure your team knows what the norms and expectations are. This might look like team members sending a simple message to your team, or it could be a formal process around scheduling swarms or pairing up team members. Whatever route you take, make sure everyone is on the same page and feels encouraged to seek support and collaboration.
Involving Your Stakeholders
Getting sign-off from stakeholders on pair coding initiatives can feel tricky, but it doesn’t have to be. Not all clients want to be involved in process-specific decisions — as long as their product is delivered on target and on time. However, larger projects where billable hours come into play might warrant a conversation. Be sure to manage expectations and maintain open communication with your client. Of course, explaining the “why” behind swarming can go a long way toward your client understanding how this process can help you deliver a better solution faster.
A team effort
Pair coding has helped me out of many situations where I felt stuck and frustrated. And on the flip side, I’ve appreciated the opportunity to help others reach a solution and get “unstuck.” Embracing the opportunity to collaborate, learn, and grow is a great habit for any team in any field, but in the ever-shifting landscape of technology, it’s invaluable. I like to think of each opportunity to pair code as goodwill that gets passed around the team, incentivizing us to work together and help one another. We all get to approach challenges with more confidence when we know help is just a message away.
Ready to give it a shot? Let us know how it goes on Twitter – we’re always happy to lend a hand.