Pair Programming -- the real experience

For the rest of the week I paired with a Crafter. I’m going to share a bit about my experience. I’ll also share what I think makes a successful pairing and what makes a bad session.

Before pairing, I asked the Crafter if there was anything that I should read or review before our session. She said that since we would be working in Swift, I should review some of the basics. So before our session, I downloaded Xcode and I started looking at the Swift docs. Then I started a Swift tutorial, and this helped me to get a feel for the language and the environment.

After working on the tutorial for a bit I was feeling ready to pair. I was confident that I’d have more questions about the structure and implementation rather than the syntax and Xcode environment. The pairing session started on Tuesday morning. One thing that I appreciated before starting was that my pair checked in with me and set up some general expectations for the week. She asked where my head was and if I had any questions about Swift. She also said that we’d also be working in Java; that I was welcome to the group’s standup meetings; and that I would be the “driver” the following day. Her expectations about what I would learn and what we would work on was very clear. She set the tone for what my experience would be — I felt like I would be able to ask questions and I knew what to expect for each day we paired. Before our session, I was nervous that I’d slow her down or that I wouldn’t be able to keep up and follow along with the advanced code. However, after she went over our game plan, I felt calm and welcomed. I was ready to engage, ask questions, and explain my thought process.

After our check-in and user story review, we dug into the code. She went over the sections that we’d be working on, which I appreciated. Seeing folders upon folders made me a little nervous. I always feel like I need to look at every single file and colon in a code base, but we focused strictly on the few files that we needed to complete the story.

My overall goal was to contribute as much as I could, but I really wanted to be able to look at the codebase and not feel completely lost. I felt like there were times where I was actually able to help. I’d written a couple of methods, but it was really my questions that helped us come up with tests and code. We worked on things and when we had a roadblock, we researched the docs and stackoverflow for help. Pairing with an experienced programmer made me realize that struggling over code, confirming incoming data, and researching for solutions was not just something that inexperienced developers did. I initially thought that developers were just rolling through code effortlessly — in reality the process seemed to be the same. They just have more experience in pinpointing their issues and knowing how to quickly find what they need to keep moving forward. Asking questions and explaining our thought processes was a large part of pinpointing issues and finding solutions. Luckily for me, I felt comfortable asking questions and asking for further clarifications when an explanation wasn’t enough. Where a explanation wasn’t enough, since I’m a visual learner, my pair made diagrams for me which really helped me see where I was stuck. Constant and clear communication of what I didn’t understand and what I’d need in order to understand made the experience more valuable. I was able to work on communicating my needs and areas of confusion. This communication style allowed me to learn more about programming concepts and what the solutions might look like for the codebase that we were working on.

One aspect that I don’t want to overlook is her knowledge about the code that already existed and what everyone else was working on. I don’t know what our experience would have looked like if it was also her first time seeing the code. I think it helped that she had written a lot of what was in the code base. She knew her way around the files. She knew the overall architecture and the fine details. If needed, she was also able to locate the other developers and ask questions about their contributions.

Then we started looking at Java. I don’t know anything about Java except that looking at it makes me sleepy. During our Java moments, I had to get up and take breaks. I had to ask more questions to stay engaged as I got used to looking at that type of language. However, by our last pairing session, I felt comfortable with Swift and Java in that I knew what kind of quirks to expect with each language and I felt comfortable with expressing what was needed even if I wasn’t exactly sure how to code it. I knew what the solutions would entail and what potential issues would appear.

Overall

So overall, I think it was a valuable experience. After each day of pairing, my pair asked me for feedback and provided me with some feedback. This challenged me to think about what I got out of the experience and it challenged me to identify and work on my own opportunities. It seems that I lost focus whenever we worked in the Java sections. I need to do some additional digging into that language. Anyhow, I hope to have additional pairing sessions as I think it makes coding easier and speeds up the coding process. Two heads definitely seems better than one lonely, confused head. I especially enjoyed demystifying the experience of advanced developers. I enjoyed getting a true sense of what they worked on and how they communicated with others involved in the project.

Lessons Learned

Here is a brief overview of what makes for a good pairing session and one aspect of pairing that I had to work on:

What makes for a good pairing session?

1. Check-In and setting expectations — Checking in and setting the goals for the session puts everyone on the same page. It sets a welcoming environment.
2. Asking questions — Asking questions helps with conceptualizing solutions, solidifying knowledge, and learning new concepts. Asking questions is also a way to stay focused and engaged. Having a pair that respects questions makes the environment more welcoming and boosts communication. If I’m not comfortable asking questions, I’m probably not going to be comfortable with sharing my concerns, making mistakes, or contributing with ease.
3. Clarifications — My pair provided addition drawings on the whiteboard, which made things easier for me to understand and gave me the opportunity to express any further gaps in knowledge.
4. Workspace — Having a good workspace setup made pairing stress free. Along with our laptops, we had a shared monitor, two additional keyboardset, and a whiteboard to work with.
5. Taking breaks — Coffee and snack breaks were a must after looking at advanced code. Moving around got my blood flowing and helped me regain focus.
6. Expressing driver/navigator roles — Setting up clear expectations of who would be typing allowed us both to see what I struggled with and helped me stay engaged.
7. Codebase knowledge — My pair knew the codebase for several months prior to our session. This meant she knew the structure of the code and how everything was connected. She also knew who to ask for clarification.
8. Getting feedback after each session — Receiving and providing feedback after every session (and even during sessions) challenges you to think about why things are going well, what things could improve as far as communication or just experience in general, and what you’re learning from the experience.

What makes for a bad pairing session?

1. Losing focus — Besides not considering the elements that make a good pairing session, the only potential downside of pairing is derailing the session when someone loses focus. There were a couple of times where I was getting sleepy and the communication slowed down or a couple of times where I prompted non-code related questions, which resulted in both of us losing focus for a few minutes. It wasn’t anything major for us, but I could see how that could spiral into unproductively for others. However, my pair called me out on this, nicely of course, and I was more intentional about staying focused and keeping non-code conversation to a minimum.
2. You or your pair being a jerk — This may seem like a given, but it really helps if your pair (or self) isn't a jerk. Lucky for me, my pair was beyond a decent person -- she's very empathetic, caring, and feedback driven.

So that’s my story on pairing. I didn’t think I’d have more than a few words to mention about it and yet, here we are!