pair programming Archives - Developer Nation Blog

Programming and development is a minefield of complexity, creativity, and technology. When a business problem needs solving, it often falls to these hardened defenders of the code to find a solution and save the day. Without the expertise of trusted developers, our entire digital ecosystem would fall into disrepair — it may have never even been made.

Still, for the incredible importance of these individuals in business structure, all too often the work itself can be pushed to the side, leading to isolated individuals tackling huge problems that require more resources than they’re given. While there have been a host of strategies to alleviate this, pair programming is emerging as a panacea to the many issues that have plagued programming teams for decades.

What is pair programming?

Pair programming is the approach of creating duos of programmers to tackle a specific project or task. They will work collaboratively to develop the code and tackle any problems faced and will work simultaneously towards the end goal. It is a simple concept in truth and can be modified to suit your development team too, making it a flexible approach to development that has grown in popularity over time.

Pair programming can be employed in development teams of all sizes, from start-ups with fewer than ten employees to huge businesses that routinely have enterprise meeting sessions of dozens of team members.

With that said, the concept does invite a host of questions such as how is the work achieved without stepping on each other’s toes, what is the best approach to establishing a pair programming strategy, and is it even beneficial to apply two individuals to work on one problem? We’ll answer these below and explain the key bits of info you need to know.

5 things to know about pair programming

As adaptable as the concept is, there are a series of established ideas that most pair programming arrangements will adhere to.

There are 3 maExpert – Expertin styles to consider

The vast majority of pair programming setups will fall into one of three main methods — ping pong style, unstructured style, and the driver-navigator approach. Each of these methods has advantages and disadvantages, so it’s worth exploring each to determine what works best for both the individuals and your business.

Ping-pong style

Ping-pong programming focuses on having developers push each other forward with a series of rotating test-based development. Once the problem has been identified and the requirements to resolve it established, one developer will create a test to benchmark successful code commits against. The other developer will program in accordance with those tests and seek to pass them. As the codebase matures and the tests are passed, they can swap roles and work towards a new goal.

This is a great approach to ensure both developers are engaged and are working productively, though the time taken to complete tasks may be longer than other approaches.

Unstructured style

An unstructured style is pretty much what you’d expect — no-holds-barred collaborative development. Programmers are given the autonomy to determine how to best tackle the project and can create code in tandem or in silo of one another, however suits them best.

While this can be a superb way of tackling complicated issues that require two sets of eyes, it can also lead to mismatched inputs and a loss of engagement if one developer outshines the other.

Driver-navigator approach

In this style, developers take two distinct roles. The driver creates all code and contributes the direct work, while the navigator will critique, examine, and help propel the driver forward in their efforts.

For example, the navigator might research information — such as seeking to define ERM at the driver’s request in relation to the task they’re working on — or solutions to an impending issue while the driver continues making progress elsewhere. This helps ensure that work is always moving forward and that both developers feel supported. Roles will often swap over the course of a project, especially when areas of expertise present themselves and an individual can tackle them.

Different pairings can lead to different results

The pairings of developers will have a marked impact on how a task and the individuals will progress. Most developer partnerships can be identified as the following:

Expert – Expert

Ideal for highly complex tasks that require vast amounts of knowledge or expertise to accomplish. Both developers will be highly skilled and can support each other in creative problem-solving and collaborative contribution to the codebase.

Expert – Novice

Ideal for medium-scale projects where both developers can partake in contribution and the senior developer has room to educate and monitor output before task completion. The novice benefits from expert guidance and support, while the expert gets the opportunity to educate and support another team member.

This pairing is particularly effective when aiming for a minimum viable product, as the expert can guide the novice in focusing on essential features and functionalities to deliver a functional solution efficiently.

Novice – Novice

Ideal for simple or low-priority projects, where junior developers can spend time learning and growing with each other to resolve the issue. Best used as part of onboarding activities and training exercises, such as exploring the differences and benefits between Spark vs PySpark.

Depending on whether you need absolute precision within a project or want to create learning opportunities for the team, pairing your developers correctly is a key part of effective pair programming management.

Pair programming can boost morale while speeding up projects

Let’s say your development team is tasked with building a framework allowing for artificial intelligence in customer experience monitoring, and a series of required functions are outlined — live monitoring of data, and export tools for third-party manipulation at a minimum. A project of this scope might seem unmanageable for an individual to tackle, but a pair of expert programmers can work together to break it down and succeed.

The morale boost from working together cannot be understated, especially when things get challenging, and there will be time saved from having additional resources working on a task. In many cases, simply having support when facing difficult circumstances can be the difference between success and failure.

Additionally, with the right infrastructure, like dedicated hosting, teams can ensure consistent and reliable performance, even when working remotely.This is particularly crucial for industries such as finance, where data security and confidentiality are paramount concerns. Therefore, pair programming becomes an indispensable strategy for a finance software development company, ensuring both efficiency and security in collaborative coding efforts.

Pair programming can work remotely with the right tools

With modern technology, it’s incredibly easy for developers to work remotely and still work in pairs contributing to a shared codebase, communicating effectively the whole way. While it is still recommended for teams to work side-by-side when contributing to a single resource, remote working provides a viable alternative that supports modern practices in 2024.

There are several tools that can help facilitate quality output, such as robust communication tools — shared or remote desktop access, screen sharing capabilities, and reliable text and voice communication apps all help to build a seamless experience for developers working as a pair.

Additionally, it’s essential to prioritize security measures, including DMARC compliance, to ensure the protection of sensitive information and maintain a secure development environment. This helps prevent email spoofing and phishing attacks by allowing domain owners to specify how their emails should be authenticated and handled by receiving mail servers.

Not every pairing is going to work out

The unfortunate truth is that everyone isn’t always going to get along. Some personalities clash, and some methods of working won’t lead to an effective partnership. Instead of pushing the issue, if you see problems arise then act to make a change.

This can present itself in stagnation on a project, low output, complaints from a team member, or a lack of contribution by an individual. Always monitor these factors to ensure that everyone is happy and working towards a common goal.

How can pair programming be helpful?

Much in the way that AI in communication appears magical in its ability to transform internal and external comms, an established development pair is capable of programming wizardry they’d be unable to achieve alone.

Think of pair programming as a force multiplier to expedite projects, as a method to train individuals in a real-world environment, and to learn more about your individual developers themselves and their capabilities. It’s a flexible tool to help break programmers out of ruts, promote their personal development, and let them showcase their creativity in a supportive atmosphere.

Can pair programming be harmful?

There are some risks to consider when actively pursuing a pair programming approach. Many of these can be mitigated with proper care, and some will only arise when the pairs themselves are not working effectively.

The main challenges to be aware of include:

Increased cost per project
Lengthier time to complete some projects
Less capacity to tackle multiple projects
Internal conflicts

As long as you monitor your teams closely, the above issues can be largely sidestepped, and the benefits of pair programming can truly shine.

The next steps

Start thinking about how you can implement pair programming strategies into your upcoming projects. If you have reports of stalled development or frustration from individual programmers, that’s the perfect time to explore pair programming and provide a fresh approach for the team to get involved with.

Always remain attentive and agile in your actions when managing pairs. If they’re unhappy or ineffective, don’t be afraid to switch things up and keep changing the dynamic. When things start working, that’s your cue to step away and let them get on with the task at hand. Pair programming can help breathe new life into tired development processes and get teams working creatively again.

Bio:

Jessica True is the Senior Director for Marketing Strategy and Operations at Dialpad, a modern business communications platform that takes every kind of conversation to the next level—turning conversations into opportunities. Jessica is an expert in collaborating with multifunctional teams to execute and optimize marketing efforts, for both company and client campaigns. Here is her LinkedIn.

Derek Lee Boire, Senior Member of Technical Staff at VMware Pivotal Labs, addresses common developer frustrations, such as decision fatigue, and the tools and methods to overcome them.

If you’re a developer, whether you realize it or not, you’ve probably experienced ‘decision fatigue’ at one point in your career. Decision fatigue occurs when the quality of the decisions we make deteriorates due to the mental fatigue of having already made a lot of decisions. While some people may want to believe that they have infinite willpower, our mental energy and focus has a limit no different than our physical bodies do. You can train long, or you can train hard – either way your body will tire eventually.

But just as we can train our bodies to endure additional stress, we can also train our minds to increase our focus. Or ideally – simplify our work to allow us to save our energy for the mental challenges that really make a difference. For example, a person with a clear idea of how they would like to manage their diet will be able to make easier decisions when grocery shopping, which can be helpful when different options are particularly abundant.

While this example refers to a relatively simple, personal decision, it’s even more important to alleviate the burden of choice for more complex decisions which involve a greater number of stakeholders. These are the types of decisions software developers will make with each line of code written, putting them at a high-risk of experiencing decision fatigue. Here we look at some of the ways in which decision fatigue and other common developer frustrations that can manifest in software development, and the tools and methods that can be employed to combat them.

Common developer frustrations

Discoverability

If there is a task that must be performed many times, or takes a long time to do manually, or is complicated and error-prone, developers should consider using automation. Continuous integration and continuous delivery (CI/CD), the practice of automating testing and deployment of your application, is one example of this. When you automate a process, you don’t just make it easier to execute, save time, and ensure consistency – you also make it discoverable.

This means that if a new member joins the team and has never worked with CI/CD before, reviewing the script that manages this automated process will help them to easily understand how the application is deployed.

This can apply to source-code as well. If you’ve ever worked on a backend API that is consumed by others, you know how important it is for your API to be easily understood in order for users to easily consume it. This same level of understanding can be applied to your internal APIs that you build for yourself, for future you, and for other members of your team.

As software engineers, we are all authors. As such, we need to consider the audience who is consuming the code that we are writing.

Rabbit Holes

When working independently, it can be easy to find yourself lost down a “rabbit hole” – deep into trying to solve a problem and unable to remember where you had started or why you went down this route in the first place. Developers working in isolation are particularly prone to finding themselves in a rabbit hole, which is a sure-fire sign that decision fatigue is settling in.

Collaborative development processes, like pair programming, help developers avoid rabbit holes through creating a culture of fast feedback and knowledge-sharing. When there’s only one person who understands how a specific feature was implemented, this carries a risk for the team if that person is out on vacation, happens to get sick, or is out for any number of reasons, then the team can get stuck.

One recommended practice for pair programming is to rotate who pairs with who daily to ensure that several different team members have knowledge of how each part of the system works. This is a great way to share knowledge throughout the team as well as to ensure that the team can always continue to make forward progress, even if a team member is unavailable.

Pair programming is built upon equality and mutual respect, a by-product of which is the establishment and/or sustenance of a culture of knowledge-sharing. Approaches to collaboration based on equal parts observation and communication are always more effective in keeping people engaged. After all, too much of one or not enough of the other can make it difficult to concentrate, which is especially detrimental when trying to absorb or share knowledge. For example, I recently learned from a pair programming session about how test-driven deployment (TDD) could be applied to configuring docker containers using scripting purely vicariously.

Domino Code

Unsure how to implement a new feature or enhance an existing feature? If there’s a similar feature in the application, it could be a good reference so you can just follow the existing code patterns and tack on the new functionality, right? Sure, this might work for the first or second time – but by the third or fourth time you’ve repeated this pattern, it could start to get unwieldy. The easy way may be to follow the same pattern, and this can be good to maintain consistency in the codebase. However, to ensure that the software can continue to evolve, a different abstraction might be helpful.

Developers often see an existing pattern and simply copy and paste or tack on more of the same. While the pattern may have been easy to understand when it was initially implemented, repeated use can eventually create a ‘domino’ effect – whereby that same pattern, at scale, may no longer serve the code after it has evolved.

While there are some developers who are strictly against code duplication, it can sometimes actually be helpful. There’s a delicate balance between code duplication and creating a premature abstraction. Sometimes duplication is, in fact, necessary if an abstraction or cleaner way of writing can’t yet be discerned. It can be good to just let the code “simmer” for a bit longer and see how it will evolve.

Developers should therefore be aware of the code being copied or the patterns continually being promoted in the code. The next time you find an existing code pattern and your initial instinct is to simply copy it, consider this: the next time you or someone else encounters this code, would it make sense to continue using this pattern, or is it time to consider refactoring or creating an abstraction? A good example is when a class becomes so long that it is difficult to manage (also known as ‘long class code smell’ amongst developers). The easy action is to continue to add to it and make it longer. When you detect this “smell”, consider if it would become easier to manage if it was broken down into more than one class. Are there multiple responsibilities within the same class that could be separated?

Culture of Growing and Sharing Knowledge

This is by no means an exhaustive list of all practices for building code which works for everyone. Consistency in the practices deployed (i.e. code style, formatting, automation) is another significant area where many of the major barriers can be overcome. But the first step toward implementing any of the practices described here involves a more widespread, cultural change within the organisation itself.

Developers work best when organisational culture promotes growing and sharing knowledge within the team. This should be approached comprehensively rather than on the basis of incentives: “lunch and learn” sessions are great, but free food will only get you so far when you don’t really get to take a break from work. Instead, development teams should tie core values like communication, courage and respect to every aspect of the work they do. Doing this will help alleviate common barriers faced by developers to writing great software, while also contributing to an increase in productivity, quality of work, and developer well-being.

About

Derek Lee Boire is a Senior Member of Technical Staff at VMware Pivotal Labs. Derek’s career as an IT professional and consultant has given him experience in every aspect of software development. From working with clients to understand and detail their requirements, prototyping solutions, designing technical architectures for large-scale systems, leading development teams and helping implement agile design methodologies.

GitHub: derekleerock

Twitter: @derekleerock