taylor-smith · March 27, 2014 14:52
diff --git a/Pairing and you b/Pairing and you
 * Pair programming vs pair learning
 	* pair learning: use two computers, get a chance to get some muscle memory going, but also interact with each other to reinforce the concepts. **Even if you find a concept easy to accomplish, there is undoubtedly reinforcing you can do.**
 	* pair programming: use **one** computer, you should have one keyboard between two people, and one monitor/laptop. Decide who will be "driving" and who will be "navigating"
 		* driver: your goal is to write code. You should be spending most of your time doing one of two things, writing code based on your discussions with the navigator, or discussing/researching what to write along with the navigator
 		* navigator: your goal is to keep the driver writing good code, or discussing what could be done to enable writing good code. You might think of the steps necessary to complete the task at hand, and what files/external resources might be the next thing to do. On top of this, you should be looking out for syntax and logic errors to help mitigate problems before they happen. 
 
 ## Pair programming shouldn't feel confining		
 * Pair programming is often a seamless experience. You might be coding solo for a little while and reach a point where you are either stuck or just need someone to bounce ideas off of. You can try the [rubber duck problem solving method](http://blog.codinghorror.com/rubber-duck-problem-solving/) to help solve your problem, but even then, it might be more effective to have another set of eyes on the problem.  At this point, it might make sense to ask someone to pair with you so you can explain your code and potentially get new solutions to your current problems that may not have come to you directly. When pairing goes right, you'll know it, because it will *feel right* and ultimately you should see yourselves working through problems efficiently, and finding a balanced workflow that includes steady verbal communication and verbally working through problems.  You are solving problems as well as increasing your own understanding, so those problems are not problems anymore and make sense.
 
 ## Common pairing problems:
 * Problem: How do I ask for someone to pair with me? 
 	* Simply put, you should try asking your partner or someone you want to pair with "are you busy right now? Would it be possible to pair on this problem, I could use another set of eyes" and, if your partner is free, you can start working on the problem. It is paramount that no one "hogs" the keyboard or the role as decision-maker. To be truly effective, pairing has to be a collaborative effort--the dialog will only help to work through problems better, even when one pair is more or less advanced than the other.  Dialogue does involve trying to ask good questions of each other, and turning those inquiries into actions whether research queries or typing code.
 * Problem: Pairing doesn't seem to work for me...
 	* Often beginners are at a loss about how to pair effectively. Some of this will come with practice. Make sure you've given pairing a fair shot and tried a sufficiently diverse amount of pairs before you give up on it.
 	* If, after attempting to pair for a while, you determine that you truly do work most effectively without others working with you directly, it is totally OK. You will still probably find it highly beneficial to have a classmate or your mentor to review your code after its been written to see if there is room for improvement.  You will most likely have questions about concepts you have encountered and about the decisions and trade offs you are making about coding something a particular. That is still pairing to work through those questions together, since it will often involved two minds talking through some code.
 	
 	
 ## Wrap-up
 At the end of the day, pair programming *should* benefit you. If it isn't, ask yourself "why?" Did you feel communication wasn't very strong? Did you feel it was a problem with you, or do you think it was a problem with your partner? Do you find yourself encountering the same issues every time you pair? 
 
 Feel free to ask one of the instructors about some of the issues you're running into, and see if they have any advice for how to pair more effectively. Remember, the instructors have dealt with many groups of students who had no experience pairing, and they have probably encountered the same problems you're running into more than a few times by now--they may have some insight into the problems you're facing.
 
 Good luck and happy pairing!
	* Pair programming vs pair learning
	* pair learning: use two computers, get a chance to get some muscle memory going, but also interact with each other to reinforce the concepts. Even if you find a concept easy to accomplish, there is undoubtedly reinforcing you can do.
	* pair programming: use one computer, you should have one keyboard between two people, and one monitor/laptop. Decide who will be "driving" and who will be "navigating"
	* driver: your goal is to write code. You should be spending most of your time doing one of two things, writing code based on your discussions with the navigator, or discussing/researching what to write along with the navigator
	* navigator: your goal is to keep the driver writing good code, or discussing what could be done to enable writing good code. You might think of the steps necessary to complete the task at hand, and what files/external resources might be the next thing to do. On top of this, you should be looking out for syntax and logic errors to help mitigate problems before they happen.

	## Pair programming shouldn't feel confining
	* Pair programming is often a seamless experience. You might be coding solo for a little while and reach a point where you are either stuck or just need someone to bounce ideas off of. You can try the [rubber duck problem solving method](http://blog.codinghorror.com/rubber-duck-problem-solving/) to help solve your problem, but even then, it might be more effective to have another set of eyes on the problem. At this point, it might make sense to ask someone to pair with you so you can explain your code and potentially get new solutions to your current problems that may not have come to you directly. When pairing goes right, you'll know it, because it will feel right and ultimately you should see yourselves working through problems efficiently, and finding a balanced workflow that includes steady verbal communication and verbally working through problems. You are solving problems as well as increasing your own understanding, so those problems are not problems anymore and make sense.

	## Common pairing problems:
	* Problem: How do I ask for someone to pair with me?
	* Simply put, you should try asking your partner or someone you want to pair with "are you busy right now? Would it be possible to pair on this problem, I could use another set of eyes" and, if your partner is free, you can start working on the problem. It is paramount that no one "hogs" the keyboard or the role as decision-maker. To be truly effective, pairing has to be a collaborative effort--the dialog will only help to work through problems better, even when one pair is more or less advanced than the other. Dialogue does involve trying to ask good questions of each other, and turning those inquiries into actions whether research queries or typing code.
	* Problem: Pairing doesn't seem to work for me...
	* Often beginners are at a loss about how to pair effectively. Some of this will come with practice. Make sure you've given pairing a fair shot and tried a sufficiently diverse amount of pairs before you give up on it.
	* If, after attempting to pair for a while, you determine that you truly do work most effectively without others working with you directly, it is totally OK. You will still probably find it highly beneficial to have a classmate or your mentor to review your code after its been written to see if there is room for improvement. You will most likely have questions about concepts you have encountered and about the decisions and trade offs you are making about coding something a particular. That is still pairing to work through those questions together, since it will often involved two minds talking through some code.


	## Wrap-up
	At the end of the day, pair programming should benefit you. If it isn't, ask yourself "why?" Did you feel communication wasn't very strong? Did you feel it was a problem with you, or do you think it was a problem with your partner? Do you find yourself encountering the same issues every time you pair?

	Feel free to ask one of the instructors about some of the issues you're running into, and see if they have any advice for how to pair more effectively. Remember, the instructors have dealt with many groups of students who had no experience pairing, and they have probably encountered the same problems you're running into more than a few times by now--they may have some insight into the problems you're facing.

	Good luck and happy pairing!