The one with pair programming

Act 1

Victor is a mid-level software engineer with two years of experience. He works at WeShop payments team building out financial accounting solution for WeShop merchants. He has team members with a variety of experience on his team, and he did pair programming with different team members. He paired with a junior developer Jason on building out a monthly invoicing feature.

Another Monday, the sun rises and shed a light on the talk skyscrapers in downtown Chicago. Victor woke up with his alarm and reflectively went to the living and pressed the button on the coffee machine. He is not ready for the weekend to be over, and he feels a bit reluctant at the thought of going back to work. “Oh well, I will make the best out of it.” He thought, sipping at the black coffee while staring outside of his apartment window. His apartment is in a downtown location. It’s early in the morning and Victor can see a few people walking on the street here and there.

At 8am, he packed his work backpack and headed out. His company WeShop, an e-commerce company, is only 15-minute walk away from his apartment. Graduated two years ago from college, Victor has been working at WeShop as a software engineer and had just been promoted to a mid level engineer. He works on the payments team, which is in charge of building software for WeShop merchants who sell goods on WeShop software platform.

This spring is a busy time for Victor and his team. WeShop aims to provide a more flexible payment solutions to accommodate its growing merchant population, and the payment team is at the center of rolling out of that software.

As a tradition of WeShop engineering, they adopted a very strict “pair programming” culture, where two developers will work on one computer, and one set of key board together. The goal is to ensure software quality by having two people think about the same problem at the same time, encourage collaboration and personal growth as well. Angela, the engineering manager on the payments team, is a big proponent of pair programming, for the project in this spring, she has been actively working with the tech lead on the team, to divide the big project into smaller engineering features, and assigned a pair on each feature.

For Victor, Angela has assigned him an monthly invoicing feature, and have Jason, a new recent college graduate, as his pair. Angela told Victor that it’s a new challenge for him to be more of leader in this assigned pair, not only to finish the feature but to mentor Jason to become a better engineer. The feature itself is pretty straightforward: at the beginning of each month, there’s a scheduled job that ingest a formatted file and create payment records based on the content of the file. Victor felt excited for this opportunity, he felt that this is a good exercise for him to become a senior software engineer at WeShop.

“Hey, Jason, are you ready to pair?” Victor sent Jason a message through company chat. Jason confirmed that he is ready and came over to Victor’s desk. Victor already had an extra pair of mouse and keyboard ready for Jason.

The two started on the task on the feature to send monthly invoice. Victor knew the software design pattern established in the code base, so he immediately created the files that follow the existing pattern. “We will need to add tests first to describe the behavior.” Victor explained, and Jason nodded and confirmed his statement. So far so good. The pair is moving along.

After 20 minutes or so, however, Victor started to feel something weird. He will ask a question on how to proceed with some portion of the code, but will hear nothing from Jason. In fact, he felt that Jason was not contributing at all. All Jason is doing is watching. Victor continued on the pair programming feeling like it’s mostly him that is doing the coding. He felt annoyed but continued without complaints, occasionally talking out loud his thought while writing out code. After 1 hour or so, Victor felt tired and suggested that they took a break.

“Okay.” This is the first time Jason said something, with a hint of refreshment, or excitement. Victor became even more annoyed by Jason’s comment, he made him think that Jason is slacking off during the pairing session. Victor immediately attributed Jason’s attitude as he being lazy, and he felt like he needed to talk to his manager Angela about this.

In their regular one on one meeting, Victor poured out his emotion about his pair programming experience with Jason to Angela. He complained that when he paired with Jason, Jason wasn’t engaging at all, and Jason was simply watching Victor code and “can’t wait” to take a break when the time is up. Angela listened intently, realizing that Victor is venting out his problems, and acknowledging his emotions by nodding as Victor continued to vent his problems for 5 minutes. After venting, both of them took a long pause, which made Victor feel a bit uncomfortable.

“Can I ask you a question, Victor?” Angela finally broke the silence, “When you and Jason started pairing, what did you do?”

“What do you mean?” Victor was a bit puzzled by that question, “I’m not sure I understand the question. For pairing programming, we sat together, and we started programming.” After finishing the sentence, Victor even felt a bit defensive.

Angela nodded, acknowledging Victor’s answer, and then continued, “I understood that part, but did you and Jason share the context on what you two are working on? Does he know that you two are working on the feature of monthly invoicing, and were you two on the same page on the general approach?”

Victor went quiet for a while, the question made him think. He recalled that he jumped right into the code without telling the context of what they are working on, and he started to recall Jason face being confused but reluctant to say anything. Victor started to think that maybe he moved too fast.

Angela noticed Victor’s face, and she started to suggest, “maybe what helps is pairing with different people on the team to get a different experience. I know Kumar is working on the feature of scheduled payments, it’s a bit more work and he can definitely use a pair.” Victor nodded. Victor asked about the feature of monthly invoicing because it is still in progress, but Angela suggested that they can pause on the feature a bit. Victor got a sense that Angela wanted him to get a different perspective on pair programming, and he agreed because he also sensed that he has a lot to learn.

Act 2

Victor paired with a senior engineer Kumar on his team to build out a scheduled payment solution, the dynamic of pair programming is vastly different. Kumar was attentive to Victor’s understanding of the problem, and he was patient throughout the pairing process. In the end, Victor felt that he had a solid grasp of a complicated problem, and he felt that he was able to contribute.

Kumar is a senior software engineer on the team. Growing up in India, Kumar moved to the United States for graduate school at Georgia Tech and started working in the US after graduation. He’s in his early thirties with a mild manner and soft spoken voice.

The scheduled payment solution is a complicated tasks. Based on the contract a merchant signed with WeShop, an algorithm will run to determine the percentage of payments. If there’s refund happen before the scheduled payment, some amount needs to be subtracted to count for the refunds. In addition, the company needs to perform accounting on the scheduled payments as booked revenue, so some reports need to be generated.

On the first day of their pairing, Victor brought his extra pair of keyboard and mouse to Kumar’s desk, they sat down and casually chatted for a while. As Victor is getting ready to type on the keyboard, Kumar actually stopped him. “Let’s go to the whiteboard,” Kumar said, “let’s collaborate on the overall design.” Victor wasn’t expecting that, and agreed to the whiteboard as it’s a good idea.

Kumar walked to the whiteboard and start to draw different boxes representing different parts for the system - databases, APIs, background jobs, and service modules, etc. He started by describing the existing system components, then describing the business requirements of scheduled payments. Every now and then, Kumar would pause and ask Victor if he has any questions. Victor appreciated Kumar’s patience and stay engaged through the whole time, he starts to have some ideas on the feature of scheduled payments, and it seemed less mysterious to him.

After describing the business requirements, Kumar paused intently, he looked at Victor and then at the whiteboard, “the question is, how do we design scheduled payments system at WeShop?”

Victor also stared at the whiteboard for a while, he had some ideas on what to build and volunteered to draw out what needs to happen. The two went on discussing the design for another 30 minutes. Each proposed solutions and asked questions along the way. In the end, they both reached a list of prioritized tasks and ready to develop.

The pairing session went better than Victor expected. Because both of them came up with the solution together, they are clear on tasks they are going to achieve. In addition, because they have identified multiple tasks, Kumar intentionally asked that they take turn to type on the keyboard, that is, to “drive” the pair programming. Each task contains a small change within a codebase, so that no one person keeps typing for too long.

Another thing that worked really well for Victor is due to Kumar’s patience. He has a lot more experience in the industry than Victor, and whenever Victor has a technical question, Kumar would slow down, either grab a piece of paper to draw out certain concept, or open up a separate computer console to demonstrate some code concept in a simple manner. What really distinguished Kumar, Victor realized, is that not only Kumar understands technology concept deeply, but also he has the patience and willingness to share it with others.

After the first day of pairing, Victor was exhausted but in a good way. He felt that there was a good amount of “following” by watching Kumar writing code, and a good amount of “driving” by writing out code himself. He felt that through the pair programming there’s good amount of discussion and feedback, and they both understood “what is done” and “why it is done”.

The pairing between Kumar and Victor went on for a week, after the pairing, they have basic skeleton of scheduled payment code done, both of them understand what needs to be done next. They both feel that they have a solid grasp of the problem domain. To increase knowledge sharing, the team members also rotate pairs, and Victor walked away feeling that he has learned a lot from this experience.

In the following one on one with Angela, Victor shared his experience pairing with Kumar. Angela was happy to hear that Victor has new realizations on how to pair more effectively.

“So Jason is still working on the monthly invoice feature. And he seems struggling with it a bit, do you mind pairing with him next week?” Angela asked.

“Yes, absolutely!” Victor replied, and this time he’s determined to be a better pair.

Act 3

Victor talked to some other people about his different pairing experience with a junior / senior developer, and derived some principles that apply to pair programming in general. He paired with Jason again, this time the pairing experience is different.

On Monday Victor started pairing with Jason again. With the new knowledge in mind, Victor decided that he is going to approach pairing a bit differently. He brought his keyboard and mouse over Jason’s desk and connected everything to his computer. “Before we start pairing, do you mind giving some context on the current progress of the feature?”, Victor asked.

Jason nodded, he opened up his code editor and started to walk through the code he wrote. Jason tried to went through file by file, and sometimes jumped through files to tie an idea together - like when he was explaining how the schedule is set up to run the job on a monthly basis, he had to jump between a configuration file and the file for the actual command. Right now Jason is having trouble to verify the command actually runs in an environment, and he also needs to add monitoring and alerting mechanism around the job.

Victor listened and nodded along the way. During the code walkthrough, there were multiple places where he felt that he would do things differently, but he intentionally held all his questions in his mind - the pair programming is about coming together with a best solution, not having one person come up with the best answer. Victor asked a few business domain questions, which made the pair on the same page.

“Okay, sounds like right now we need to make thing run on our remote server?” Victor asked, he thought he knew the answer but nevertheless asked so that they have a shared understanding.

“Yes, I can go to the console and trigger this job locally, but I am not sure like.. How to make this thing run on our QA (quality assurance) environments.”

Victor has done deployment of this sort in the past, and he knew that to do this they have to change the puppet configuration file. He reminded himself the goal of pair program is sharing context, and decided to not to provide answer right away. Instead, he decided to go slow.

“Okay, let’s see if we can find any documentation around how we do deployment at WeShop.” Victor suggested, although already knowing the answer.

Jason entered into the browser the company’s wiki page and started searching for deployment, and very soon they arrived a page about deployment of service. They read through page silently together, and realized that the page is outdated, but there’s a code repository that the document points to which seems to store most of the puppet configure files. They clicked into that configure file repository and saw some unfamiliar code - as engineers who mostly work on features, Victor and Jason don’t really touch the code configuration files all the often. Jason stopped navigating the code, he’s not sure what to do. “Yeah I read this code before, and I know I should change something here, but I’m not sure how to start.” Jason confessed.

“Well, we will figure this out together!” Victor said lightheartedly, “I know that we also have a monthly report job that has already been implemented, why don’t we look into what’s been done there, as a start?” Victor implemented that job about two months ago, although he knew all the steps to configure a job, he planned to have them follow the code path, study it and configure the new job together.

The pair looked at the application code for monthly report job, and then searched the other repository for puppet configuration. As they searched the configuration, there were a few new concepts that Jason was not so familiar with, like how puppet modules are organized. Whenever the pair had a question, Victor will intentionally have them slow down, either read the code or documentation, and sometimes to explain a concept, they would use paper to demonstrate a point. Victor can tell that Jason appreciated that Victor took the time to explain everything, and partially because of that, Jason is more engaged during the pairing, trying to drive as much as possible. To Victor, this has been beneficial too: to teach Jason what he knows already requires him to understand the knowledge in a deeper depth. For example, in order to explain Puppet modules to Jason, Victor had to go to the Puppet documentation several times and actually relearned some fundamental concepts he was super familiar before.

After a week of pairing, the pair was able to deploy the monthly voice commands on their cloud server, and they added a few things in the deployment process that Victor didn’t know before. Both of them felt that they have a good grasp of how the deployment process worked. And the trust between Victor and Jason have grown due to this collaborative experience.