Don’t go alone: Lessons learned in pair programming.
“Like this but in a basement, in Denver.”
As technology becomes more integrated into daily life and programming skill sets become more necessary, it can be easy to overlook the human side of the industry — the “professional skills” that facilitate the code. Pair programming is becoming a more widely used practice and with it comes its own challenges — ones that require the ability to communicate clearly, openly, and often.
After completing our first two week paired project (a version of the original Battleship game played through the terminal) at Turing School of Software and Design, we (Ricardo Ledesma and Tony Robertson) held a “recap session” to go over what we learned to provide feedback to each other. Ricardo suggested that we document our conversation and thoughts. This article covers said conversation.
They discussed three main topics: pair programming, initial project expectations, and the DTR process.
- A DTR (Define the relationship) is a technique used to define goals, guidelines, and expectations for a group of developers going into a project. They learned this as a part of Turing’s professional development curriculum.
All of Turing’s curriculum is open source — check out the professional development curriculum DTR article here
Pair Programming
Pair programming comes down to establishing a relationship and building trust by breaking down any potential communication barriers. What this means is being clear and upfront about expectations and creating strategies to ensure those expectations are being followed (and what to do when they are not).
The style we ended up using the most was Driver — Navigator
- This means one person is coding (Driver) and the other is offering guidance (Navigator)
Why we chose this style:
Tony: “My experience at Turing has been mostly driver navigator. It’s worked out very well and I feel the reason for that is because we are in person and sharing ideas as we work through problems. It also allows each of us to know what’s going on with that section of the code without too much review…
Ricardo: “I don’t have as much experience but from what I do have (Community College group projects) dividing up the work that needs to be done and working on those parts in isolation lead to some confusion as to how each part connected with the other”
Tony: “Near the end of the project though we both felt we should divide up the task of refactoring the project which I think went really well.”
Ricardo: “The code was written separately but we still checked in with each other on what was done whenever it was a substantial refactor — this is what I changed and this is how it works now”
In order to ensure effective pairing on a project — code collaboratively even if you are coding separately — keep those “check-ins” as a part of the process. The specific pairing style is something you can re-evaluate as the project continues.
Communication
- Address levels of experience early on
- Separate between experience with process and experience with concepts
- Communication breakdowns and how you handle them
Tony: “Communication was one of the most important aspects to our partnership. Overall I felt we had great communication but when communication failed it was very noticeable…”
Ricardo: “Failures in communication were due to assumptions being made as to what it was that one of us was confused on. Copying code without understanding it is something I found frustrating but my gap in understanding was with what a Mock object even was. Assumptions were made as to the source of frustration and confusion — we would recommend to always ask when this comes up in your pairing”
Tony: “I agree. We stated in the first DTR that we were both somewhat experienced in programming but we left it at that. As the project went along I got a sense of your skill level and made the mistake of assuming you knew the concepts of mocking in regards to testing. So when we were tackling the problem my goal was to piece together how mocking and stubbing worked in minitest and just assumed you were frustrated with that process and not being unaware of mocking in general.”
Ricardo: “We both recognized in the moment however that it was best to move on to another part of the project and take a break from the problem. I would say this helped the miscommunication from becoming anything substantial”
Levels of experience are often going to vary when working with others in development. Areas of experience are not exclusive to just programming. Someone could be more experienced with processes or project management. It’s helpful to define these strengths early on.
Initial Project Expectations
What we wanted to gain from the project:
We started out with specific technical skills (Ruby syntax, Git workflow, building a REPL interface). This was beneficial but we would also recommend choosing a high-level direction to guide the project.
Talking Points:
- Learning vs Completion
- Doing things for the sake of marking checkboxes
- Doing things that give most value in terms of knowledge gained
- Going outside your comfort zone
It’s far more challenging and rewarding to try and take on a difficult aspect of a project for which you have no prior knowledge or experience.
- For us that meant taking on the task of building our project in the browser. This was something that neither of us had any prior experience in — using Ruby on the front end.
- Different levels of drive. People hitting walls at different times.
Tony: “I think initially we both just listed specific smaller aspects we wanted to learn in the project and not a larger overview of what we wanted to gain. It wasn’t until late in the project where we came close to completing the project specs and were moving into extensions is where we somewhat had to redefine what it was we wanted out of the project. ”
Ricardo: “We started more conservative when it came to what we were going to feasibly get to in the project. Later on, we had to define for ourselves what value we wanted to get out of the project. This is where we made an important distinction between doing more work for the sake of completion and doing work that would stretch our abilities as developers.”
Revisiting the DTR
Why you should do it:
- Provides moment to reassess goals and how successfully guidelines have been adhered to.
- Air out any failures in communication or assumptions made prior to the revisit.
Our revisited expectations:
Set an MVP (Minimum Viable Product)
- An initial MVP is typically just based off of given guidelines but once you get past those — define your own MVP and assess progress against that.
- For us, once we were nearly finished with original guidelines, we defined our MVP of doing at least two of the extensions — preferably changing our program to function in the browser.
Burnout.
- Determine when each developer’s hit their wall if they already did so before this point of revisiting. How long does it take each developer to hit their wall? Consider if it’s best to finish for the day when this happens or if a long break is simply what is needed.
Readdressing work styles or pairing decision.
- If you chose Driver-Navigator — is that still the best technique, always?
- If you chose another pairing process — is this process working in regards to communication — the interconnectedness of the classes, methods, general structure — is that still clear?
Something we would recommend but wasn’t something we directly experienced:
- If one developer is substantially more experienced than the other — determine different kinds of goals.
- The experienced developer will have goals that include solidifying concepts through teaching. Ensuring that techniques, concepts, and principles are being taught effectively.
- The less experienced developer may have goals in regards to understanding the specifics of what they are being taught by the end of the project.
The practice of mentoring another developer is crucial to any organization. Time spent strengthening the abilities of another developer will be worth it in the long run through the forming of a more effective team.
In retrospect the project went very well. But it’s important for growth and development to analyze areas for improvement. Having this post-project discussion really helped clarify areas in the future that we both can improve upon when working in a paired programming environment. We even came to a better understanding of what exactly were some misconceptions or false assumptions we had that we previously were unaware of. Revisiting the DTR gives a solid frame of mind to have when moving into our future collaborations, and we highly encourage this process for anyone.
Checkout the project we worked on here. Also our Githubs for other code we’ve written:
Ricardo Ledesma’s Github
Tony Robertson’s Github
Thanks for reading, happy coding!
