Pair Programming and Feedback

November 28, 2014

Part of DBC's curriculum is pair programming, which involves collaboratively completing a coding challenge with a partner. There are loosely defined roles, that of the driver and navigator. The driver has their hands on the keys and writes the immediate code, and the navigator gives direction and a higher-level view. The best experience, however, is when the roles are more fluid, based on who is feeling more comfortable with the current hurdle. In this way, the pairing session becomes a two-way street of both learning from your partner and teaching your partner. Both of these actions are super rewarding: you cement your own understanding by teaching content you know, and you learn from your partner new techniques and ways of thinking. It can be incredibly inspiring when you're easily able to do a challenge together, when it would have been taxing solo.

The trick to a successful pair programming session is to stay away from those frustrating moments of being stuck. I've found that one important element of not getting stuck is to keep the communication flowing. Even if you need time to think, express so. Think aloud. This keeps you and your partner on the same page, checking each other's thought processes. The other important element I've found is to pseudocode together. This helps you formulate a plan, even if you don't know how to implement each step. Then you can research methods or ways of accomplishing the smaller steps–and it is easier for both parties to understand exactly what needs to be done, what to research, where you're trying to go.

Part of pair programming at DBC involves giving feedback to and receiving feedback from your partner. I enjoyed reading my feedback. It confirmed many thoughts I had been having as I reflected on my pairing experiences. Primary of which is the usefulness of continuous communication and pseudocoding, discussed above. As such, receiving the feedback is helpful to my learning, because I can now implement constructive changes in how I pair in the future. I want to be explicit when I need to think, and try my best to communicate what I am thinking. I will offer pseduocoding as a tactic for understanding the challenge at hand and being on the same page with my partner. And I will continue to offer a more fluid approach to roles, as I feel it is ultimately more efficient to be agile and adaptive.

As I mentioned, giving feedback is part of the pair programming process as well. I find giving feedback a useful tool to openly and frankly discuss the tactics my partner and I used during our session. Often I find that we debrief personally before signing off. It's nice to be able to acknowledge that we are all continually learning how to operate professionally and efficiently. Sometimes this kind of feedback can be difficult, but I think it relies on admitting that no pair programming session is one-sided. Both partners contribute to the session and the result. So admitting fault in feedback opens up a way to constructively criticize how both partners can improve in the next round.

Overall, I think using pairing to guide one's learning is an effective strategy. Not only does one have to check their own knowledge before teaching it to someone else, but one has the opportunity to learn from their partner. It can be a truly empowering experience.