Peer pairing is an industry practice in which two developers work at one computer simultaneously on the same code. One developer will assume the role of the navigator, directing and managing the overall input, while the other serves as the driver, manually writing the code. The latter is often making the more detailed choices around syntax, while the former is dictating what the code needs to do. It's a synergistic approach for collaboration, putting two eyes on the code for review in order to achieve the best code possible.
At Dev Bootcamp, we are expected to pair weekly in order to get more experience. Because students are spread across the U.S., we often collaborate through video conferencing and stypi, rather than working at the same station. Nevertheless, the roles of navigator and driver are the same.
For me personally, pairing has been a great way to learn and reinforce concepts. When I'm in the role of the navigator, it's usually a great opportunity to practice explaining to someone what I want the code to do or which methods I would like to use. I'm essentially getting more practice explaining my thought process and communicating clearly. As a driver, I often find that I'm getting more experience with syntax in Ruby, while also learning from the navigator new approaches or methods to tackle a problem. In general, I feel like I learn more from my pairing sessions than I do while working alone.
Some of our peer-pairing sessions are facilitated by a guide, who will answer questions if we get stuck and provide feedback on how we pair. I think it's great to get an outside perspective on how I work while pairing, especially feedback on how I can improve. In general, providing feedback is a big part of the Dev Bootcamp culture. For every pairing session, we are expected to provide feedback on our partner. As a rule of thumb, feedback is expected to be actionable, specific, and kind. This means that feedback provided has to be something our partner can act on in a constructive way. It also means there needs to be specificity to the feedback so they have a clear idea where they excelled and where they need improvement. The feedback also needs to be written in a way that is respectful.
When reviewing feedback I've received so far, the most common critique I receive is to timebox and work on syntax. My pairing sessions tend to run a little long, because I forget to establish a timebox for each piece of code so that we don't waste time on one part. As a Navigator, I'm relatively up-to-speed on what the code should do and the overall approach we should take, but as a driver, I find myself occasionally having to fix syntax errors or familiarize myself with syntax. As a result, I'm now working more on timeboxing, as well as syntax. In general, the feedback helps me stay mindful of how to communicate and work in a pairing session.
As meta-feedback, we also receive anonymous ratings on the feedback we provide to others. For the first feedback I wrote, I was unsure of how to address our session simultaneously with brevity and specifity, and I couldn't think of anything actionable my partner could do to improve. The meta-feedback I received on that particular one inspired me to make a more concerted effort to be specific about what was done during the session and what can be improved. In general, I strive to write kind feedback and avoid writing anything that is negative. I try to frame everything as a way to improve, while emphasizing aspects at which my partner excelled. I think the meta-feedback is great way of assessing how my tone is perceived in writing.