Lecturing Using Pair Programming


We use a didactic form of pair programming in our large lecture courses. The instructor is the driver, while the class as a whole (from 40 to 180 students) works together as the second member of the pair programming team, which we call the navigator. A typical scenario, used from beginning to advanced courses, is outlined in the following two sections. First we explain the process from a student view; then we elaborate on the process from a faculty developer perspective.

Student View

  • A problem is posed that requires a programming solution. The problem and its solution are intended to illustrate features of a programming language, elements of software design, and principles of computer science and to engage students in the process.

  • A preliminary, partially developed program is given as the first step to the solution. Students read the program and ask questions about it as a program and a potential solution.

  • The instructor displays the program on a projection screen visible to the class (each student has a written copy) and adds functionality with input from the class. This involves writing code, writing tests, and running and debugging the program. The instructor drives the process, but the class contributes with ideas, code, and questions.

  • The final program is added to the day's Web site for reflection and completeness and for those students unable to attend class. Both the initial and final programs are part of the materials available to students.

We have tried a variety of standard active-learning techniques in this form of pair programming: calling on random students to contribute, breaking the class into small groups to provide solutions, and making pre- and post-class-work questions based on the programming problem.

Educator View

The instructor who drives a programming problem and solution must develop a complete solution beforehand and then refactor the solution into one that meets the needs of the instructional process as described in the previous section. This process may take more preparation time and require more responsibility from the instructor during class time than a traditional lecture.

  • The instructor finds a problem and develops a complete program/solution to the problem. The solution is developed using XP, but the goal is a simple, working program, which isn't always the right instructional tool.

  • The program must be refactored until it is simple enough to be understood by the student client while still achieving the intended didactic goals. This simplification process is often easier in introductory courses because the programs are smaller. In some cases, especially in more advanced courses, a problem and its solution must often be completely reworked or thrown out when they're too complex to be used in a one-hour lecture.

  • Parts of the program are then removed so the program can be completed as part of an instructor/class pair programming exercise. The instructor has an idea of what the solution could be, but the solution developed during class isn't always the one the instructor pared away. Instructors must be comfortable with accepting and using student input, going down knowingly false trails for instructional purposes.



Extreme Programming Perspectives
Extreme Programming Perspectives
ISBN: 0201770059
EAN: 2147483647
Year: 2005
Pages: 445

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net