<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Pair Programming: The Non Driving Pair</title>
	<atom:link href="http://www.markhneedham.com/blog/2008/02/14/pair-programming-the-non-driving-pair/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.markhneedham.com/blog/2008/02/14/pair-programming-the-non-driving-pair/</link>
	<description>Thoughts on Software Development</description>
	<lastBuildDate>Wed, 17 Mar 2010 23:38:45 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Pair Programming: It&#8217;s not about equal keyboard time at Mark Needham</title>
		<link>http://www.markhneedham.com/blog/2008/02/14/pair-programming-the-non-driving-pair/comment-page-1/#comment-17476</link>
		<dc:creator>Pair Programming: It&#8217;s not about equal keyboard time at Mark Needham</dc:creator>
		<pubDate>Sat, 23 May 2009 06:39:55 +0000</pubDate>
		<guid isPermaLink="false">http://markhneedham.wordpress.com/?p=27#comment-17476</guid>
		<description>[...] role of the navigator shouldn&#039;t be underestimated as when it&#039;s done well it provides a very good complement to the person [...]</description>
		<content:encoded><![CDATA[<p>[...] role of the navigator shouldn't be underestimated as when it's done well it provides a very good complement to the person [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pair Programming: The Over Eager Driver at Mark Needham</title>
		<link>http://www.markhneedham.com/blog/2008/02/14/pair-programming-the-non-driving-pair/comment-page-1/#comment-1143</link>
		<dc:creator>Pair Programming: The Over Eager Driver at Mark Needham</dc:creator>
		<pubDate>Wed, 05 Nov 2008 13:50:37 +0000</pubDate>
		<guid isPermaLink="false">http://markhneedham.wordpress.com/?p=27#comment-1143</guid>
		<description>[...] When navigating it often feels that you are not adding value and it sometimes becomes confusing as to exactly what you should be doing. [...]</description>
		<content:encoded><![CDATA[<p>[...] When navigating it often feels that you are not adding value and it sometimes becomes confusing as to exactly what you should be doing. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Apurv</title>
		<link>http://www.markhneedham.com/blog/2008/02/14/pair-programming-the-non-driving-pair/comment-page-1/#comment-7</link>
		<dc:creator>Apurv</dc:creator>
		<pubDate>Sun, 17 Feb 2008 19:03:33 +0000</pubDate>
		<guid isPermaLink="false">http://markhneedham.wordpress.com/?p=27#comment-7</guid>
		<description>I was in a peculiar problem and ThoughtWorks University last week. It was my first week and I came up with a problem. How do you involve a person in the whole process of estimating. If a person is not giving his ideas, feedback and gives only when asked this question &quot;what do you think about this?&quot;. How to cope with this, do the safety check more often, keep asking the questions or talk to person outside.

What if somebody is feeling isolated? How as a developer I can make him/her a better part of the team. These are some of the questions that came up during the Lego Game at  TWU.</description>
		<content:encoded><![CDATA[<p>I was in a peculiar problem and ThoughtWorks University last week. It was my first week and I came up with a problem. How do you involve a person in the whole process of estimating. If a person is not giving his ideas, feedback and gives only when asked this question "what do you think about this?". How to cope with this, do the safety check more often, keep asking the questions or talk to person outside.</p>
<p>What if somebody is feeling isolated? How as a developer I can make him/her a better part of the team. These are some of the questions that came up during the Lego Game at  TWU.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pat</title>
		<link>http://www.markhneedham.com/blog/2008/02/14/pair-programming-the-non-driving-pair/comment-page-1/#comment-6</link>
		<dc:creator>Pat</dc:creator>
		<pubDate>Thu, 14 Feb 2008 21:46:29 +0000</pubDate>
		<guid isPermaLink="false">http://markhneedham.wordpress.com/?p=27#comment-6</guid>
		<description>See if you can track down a copy of Pair Programming Illuminated. It describes different styles of pairs working together and when pairing works against instead of for.

I have a few suggestions for improving your skill as a &quot;navigator&quot; (another name given to the person not actively coding).

Rather than just dive into the tiny tasks - have that design discussion with your pair about what is the best way of approaching whatever you&#039;re working on. A result of this might be tiny tasks. If it&#039;s straightforward, then you can simply review the tiny tasks.

When you&#039;re not driving I find it&#039;s useful to step back and ask a few questions to myself. Is the testing strategy right? Is there excessive duplication? Would some other person come along and find this difficult to follow? Does it look consistent with the way the rest of the application? Are there more tiny tasks to find and add to the pile?

One other thing I find useful to do when acting as a navigator is to share tips around the workspace such as keyboard shortcuts, various tools (I see you do this - did you know you could do it quicker if you used x?).

If you don&#039;t find yourself adding value or if your pair doesn&#039;t feel like you&#039;re adding value then maybe you should reduce the amount of pair programming time.</description>
		<content:encoded><![CDATA[<p>See if you can track down a copy of Pair Programming Illuminated. It describes different styles of pairs working together and when pairing works against instead of for.</p>
<p>I have a few suggestions for improving your skill as a "navigator" (another name given to the person not actively coding).</p>
<p>Rather than just dive into the tiny tasks &#8211; have that design discussion with your pair about what is the best way of approaching whatever you're working on. A result of this might be tiny tasks. If it's straightforward, then you can simply review the tiny tasks.</p>
<p>When you're not driving I find it's useful to step back and ask a few questions to myself. Is the testing strategy right? Is there excessive duplication? Would some other person come along and find this difficult to follow? Does it look consistent with the way the rest of the application? Are there more tiny tasks to find and add to the pile?</p>
<p>One other thing I find useful to do when acting as a navigator is to share tips around the workspace such as keyboard shortcuts, various tools (I see you do this &#8211; did you know you could do it quicker if you used x?).</p>
<p>If you don't find yourself adding value or if your pair doesn't feel like you're adding value then maybe you should reduce the amount of pair programming time.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
