Skip to content

Latest commit

 

History

History
88 lines (55 loc) · 5.52 KB

pairing-in-phase-0.md

File metadata and controls

88 lines (55 loc) · 5.52 KB
Raw

Table of Contents

Pairing in Phase 0

Pairing is common in software development. Software Engineers pair in order to:

  • reduce code errors and/or catch errors early
  • share or transfer knowledge
  • on-board new developers

Pairing can feel stressful or awkward at first. We ask that you keep an open mind on pairing throughout DBC and challenge yourself to work on your pairing skills while here.

Expectations

As part of Phase 0, students are expected to pair program with another student in their cohort, from any location, at least 2 times per week (with the exception of Week 1). Each week has mandatory pairing challenges you will need to pair on.

While it is not mandatory, we encourage students to pair with a different person in each session. Diverse pairing will strengthen your pairing skills more quickly.

It is up to each student to arrange pairing sessions. We suggest posting on the discussion board in Canvas (devbootcamp.instructure.com) to request a pairing session. In your post, it helps to state a time/times (including a time zone) and the challenge you want to pair on. Once another student says they are available to pair, you should decide whether you will attempt the challenge before the agreed upon time or decide to not work on it before the session.

  • A peer pairing session must be at least 45 minutes to be counted as one of your sessions.
  • You can work on any of the challenges for the week except for the solo challenges.
  • You must pair on "Mandatory Pairing" challenges.
  • Guided Pairing Sessions (GPS) DO NOT count as peer-pairing sessions.
  • You must give feedback to your pair after every session in the Feedback App.

Driver and Navigator Roles

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.

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.

Pairing Dynamics

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.

Success Guidelines

You will be successful in your Peer-Pairing sessions if you:

  • Check in with your pair according to the Pairing is Caring video.
  • Decide which of you will start as the driver and navigator, discuss what each role requires, and stick with it.
  • Alternate between driving and navigating. Aim to spend about 50% of your time in each role.
  • Keep communication open and tell your pair when you need time to think.
  • Make sure both of you know the exact line of code and the concept you are discussing.
  • Ask your pair for their opinions and ideas often.
  • Allow yourself to make mistakes.
  • Submit feedback to help your pair improve.
  • Use feedback you've received to become a better pair.

Pairing Remotely

Pairing over the internet has its unique issues. It is easy to misinterpret people's intentions and tone. Technical issues can create added difficulties on understanding one another.

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.

Try your best to work from a quiet place with a reliable Internet connection. It is usually helpful to have headphones for your sessions as well.

Strategies for difficult sessions

If you feel your pair isn't listening to you or taking your perspective into account, you need to speak up! Your pair is learning this new skill, too. Make sure you bring up your concerns with specific, actionable,and kind feedback. I messaging is a great way to do this. "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.

I-messages are a powerful communication tool that prevents conflicts from escalating.

Pairing Resources