February 22nd, 2019
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.
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.
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?
What makes for a bad pairing session?
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!