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.
During phase-0, you have a required number of pairing sessions per unit (Unit 1: 4 times, Unit 2: 6 times, Unit 3: 6 times) along with the 2 guided pairing sessions per unit. This adds up to a lot of time spent coding with others! Pairing is a key part of the DevBootcamp's secret sauce to create world class beginner. You will be doing even more pairing when you get to DevBootcamp on site, so consider this an opportunity to fine tune your pairing before diving deep on site.
The first step in pairing is to decide who will be driver and navigator. Here are the definitions of the roles.
Driver:
This is the person with the hands on the keyboard. By default all typing of code should come from the driver. If the navigator wants to type something, asking permission is the best procedure. Drivers should have a decent grasp on syntax and be able to implement most of what is discussed without step-by-step instructions from the navigator.
Navigator:
This is the person who is not typing. This frees you up to look for syntax errors, research quickly, have docs open etc. Your role in the development of the program is the same as the driver, you just do not type unless permission is granted.
The navigator is not an annoying back-seat driver. The role is not to say:
"Type d.e.f. space my underscore method new line"
Instead it should go something like: "Let's make a method. What should we call it?"
If the driver needs help with syntax, by all means help them, but pairing shoud be a conversation, not step-by-step directions.
Take the time to discuss your understandings of these roles and talk about characteristics of successful and unsucessful pairing sessions before you get started coding to ensure you are both on the same page.
Who has the power in this relationship?
Neither role is more powerful than the other. You are just 2 programmers trying to solve a problem together. The roles are there to make you more efficient, not bog you down. Think of this as a brainstorming session with the driver holding the marker. Both of you are thinking of ideas simultaneously and discussing which ones are good enough to get on the board.
It is common -- and expected -- that pairs switch roles.
Discuss with your pair before starting the exercise at what point you would like to switch (time based, exercise based, etc.).
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 over the internet has its unique issues. It is easy to misinterpret peoples intentions and tone when you do not have a full picture of their body language, technical issues can create added difficulties on understanding one another. Be aware of these issues and be proactive in combating them.
Overcommunication is preferable when working remotely, especially when you are just starting to pair with someone. You can find out how they like to work and communicate as you go, but to start be overly expressive of your needs. It really helps to get things started on the right foot!
Phase 0 is built to prepare you for working on site at DevBootcamp, but post DevBootcamp you may work at a job that is 100% remote and only communicate with people over the internet. These skills will put you in a great place to feel comfortable with jobs like this.
If you feel your pair isn't listening to you or taking your perspective into account. You need to speak up! If you feel like there is a problem in your pair arrangement, say something. It helps no one to 'grin and bear it.' Your pair will appreciate the insight with how they are effecting other people and you will get to voice your concerns. Make sure you bring up your concerns with specific, actionable,and kind feedback. "I messages" are a great way to do this. I messaging, "I messages" generally follow this format
I feel... (Insert feeling word) when... (tell what caused the feeling). I would like... (tell what you want to happen instead).
For example:
I felt ignored when I brought up my idea about how many arguments that method should accept. I would like to have more of an open discourse with the direction of the code.
Instead of:
You aren't listening to me, stop being difficult. I want to talk about the number of arguments the method should accept.
It sounds silly, but it is an amazingly powerful communication tool that prevents conflicts from escalating.
Be mindful of what topics you bring up in conversation with your pair. Treat your pairing session like you would an office space. Do not say anything that would not say to your future bosses, coworkers, and employees. DBC is a respectful place filled with people of diverse backgrounds. In particular, negative 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.
- Peer-Pairing in Phase 0
- Good Check-ins for Pairing Video: 5 min
- Our collaborative coding editor video Stypi 2 min
- Guided Pairing Sessions (GPS) in Phase 0
- Giving and Receiving Feedback 27 min