Pair Programming is an important part of the culture and teaching style of DBC. We believe that everyone learns better by teaching and mentoring.
Additionally, pair programming and Agile Development are increasingly common in software development in general and pretty standard for Ruby on Rails jobs. It is also likely to be part of the interview process.
Software Engineers pair in order to:
- reduce code errors and/or catch errors early
- share or transfer knowledge
- on-board new developers
That said pairing varies between teams. Some pair 99% of the time; some pair only some of the time; others pair only when it makes sense.
Pairing doesn't feel natural or easy for everyone. We ask that you keep an open-mind on pairing throughout DBC and challenge yourself to work on your pairing skills while here.
Within the industry there are a number of different pairing arrangements. In each case, two programmers code with only one person typing at a time.
Driver-Navigator pairing involves the driver typing and the navigator talking and leading the driver. The driver gives input, but should be focused on the area of code instructed by the navigator. The driver presses the gas, but the navigator says when to turn.
This is probably the most common pairing technique professionally, particularly in Test-Driven Development environments. It involves one person writing a test for the code and the other person writing the code to pass the test. You may use this type of pairing in Phases 2 and 3.
This is a variation of Driver-Navigator pairing, where one person is more knowledgable about the problem or technique than the other. Depending on the goal of the pairing session, this can either involve:
- Expert Drives The expert acts as a mentor helping to guide the novice in the right direction without giving away too much. This variation is often used during job interviews.
- Novice Drives This allows the expert to relay information and teach in a very focused way. However, there is risk of the novice disengaging if the expert just tells him/her what to do. Pairing should always feel like a conversation.
- Novice observes In this scenario, the novice observes while the expert drives and navigates. This can be used to demonstrate information, but should never be used for a full pairing session.
It is common -- and expected -- that pairs switch roles.
Ideally, switching happens organically. Half way through each pairing session you and your pair should switch roles if you haven't already.
For Phase 0 (and much of your time as DBC), we will use Driver-Navigator pairing.
If there is a case where one student is more knowledgable or has already completed a problem, you should almost always use Expert-Novice where Expert Drives
In Phase 0, we will be very rigid about roles for pairing. Once you enter DBC, you will have more flexibility. However, we want to ingrain appropriate action for each role.
This means:
- The Driver should never be looking at a line of code they are not told to look at by the Navigator.
- The Navigator should always describe what code they are looking at by the line number.
- The Driver should never type code or comments before discussing with the Navigator.
- No one should spend an entire pairing session as the Driver. The exception to this is Expert-Novice pairing where you should always use Expert Drives.
Successful pairing requires two components:
Good communication during pairing is mainly through vocalizing your thoughts and thought process.
If you don't understand, you should tell your partner.
If you want to try something in IRB, tell your pair.
If you want to go research something, tell your partner.
Tell your partner everything you are thinking and doing!
Both people should know the exact line of code and the solution or concept they are discussing.
Good pairing sessions feel like a conversation.
Pairing remotely is more difficult than pairing in person. You can't see a person's body language or face. To be successful, remote pairing requires discipline in adhering to pairing roles and excessive communication.
While pairing in Phase 0, you cannot communicate too much. For realz.
I hope it goes without saying (but I will say it anyway) that pairing or any other communication during DBC should not involve inappropriate topics. DBC is a respectful place filled with people of diverse backgrounds. In particular, comments of a sexual nature or related to sex, gender, sexual orientation, race, disability, and class should never be made and will not be tolerated. Please email your instructor if you feel another student violated this policy.