When doing LetTheJuniorDrive, there are possibilities that the PairProgramming won't work right, as listed in LetTheJuniorDrive. If there is PairMismatch, be careful lest it be a one-way lecture or exam to the junior.

'''Therefore'''

DialogueWhilePairProgramming so that both the pair should proactively participate during PairProgramming. Whenever you feel like you are lecturing the junior, try to dialogue rather than to lecture.

When it's in lecture form, it may benefit the junior somehow (but not very much if it's done in an overbearing manner), yet it's of not much benefit to the senior or the entire group in a cost-efficiency way. In fact, dialoguing in DialogueWhilePairProgramming is not primarily for pedagogical purposes. It's for the pair to work efficiently and effectively, and benefit the whole group in a cost-efficiency way.

When DialogueWhilePairProgramming is being done, there is no dominant driver -- neither the junior nor the senior. Any one of the pair who has more clue on the bit of the task hold the keyboard and drive. Don't think about teaching the junior. Just concentrate on driving. Of course, it's more likely that the driver would be the senior -- but not always as the junior knows better about what he/she can't understand and what is more understandable from his/her POV. So the pair's overall speed is higher than in LetTheJuniorDrive. But it overcomes the disadvantages of expert monopolizing (such as the junior having nothing to do but watching and not learning anything, thus remaining as "junior" permanently) the keyboard by dialogue.

Junior feels free to ask questions, and when asked, the senior notices that he/she failed to let the code communicate, and dialogue with the junior to find out which part failed to reveal the intention. As the senior refactors the code in collaboration with the junior and the junior understands the code more, the two sides move toward each other to meet at some balancing point and RecordYourCommunicationInTheCode. (when you two are trying to RecordYourCommunicationInTheCode, you guys will naturally be dialoguing since communication requires two parties participate actively)

As the result of DialogueWhilePairProgramming, the junior has learned implicitly and constructively (see also ConstructivismInPedagogy) with comprehensible inputs (as from the linguist Krashen's theory) rather than through one-way lecture ignoring his competency, and the senior has learned which part of his/her code fails to reveal/communicate the intention clearly and worked with the junior to refactor it. Consequently, the pair has filled the hole and the followers will no longer get trapped in the hole as they did RecordYourCommunicationInTheCode.

The reason this doesn't become yet another lecture is that the junior has something to do other than listening to and watching the expert. Junior has to explain to the senior what he/she can't understand and what is more understandable, and what part of the code fails to communicate. And the senior asks and anwsers -- he/she should listen to the junior! When the senior doesn't understand the junior, the junior grabs the keyboard and explains with code (natural language sometimes is not clear enough). It's intercommunicative.

Above is what I found from many observations and first-hand experiences with juniors, even from one who doesn't understand the syntax of a language, to one who has reasonable knowledge in other parts but is weak on the task at hand. When I first met PairProgramming, I tried to LetTheJuniorDrive when there was PairMismatch but before long I found out that it doesn't work as I expected. So I, incrementally, changed the method and tried this and that, and finally came up with DialogueWhilePairProgramming. I'm happy with it whether or not I'm with a junior, because I learn something, and he/she learns something, and we contribute to the future travellers (from RecordYourCommunicationInTheCode).

--JuneKim