In fact, over the past thirty-five years, about half of the Nobel Prizes in Physiology or Medicine have gone to scientific partnerships.
In “Powers of Two: Finding the Essence of Innovation in Creative Pairs,” Joshua Wolf Shenk quotes an interview in which John Lennon explained that either he or Paul McCartney would “write the good bit, the part that was easy, like ‘I read the news today’ or whatever it was.
” One of them would lack inspiration until the other arrived.
Lennon followed up with, “I would sing half, and he would be inspired to write the next bit and vice versa.
” Anyone can fall into a creative rut from time to time, but it is rare for two people to do so concurrently.
The formal definition of pair programming on Wikipedia states:Pair programming is an agile software development technique in which two programmers work together at one workstation.
One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in.
The two programmers switch roles frequently.
Pair programming is not about taking turns using the computer or having a teacher vs.
student approach.
A mentoring relationship is quite different from two people working jointly as equals, even if one has significantly more experience.
At its core, pair programming is engaging two minds on the same problem so that a solution can be developed more quickly and with higher quality than if one person was working on it alone.
With increased quality, benefits will emerge later in the project.
It might feel awkward at first, but like other new skills, pair programming takes some time to get used to.
Pair programming is somewhat similar to dating; it’s a social skill that will improve with practice.
The primary objective is to strive for a cooperative way to function.
This includes give and take from each partner regardless of their corporate status.
A common opinion for the ideal method to pair program is to sit side by side in front of the monitor, sliding the keyboard back and forth.
More on that later…The structure of pair programming has two roles: driver and navigator.
The driver is the one with hands on the keyboard, writing the code.
The navigator is the one who observes and reviews each line of code as it is typed in.
The driver’s fundamental job is to deal with the details of typing and writing ideas into the computer.
However, the driver’s main goal is to be of service to the navigator with trust and support.
They should voice their opinion or challenge things if they have questions, but since their primary job is to type the code it can be difficult for them to think several steps ahead.
While this requires being comfortable working with an incomplete understanding of the task, it’s usually a more efficient way to work.
On the other hand, the navigator is able to work with a more comprehensive context by cause of not having to type the code.
The navigator’s overall goal is to present information for the driver to process with clarity and ease.
They should think about the problem with a more conceptual frame of mind.
The navigator should promptly give the driver instructions needed to implement with an acceptable level of abstraction so the driver can enter them most efficiently.
Because the navigator is thinking about the problem at a higher level of abstraction, they have a sense of the overall task at hand and the direction they want to go.
The diagrams I found had poor resolution quality, so I made this on creately.
comIf the driver has an idea for what to do next while the navigator is directing, the solution is to switch roles.
This can help both partners stay in sync with each other.
Bouncing ideas off each other while brainstorming will not only decrease mistakes but will also stimulate creativity and workflow.
A key characteristic of exceptional pair programmers is knowing when to say “Let’s try your idea first.
”One piece of advice I can give pair programmers is to take a break and ask each other questions.
This will help you engage each other in meaningful conversation and encourage a heightened understanding of each other.
Breaks are also ideal for passing the keyboard back and forth.
Pairing and Workstation FlowA typical pair programming setupWhile researching I found that there are several different strategies for pairing.
Some of the possible pairing options can be found here.
One of the more interesting approaches I found during my research for this blog is called “Ping-Pong Pairing.
” Essentially, the approach is something like this:Coder A writes a new test and sees that it fails.
Coder B implements the code needed to pass the test.
Coder B writes the next test and sees that it fails.
Coder A implements the code needed to pass the test.
Back to the top.
This doesn’t sound like my ideal workflow, but I won’t knock it until I try it.
Something exciting I learned about from a classmate recently is that Atom has a package called Teletype that allows developers to share their workspace with team members and collaborate on code in real time.
It’s an advanced screen sharing portal that allows each of the host’s guest to individually type and edit code within the same workspace.
As the host moves between files, collaborators follow along with the active tab automatically.
I think this is a really cool feature and I will be definitely be testing this out on my next project to see if my team’s productivity can be increased.
Some Benefits:Pair pressure can help ensure timely delivery of projectsImproved on-boarding of new team membersBetter team building and communicationDecrease in the cost of fixing defectsLess distraction, leading to higher productivityIncrease in programmers’ confidenceImproved satisfactionContinuous reviewSome Tips to Remember:Trading roles “frequently” throughout the day is important.
You shouldn’t necessarily set a definitive timer because it can interrupt workflow.
Many people suggest that you should be switching roles from just a few minutes to twenty or thirty minutes.
Pair rotation can be beneficial.
However, if you’re a manager always specifically assigning each pair or choosing selective pairs close to a project’s release are not advised approaches.
“The adjustment period from solo programming to collaborative programming was like eating a hot pepper.
The first time you try it, you may not like it because you are not used to it.
However the more you eat it, the more you like it.
” — AnonymousThe quote above really resonated with me.
Furthermore, my initial inspiration for this blog post came from reading The New Yorker’s article “The Friendship That Made Google.
” (Check it out! It’s a great read).
The article details how Jeff Dean and Sanjay Ghemawat became Google’s Senior Fellows — the company’s first and only Level 11 engineers.
If the top two engineers at Google were able to successfully change the path for the company as well as the internet as a whole, it leads me to believe there is a significant correlation between pair programming and achieving great heights.
In Closing…Llewellyn Falco, a successful Agile Programming coach, uses the phrase “strong-style pair programming.
” He says “In order for an idea to go from your head into the computer, it must go through someone else’s hands.
This style of programming is all about increasing communication and collaboration.
” My primary takeaway from Llewellyn’s blog post is that communication and collaboration are fundamental to success.
Personally, I can say from experience that I am much more productive in a pair or group setting.
My background as a musician taught me that I prefer to perform in an ensemble vs.
being a solo artist.
It’s not that I am relying on the other person (people), but rather, my confidence increases exponentially when I feel somewhat of an obligation to do better than on my own.
Also, I am the kind of person that feeds off of other people’s energy.
When I pair program, my production rate significantly increases.
My current skills have shown me I’m currently a better navigator than a driver, but I plan to focus on being great at both.
I hope that after reading this you can see why this type of collaboration is encouraged why it might be beneficial to your future projects.
lolz.