On Pair Programming
When I was in elementary school, maybe first or second grade, my teacher paired up the class for a geography assignment. My partner - let's call her Jenny - and I were given a globe and a worksheet. The worksheet asked questions like, "What are the four major oceans?" and "Which country is located south of France?"
Now I was pretty good at geography, probably from playing some Flash-based quiz games online or filling out the workbooks my parents would buy to keep my siblings and I entertained on road trips. Jenny, however, did not share the same prior knowledge. We would read a question together, then I would blurt out: "Oh! Atlantic, Pacific, Indian, and Arctic! Next question!" Before long, "we" had finished the entire worksheet. When I called the teacher over to check our work, I was surprised to find myself being scolded. She said something like, "Aiden, are you working together with Jenny or doing it all yourself? We are doing this exercise so she can learn too." The teacher then asked me to go back through each question while pointing to the relevant area on the globe and explaining my reasoning to Jenny.
Fast forward to a few weeks ago. My coworker - let's call him Steve - was assigned a task that was very similar to one I just finished. In fact, it was so similar that the team agreed he could just copy and paste about 75% of my code, then make a few tweaks at the end. So Steve set up a meeting for the two of us and one other colleague to review my code and make the necessary changes.
During the meeting, I shared my screen and stepped through the chunks of code I had written. I have always sought to write the most simple and straightforward code possible, but these tasks were a bit complicated. It had taken me several full work days to arrive at my solution, then a few more days to resolve edge cases that popped up when I started testing, and another day or two to rewrite it for improved readability and performance. Having done all this work recently, I had a pretty nuanced view of the task at hand.
I knew my coworkers were familiar with our codebase, but new to this specific assignment. After I finished walking through my code, they inquired about a few details like the intermediate outputs from each step of the process. I happily demonstrated an example case. Then, I explained that if I were Steve, I would just copy and paste the code up to line X and explore approach Y to complete the rest of his task. Our time was up for that particular session, so I sent my colleagues the file we had been looking at and we went our separate ways.
The next day Steve invited me to another working session. When it started, he said, "Hey Aiden, can you share your screen again and we'll keep working?" I agreed. My intention was not to hijack Steve's assignment. I was hoping to just pass on whatever knowledge I had accumulated on the topic so that he could successfully finish it for himself. But it seemed increasingly like this was becoming a pair programming situation. I had no objections.
I started with the approach I suggested in the previous session. I typed up a rough first draft, explaining each line, and printing the output to the screen. The room was silent. I explained how the output fell short of some requirements and highlighted the problem areas. By this point, I was frequently stopping to ask, "What do you guys think about X? Maybe we could try Y? Any ideas for how we can fix Z?" My colleagues were contributing very little. I assumed I had gone too quickly, maybe they were not following. So I went back through everything step by step, explaining my thought process. At the end, I asked: "Does that make sense?" They nodded.
We continued on like this for several more sessions. I knew that I was doing more than my share of the work, and it was not my task to begin with, but my team was not eager to offer up anything. I did not want to rob them the opportunity of learning like I had with Jenny. But this was a time-sensitive assignment, and I was the "expert" on the topic, so it made sense for me to take the lead. It did not seem like my counterparts were spending any time outside of our sessions reviewing the code or coming up with any ideas.
Eventually, "we" came up with some working code and "our" efforts culminated in a few final sessions of running through some test cases and making minor fixes. These meetings were especially silent. At one point, I described why I decided to rewrite a certain section of code, to which a colleague replied, "Oh yeah, I was about to suggest that." The quiet, lonely problem solving reminded me of a LeetCode interview gone wrong.
Generally, I like pair programming. The first computer science lab I took in college mandated that students paired, and I have happy memories of working with a good friend, trying to wrap our heads around Java and OOP. It was collaborative, back-and-forth. We took turns typing and throwing out ideas. We corrected each others' syntax errors and logical bugs. But this recent experience at work has me questioning where in the process things went wrong.
I worry that I didn't allow my teammates the opportunity to learn. Did I take too much control? Should I have let them flounder on their own, making the same mistakes I did so they could come to the same understanding? I could have refused the keyboard, asking them to type for a while.
Are my coworkers also partially to blame for our failed attempts at pair programming? Were they too passive, afraid to ask questions or make suggestions? Should they have spent more time preparing for our sessions? Two or three minds can be greater than one, but it takes a concerted effort from all parties involved. You can't have a know-it-all who plows ahead and does all the work themselves. You also can't have members who refuse to contribute.
I suspect there are no concrete answers to what went wrong. I feel dissatisfied with the level of cooperation from all parties involved. It helps to retrospect on how well I'm performing as a teammate and reflect on what behaviors I can improve. I hope to work with those who do the same.