Pair Programming gives you efficient, effective transfer of knowledge, values, and culture
It’s clear to me that regularly rotating Pairs of programmers gives you efficient, effective transfer of knowledge, values, and culture.
- A good idea, once envisioned, is soon practiced by every pair.
- Pairing ensures adoption of the highest common denominator, naturally. There is no need for additional (time consuming, distracting, and inefficient) processes.
There is a lot to learn and keep up with: Rails best practices, new gems, testing strategies, OOP Design, and more. I have found Pairing to be the best way to decrease the team’s skill delta. When we are Pairing, not only do we learn about Pattern “X”, but we know why we used it, how it works, what some issues are, and we can share that with others — while we continue to write production code.
Decisions which affect the entire team are initially made by at least two members of the team. Pairing ensures we identify differences in flow, quickly. Some examples I’ve experienced:
- Why does your machine take 20 sec. to load Rails, but mine takes 4?
- What do you mean these features have been broken for a week?
- The last release introduced Concerns as a first-class object, we should really use them here.
Once Pairing, you will almost certainly find your developers are using their tools more efficiently, as they share tips and tricks. Pairing makes communication so commonplace that even the simple questions get asked… and answered.
- You should write to the gem’s author.
- You mean git squash doesn’t require rebase?
If your team isn’t Pair Programming, then you have many silos of knowledge. Knowledge that could help your team be a better team.
“If the programmers like each other, they play a game called ‘pair programming’. And if not, then the game is called ‘peer review’.” — @ashalynd
Matt Scilipoti
matts@scilipoti.name
github.com/mattscilipoti
