by Jacob Schweitzer
Software development is often seen as a solitary endeavour — a lone hacker typing furiously at their keyboard until they have that eureka moment. However, this is often far from the truth; software development is a team sport. Even when you are working in relative isolation, there are others helping you online with articles, videos, code snippets, and the very code you are 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.
Two heads are better than one
Many of us have heard this expression, and it certainly is true for software development. Nobody knows everything — it would be impossible due to the breadth and depth of programming languages today. But, even if a situation is new to you, someone you team up with may have already encountered this exact problem or something similar. Finding a solution will be a lot faster with their advice. It also could help you avoid going down a path which could lead to a dead end or an inferior solution. Sometimes, working through the problem together, you figure out the potential solution is larger than the initial scope that was agreed upon by the client, so it needs to be discussed by the team at large and/or brought back to the client for reevaluation.
Team building
Finding a solution together gives you the opportunity to learn about your teammates’ skills, build trust, and learn how to better work with one another. Some of my team members like to make jokes, and some of them like to get right to work — everyone has their own style which you can learn about by working one on one with them. For example, maybe you learn about a skill that a teammate has that will come in handy when you need help in the future. Whenever you work together, you build up more trust, which allows you to ask hard questions of one another. For example, why did they take a certain approach to a problem when you believe another approach might be better? Accepting and giving constructive criticisms is also a lot easier when you have built up a certain level of trust. Finally, cross-team coordination is also a useful outcome of these situations — for example, a backend developer working with a designer to ensure the work they are doing is in line with the expectations they have for when the work is handed off to the other team.
Rubber ducky
Very often when working on a difficult problem, we look to others for help. While explaining to them what is going on, we figure it out ourselves. This is called “Rubber duck debugging,” a phrase coined in the famous book The Pragmatic Programmer. It originates from a programmer who used to carry a rubber duck around with him and attempted to explain the issue to the duck one line of code at a time. This forces you to step through the code and explain it in a way someone unfamiliar with the issue can understand it.
Coding standards formation
Sometimes we run into a problem with multiple solutions, or we are unsure that the approach we are taking is consistent with the current codebase. When this happens, it is good to work with another person to ensure they also feel the proposed solution is going to make sense to someone unfamiliar with the code looking at it at some point in the future. Then, a pattern can be agreed upon which can be used in other parts of the codebase going forward. As a result, someone new to the project will find it easier to get onboarded to the codebase.
So, that’s the why — what about the how? This depends on your situation, but some things to consider are below:
When does pair coding not make sense?
Smaller or limited budget projects might not have the capacity to do much pair programming. Also, problems requiring unique or rare knowledge that only one team member has would require that one person to work on the problem. But, pair coding could help another person gain some of that knowledge in the process, even if they weren’t directly contributing. In other situations, the solution to the problem might be a Google search away, and so bothering team members isn’t always the most productive way to go about things.
How does one get started with pair coding?
You could be intentional about it — for example, each week choosing a ticket to pair on with your team. Or, it could be more ad-hoc -just pairing when it makes sense for a larger ticket or a challenging problem that you need an extra pair of eyes on. Sometimes, it is as simple as posting something in a shared communication channel such as “Hey everyone, I’m working on XYZ, has anyone worked on this before? I just have a few questions before I get started.” or asking a specific person “Hey Jill, I know you worked on this part of our codebase before, could you help me get started on XYZ?”
How do we get sign off from stakeholders for doing pair coding?
This can be tricky, but it doesn’t have to be. Some clients don’t need or want to know how you get your work done, just that it is done well in a timely fashion. In these cases you don’t need a formal sign off. However, pairing on a larger task which will show a lot of hours billed to it later might require you to at least give the client a notice that this needs to happen. In your regular meeting with the stakeholders it could be brought up as something you want them to be aware of: “Just to let you know, in order to build feature XYZ we’ll need a few people working together to get us to the best solution faster. It is a complex feature and how we build it will affect our work on ABC.”
Pair coding has helped me out of many situations where I was stuck and frustrated. I’ve also helped people get unstuck and seen how relieved they were when we were able to get to a point of making progress again. Sometimes we don’t find a solution, but most of the time pair coding is an effective way of collaborating, and has a lot of additional benefits which help the team function more efficiently. Each time you pair code with someone it seems to build goodwill which is passed around the team as a whole as you work with each other. Knowing you can count on your team gives you more confidence even when working solo, since you know help is just a message away.
Ready to give it a shot? If you do, let us know how it goes on Twitter — we’re always happy to lend a hand.
Originally published at https://alley.co on July 6, 2020.
