On Pairing
Paring Down the Peer Pair
August 16, 2014
My favorite time to pair isn’t necessarily at the beginning of a project, but rather after I’ve already completed (or started) my code. To be able to come into a pairing sessions with code already written, and questions already formulated to discuss with your pair peer is the best way to learn in my opinion. There’s been many times that I’ve struggled with getting the result I needed from the code I’ve created and its been super helpful to set up quick chats (that often turn into long conversations) with other cohort members to go over the extremely different ways we solved the problem. Not only have peers helped me to discover issues I may have overlooked in testing, but they’ve also been able to help me change the way that I look at possible solutions by helping me verbalize the steps that must be performed in order to complete the method.
One of the most rewarding things is when a pair peer comes to me with a solution that doesn’t work correctly and asks for help. Diving into another person’s code and trying to understand their solution and methodology often solidifies my own knowledge. It’s the most rewarding, however, when I can find out why someone’s code isn’t working and help them to discover the problem or help them simplify their solution. The other day I was looking over a peer’s solo challenge that they were having difficulty with and after an hour of trying different things without completely changing their code, I stepped back and asked why they were using a certain series of methods to target and change the array. I was able to look back at the code and immediately realize that they had made their code much more complicated than it needed to be. I was able to remove multiple unnecessary lines and methods and turn something that was long and didn’t work, into a one line method.
On Feedback:
It feels good to read my feedback. I think that the more that I pair with certain people, the more that we are able to be honest and give better feedback to one another. Although some feedback is very short and not exactly helpful, most of it contains little gems of wisdom. These include not being so hard on myself, not trying to reinvent the wheel, or just taking a little extra time to read the literature each week and play around with the code outside of the homework assignments to understand it a little better. I definitely think that my feedback has positively impacted my working relationships with my pairs and also my working relationship with myself over the last few weeks.
The most difficult thing about feedback is just writing intentionally about your experiences with your partner. For me I am so concentrated on building the relationship during the pairing session and in getting the project done that I forget to even think about what sort of feedback the peer pair needs. Perhaps I just need to be more focused on how I can help my peers to become better pairs and better coders during our sessions rather than focusing on how insecure I am about the code, my methodology, and even what I know.