Skip to content

Latest commit

 

History

History
86 lines (63 loc) · 4.75 KB

working-together.md

File metadata and controls

86 lines (63 loc) · 4.75 KB
Raw

Pair Programming

We encourage pair programming between all levels of experience. Nobody is required to pair program for a certain amount of time, but it is a great tool to help solve complex problems quickly and more efficiently with an extra set of eyes.

Code that is written by two people who sit next to each other at the same computer is pair-programmed code. The best way to pair program is to just sit side by side in front of the monitor. Slide the key board and mouse back and forth. Both programmers concentrate on the code being written. The programmers undertake one of two parts — the Driver and the navigator. The driver in the process is responsible for diligently drafting code, while the navigator’s job is to review and concentrates on the plan of action.

That code is considered high quality and should result in cost savings due to less maintenance. The matter of fact is, pair programming technique can take around 15% longer, yet produces 15% lesser defects. In the long run, this style of development saves money because fewer bugs are written and therefore do not need to be fixed later.

Generally we use it for complex pull requests review and coaching and fixing

How?

  • When pair programming, one person should “drive” while the other “navigates.” The navigator will assist the driver with the code they should write and explain the reasoning behind any code that they might dictate

  • The driver should be implementing the code that the navigator recommends, while frequently pausing to ask questions about the code. When the pair programming session is over, both parties should have a deep understanding of the code that they have committed

  • Generally the one responsible for typing is known as the ‘Driver’, while the other one called the ‘Navigator’ continually revise and review what is being coded or typed. During the whole of their time with each other, the duo invariably keeps in touch, enabling the other partner to participate and help outline the code direction.

  • The objective is to share the workload between both the participants in order to maintain the constant development stream and also to help spread knowledge over the team.

The driver and the reviewer should constantly interact with each other as it will add to the knowledge and efficiency for both the members.

Before:

  • Agree Scope (Pairing for two hours? Until the ticket is complete? Just get past the bug?)
  • Agree Physical/Virtual Location ("Will we both be comfortable here?")
  • Agree Working Environment (Two keyboards? Text editor and other tools)
  • Agree Pairing Style (Time-based? Ping pong?)

During:

  • Keep the chat going (Think aloud. Encourage/support)
  • Keep switching (Follow the pairing style)
  • Keep both involved ("Could we do this another way?")
  • Keep breaking
  • Keep checking in ("Could we search for a guide separately?")

After:

  • Ask for Feedback (What did we do well? What could we have done better? It’ll feel weird, do it anyway)

Do

Communication is what that makes all the difference.

Strong-type pairing

For an idea to go from your head to the computer it must go through someone else’s hands. Whenever the driver requires pitching in the idea, he must handover the system to his partner and then carryout the control from the observer position

Don't

That’s possibly because the person in charge of typing isn’t communicating, or perhaps the reviewer doesn’t want to bother him. Many times I’ve observed where the driver put forth ‘just a minute, I’ve got an idea’ and keep on working, the navigator check their social accounts or do some other irrelevant tasks.

Pros

Paired programmers are only 15% slower than two independent individual programmers, but produce 15% less mistakes Around 96% of the pair programmers reported in an online survey that they enjoyed their work in a pair programming environment than working alone. Establishing a senior-junior combo might be a great step to refine the junior’s skills and proficiency.

Significant Pair Programming Markers

Some notes that we should consider applying

During Pairing

  • Let me drive
  • Could you assist me?
  • Let’s do it together
  • Here’s my plan
  • What plan do you have in mind?
  • How does this code block work? Let’s perform unit test
  • I’m tired? What’s up?
  • I don’t get the point. Draw me a design
  • Did we overlook something?

Take a Short Break

  • Can we take a break?
  • Can we switch roles?
  • Let’s go out for a cup of coffee

Remember

  • Don’t force it
  • Give your partner an opportunity to drive at the RIGHT time
  • Encourage open communication
  • Don’t ignore breaks
  • Trust
  • Identify your mistakes
  • Criticize yourself first
  • Slow down

TAKE AWAY

  • Sync
  • Communicate to sync