'''CategoryPattern'''

'''Forces:'''
	* A senior programmer is PairProgramming with a junior programmer.
	* You want the junior programmer to learn from the senior programmer.

'''Technique:''' The junior programmer drives while the senior programmer navigates.  The senior programmer describes what needs to be done and the junior programmer does it.  The two alternate between coding tasks regularily. If necessary, Senior describes keystrokes, and Junior types them. This is for MuscleMemory, and to keep the alternating going.

Per PairPromiscuously, Senior & Junior do not need to do this very long; a couple hours is good.

When Senior thinks of an operation, she should relate it to Junior's experience on this scale:

* Senior does not know what to do next: Senior types.
* Senior knows how to explain operations to Junior: Senior sets a high level goal (such as "ExtractMethodRefactor this here, to get ready to override it") and Junior types
* Junior knows what to do next. Senior watches, refraining from interrupting over mistakes, and keeping mental track of them. 
* Get a 3-minute hourglass timer. Use it to remind pairs when to switch.

Senior operates the GoalStack.

'''Result:'''
	* The senior programmer doesn't shut out the junior programmer
	* The junior programmer learns by acting as a conduit for the senior programmer's wisdom

----

'''L''''''etTheJuniorTdd'''

For some strange reason, the schools _still_ are not teaching TestDrivenDevelopment. Give them another decade.

Until then, Senior is probably more likely to think of the next test case. She should reinforce ArrangeActAssert/AssembleActivateAssert, then sketch it like this:

 def test_frim_fram_the_frob
   #  whip out a frim test resource*
   #  whip out a fram test resource
   #  assemble them together
   #  activate their frob
   #  assert the result is what we expect
 end

The last comment is not periphrasis. Junior should replace each line with real test code (testing and integrating after each line), and then _Junior_ should try to figure out what to assert.

The point is that test cases often evert program logic, and Juniors typically have not learned to set them up. After the hard work, then figuring out what to assert reinforces Junior's mental model of the code's situation.

''* a Rails "fixture"...''

----

'''How to do it Wrong:'''

	* The senior programmer lectures the junior programmer
	* The senior programmer sits in silence waiting for the junior programmer to digest the lecture and type the correct solution
	* The senior programmer takes over the keyboard in frustration and shuts out the junior programmer
	* The junior programmer feels frustrated and doesn't learn

'''Remedies:''' 
	* DialogueWhilePairProgramming
	* PairPromiscuously
	* MostQualifiedPairsWithLeastQualified - where juniority is relative to the module at hand

'''Known Uses:'''
	* JuneKim (see anti-testimonial below)
	* DenaliProject

'''Related Discussion:'''
	* RecordYourCommunicationInTheCode
	* PairMismatch
	* PairProgrammingTipsAndTricks

'''Testimonials:'''
	* My best friend is learning to program.  I'm a relatively experienced coder -- over seven years of hobby and "real world" development.  When we Pair Program, he drives about 75% of the time, and I've found it to be a very pleasant experience.  As a result, he learns extremely quickly, and I can let him do all of the typing while I think about larger issues.  I find that the secret is '''attitude''' -- as long as the expert ''lets'' the junior drive, and both recognize what they're trying to get out of this, the experience can be extremely rewarding. -- BrentNewhall

	* Amen to Brent's "secret"! I'm working on a real project with real deadlines, with three employees who are new to OO and one other consultant - both of us experienced with heavyweight methodologies, the other guy less enthusiastic about XP and both of us new to it (see OptimisticProgrammingSkunkworks). I've found pairing with the junior guys and letting them drive most of the time very satisfying and educational for all concerned. I'm improving my teaching chops and expanding my (excuse my Zen) Buddhist calm. I started out dictating every keystroke, but as they developed the "muscular memory" of coding the language, I've been able to gradually escalate to simply mentioning higher and higher level structures - e.g., "how about a getter for that?" - and letting them start to really drive. (If I'm driving, it's harder to keep them involved, since they tend to relax and stop concentrating.) They're enjoying it and learning and so am I.  I guess if you're a poor/reluctant/impatient teacher this will be an anti-pattern for you - but so will any kind of mentoring. -- TomRossen

	* ''(Please add experienced-based reports of this pattern succeeding)''

'''Anti-testimonials:'''
	* I don't think letting someone, whether a junior or an expert, drive dominantly is good at all. From my observation and experience, while LetTheJuniorDrive was too much emphasized, it was very likely that the expert already knew the answer and watched (arms crossed) the junior if he/she was doing it right. And then the PairProgramming suddenly turns into a one-way EXAM putting much burden onto the junior. Though it might benefit the junior somehow, but what's good to the expert after all, if all he's doing was looking over and trying to score the junior, thinking he knows the right answer already? It sure is boring. 

	 :	If any side of the pair is not learning anything, the chances are they aren't doing it right. The key point in RecordYourCommunicationInTheCode is that both the pair actively participates in building up the question/answer pair into the source code, and then distilling DocumentMode version -- removing the further chance of anyone seeing the code not understand and question any bit, by improving the quality of the code during the PairProgramming. --JuneKim 

	* I HaveThisAntiPattern. When I first started PairProgramming, I recommended LetTheJuniorDrive exclusively. It was not a healthy approach -- all the bad things mentioned above happened. I'd like to see some discussion of positive ways to deal with a PairMismatch. -- JimLittle

	* Interesting, up until a couple of minutes ago (long enough to read this page), I thought LetTheJuniorDrive was the right way to go when programmers are different in their skill level. However, now that I re-examine it, I realize that it probably is an AntiPattern as suggested by this page. I've tried LetTheJuniorDrive several times and have always found that both the junior and senior programmer become frustrated and make a lot less progress than PairProgramming predicts. In my cases, the junior often sees a very different solution than the senior programmer, often overlooking opportunities for DesignPatterns, ReFactoring, and DoSimpleThings. The junior gets frustrated because they can't see where the senior is navigating to, and when they fail to make consistent progress towards this goal, the junior often gives up and says "do you want to drive?", feeling unsatisfied with progress. The senior gets frustrated because the junior makes several wrong turns (since it is difficult to communicate what the navigation goal is if the junior doesn't know what the ObserverPattern is, for example). A programming session is not the right time or place to train on fundamentals, especially if a deadline is coming up. Perhaps XP should have some provisions for external training such as BrownBagLunch (aka LunchnLearn), or after hours seminars or whatever. I ''have'' had success with PairProgramming occasionally, especially when PairProgrammingIsDoneByPeers; or, to say it more generally, PairProgrammingIsNotTraining. -- RobHarwood

	* I had been doing this for over 2 decades, and he was only a few years out of college, and we were working on the same project together. We tried PairProgramming, and I wanted to let him drive, because I had read that with a PairMismatch, the junior should drive. Also because I had driven before, and it was an uphill battle keeping him involved.

	 :	So we switched, and I ended up explaining to him things like RefactorMercilessly or how to implement IteratorPattern. I'm not complaining; I was happy to tutor him. But that's what it was, tutoring, rather than creating software. And when I was on a roll, it sometimes was frustrating because I'd have to break my train of thought in order to explain something, stammering all the way. Again, I'm not complaining, but if PairProgramming increases productivity, this ain't it.

	 :	We finally ended up working separately, I on the broader architecture, solving a problem the first time, generating reusable library code in the process; and he on implementing specific features that were variations on what we'd already done, building on what already existed. I still had to explain to him what I had done, and I still helped him from time to time understand how to extend the concepts. But we got more done this way than when we were PairProgramming.

	 :	We had much more success PairProgramming when we jointly authored a certain document. We each had similar knowledge of the domain. But we had different styles and experiences, and sitting at the same terminal, we could lever off of each other's background. Furthermore, when the driver stopped to fill in some aside, the other would regularly keep our joint train-of-thought (and thus our flow) alive. In short, it was everything PairProgramming claims to be.

	 :	My first experience with PairProgramming was many years before the practice had a name. I was collaborating on a joint project with an engineer of similar experience to my own. It was a productive and fondly remembered experience.

	 :	-- TimKing

----

Brent, is your friend just learning to program or are you working on a real project with a real deadline? I think maybe this will delineate when it is appropriate to use/not use LetTheJuniorDrive.

----

But see HowToPissOffYourPair, Guru division