The Case for Pair Programming for Data Science, for 2021 and beyond

Pair programming is a popular agile development practice where two programmers sit in front of a shared screen to write code in a collaborative effort. Research shows it can help you write better-quality code, either faster or slower, depending on the complexity of the task and the developer’s skill level. We believe that the benefits of pair programming extend to data science and are increasingly important for maintaining relationships among team members in a remote-first workforce. In this article, we’ll examine the importance of pair programming when teams are fully remote and offer ideas for tasks that data scientists can work on collaboratively.

The WFH dilemma

Remote work has taken away the spontaneous interactions our team used to have in the office. There are less casual conversations (no more classic Monday “How was your weekend?” chitchat). We also seem less likely to ask, “Would you mind coming over here and helping me debug this issue?” Although we could technically have these interactions over Zoom, they do occur at a much lower rate in the digital realm than they did in the physical realm. Sometimes, we even resort to hours-long asynchronous debugging sessions over Slack, rather than hopping on a Zoom call, even in cases where the call would be more effective. While we all acknowledge that screen-to-screen interactions are down compared to the face-to-face interactions we had in the office, we are trying to reverse this trend. Pair programming can aid in re-creating the social dynamics of face-to-face interactions in a remote-first world, while allowing us to collaboratively solve tough data and programming problems.

Why you should pair program in 2021

Pair programming is more important now than ever before, and yet it has remained largely unchanged. The reasons why you should practice it have been the same for decades. More importantly, in a remote-first workplace, any debate over pros versus cons of pair programming is vastly outweighed by the need to maintain a healthy team dynamic via more face-to-face interaction. Additionally, pair programming is inherently well suited for remote work. Video-call technology still lets both programmers share the same screen as they would have in person, only now the two participants are more than six feet apart. Now let’s apply this traditional software development exercise to data science and see how it can help your (now) remote data science team thrive.

Pair programming for data science

In this section, we list a number of tasks and activities that data scientists often perform, which may be more productive, and fun, when tackled collaboratively and can still work well virtually. At WW, our team adheres to the full-stack or end-to-end approach to data science, with each data scientist owning a data product from start (getting access to the data for initial exploratory analysis) to finish (deploying a model-serving application to production). Thus, the ideas here range from traditional software development coding exercises to machine-learning (ML) domain-specific tasks.

Classic pair programming tasks

The job of a data scientist increasingly overlaps with that of a software engineer. These are some examples of tasks for a traditional pair programming session where each participant can take turns playing the driver and navigator roles, but with a data science spin.

• Build a demo: Telling a product manager (PM) about your model’s high F1 score is a great way to get an awkward “That’s cool” response. However, showing a PM a demo of a data product that could be using your model is a great way to get on the product roadmap for the next quarter. By taking turns testing different app designs and then trying them out as a user, two data scientists could quickly come up with a demo of a minimal viable product that might be more likely to win over a product manager than a solo endeavor. Packages like Streamlit make this rapid iterative development of an app demo possible using pure Python in only a few hours, making this a viable exercise for a single pair programming session.
• Build or refactor a model-serving API: Building a production-ready ML serving application is a complex task. Working with a partner gives you a second pair of eyes to vet and select a design with more confidence in its chances of success. Similarly, a second opinion during a refactor could help you make an existing service faster and more reliable. If this seems ambitious for a single session, newer frameworks like FastAPI can help you build an ML-serving API within hours, complete with all the bells and whistles you need for production.
• Write tests: There are many ways data pipelines can fail, and traditional unit and integration tests are still useful, but not always sufficient. With a partner, brainstorm data edge cases and other sources of risk for your data products, then make sure your tests address them. For example, you might need statistical tests on data in your pipelines that are run before every model retrain or tests after the model retrains, to ensure predictions haven’t drifted before the model is automatically pushed to production. Don’t forget load testing, too! In addition to Pytest, other libraries like Hypothesis, Great Expectations, and Locust can help you level up your testing suite, and you can be up and running with them in under an hour.
• Streamline MLOps pipelines: Most MLOps platforms involve running directed acyclic graphs (DAGs) where each node is some component of an ML pipeline: reading data, transforming it, training or predicting, writing out predictions, etc. We use our own open-source DAG-running framework: Primrose. However, regardless of which framework you use, your codebase can become bloated with many similar, but project-specific, DAG nodes. Combined, two data scientists will touch many more of your team’s projects than one, empowering them to better identify which nodes can be refactored and replaced with a single, more generic, and reusable version.
• Debug: This is more just a PSA reminder to move that debugging session from Slack to Zoom!

Data-specific endeavors

These exercises aren’t geared toward a traditional pair programming approach, where one person writes tests and the other person writes code to pass them. However, they are valuable exercises for data scientists to trade techniques, share perspectives on the data, and have fun while doing so.

• Investigating data quality issues: This is basically debugging, but for data scientists. With their combined experiences filling in each other’s blind spots, two team members will be better able to navigate your labyrinth of data pipelines, helping you get to the root of data quality issues quicker. As a bonus, if you compile a table or graph with some metrics that helped identify an issue, you can turn that code into an automated report with triggers to alert your team of future data quality issues.
• Exploratory data analysis (EDA): When you first obtain a dataset, you often want to explore the dataset to get a sense of the shape, distributions, and quirks of the data. However, we each have a certain perspective, and others might notice patterns that we don’t. Collaboratively exploring the data; slicing, dicing, and discussing the data in real time; plotting distributions in R or Python; or mapping spatial data in Tableau is a fun and useful exercise.
• Data labeling: Data scientists always crave more data but sometimes the easiest way to increase sample size is to hand-label. At WW Data Science, we often turn this into a team session, collaboratively divvying out work and tasks in Google Sheets or live-chatting about edge cases in Slack as we work. While we do this as a team, it can work well in pairs, too.
• Logging: Comb through the logs for your services, and discuss if you are capturing everything you might want for a future model iteration. Is there a missing feature that could be useful in the future? Add it to the logs now before one of you has to iterate on a model and wishes you had been collecting that information.

Good for everyone

These are not unique to data science, nor do they fit the traditional model of pair programming, but we still think these exercises are useful to do in pairs on our team.

• Explore a new package: When vetting new tools for the team, it’s best to have more of the team represented in the vetting process to broaden the perspective of your evaluation. It’s also an excuse to test exciting new technology that you otherwise can never find the time to try. So grab a buddy and play around with the latest Hugging Face release, give quantum computing a try with Amazon Braket, or take Facebook AI’s KILT for a spin. It’s not always clear what value you may find in a new tool until you experience what it can do.
• Write documentation: Have one person familiar with an undocumented piece of your codebase write docs for it, then have a second person read the docs and attempt to interact with that part of the codebase. Would the docs make sense to a new hire being onboarded to your team? Pairing senior and junior members could be especially useful in this exercise. This is a great time to work on your written communication, before someone goes on vacation and a bug is found in their undocumented code.

Evaluating the exercise

Pair programming is an excellent way to have your data science team complete productive tasks while fostering social interaction in a remote-first workplace. We came up with this list of pair programming tasks to help our data science team grow both its technical skills and interpersonal relationships, and it’s going well so far! If you are trying out any of these pair programming ideas or have other ideas for how data scientists can pair program, please share with us what you learned!

— Brian Graham, Senior Data Scientist at WW

Interested in joining the WW team? Check out the Careers page to view technology job listings as well as open positions on other teams.