Introduction
“Drive and Navigator” is a pedagogical technique that is utilised across a variety of different subject areas to support students in their understanding of a concept or topic by forcing them to either explain their own knowledge, or experience the knowledge of another in order to complete a task. But specifically, one student (the driver) can operate the mouse and keyboard but can only click/type exactly what student B (the navigator) has told them to.
It is a technique that is suggested for use in the delivery of introductory lessons in Python at key stage three to help secure understanding of the basic concepts of sequence, selection, and iteration however I have begun to experiment with its application in T-Level Computing practical activities. Specifically, practicals that they will undertake as part of their occupational specialism assessments this year.
The Occupational Specialism Assessments
One of the things I love above delivering the T-Level Computing qualification is the practical assessment that does at some level simulate parts of the role of a Windows system administrator. It requires students to demonstrate an understanding of some key concepts that Windows infrastructures are built upon such as, but not limited to:
- Creating and designing a small network topology, with IP schedule, planning timeline, and rationalisation for their decisions.
- Windows Server and Windows 10/11 Installation.
- Assigning static IP addresses where necessary.
- Installing and configuring DHCP, DNS, Active Directory Domain Services, and Windows Deployment Services.
- Capturing and re-deploying a Windows image over the network.
- Documenting all of their process, with relevant justifications for their choices.
For me personally coming from a background in secondary education where all of the focus was on good old Computer Science, which to this day produces images in my head of people in white lab coats tinkering with a supercomputer, this type of assessment blew my mind.
All of the things that I’d previously pushed aside with teaching Computing in secondary, such as even basic things like setting up static IP addresses, where part of the core assessment and a requirement for students to complete. And now we are in an interesting period of reform in the space of digital T-Level qualifications with the transition from NCFE to Pearson.
The Driver and Navigator
Driver and navigator has taken many different forms across the curriculum and has been reshaped in different subject areas into quite different pedagogical techniques. In Computing, the National Centre for Computing Education (herein NCCE) suggested the use of driver and navigator be applied to learning to code. The key element that makes driver and navigator a successful pedagogical technique is that it focuses on reducing the cognitive load of both learners and enables them to make focused decisions specifically relating to their role. The driver focuses explicitly on the process that is occurring in front of them, taking in each step in detail but not having to make the considerations for the next steps. While the navigator is spending their time focusing on the task, process, and next steps that must be undertake to achieve the goal.
In the case of the occupational specialism assessments that I am currently working on preparations for with my class, I’ve found that for short controlled sections of practice that driver and navigator has been incredibly effective. It has helped my stronger students cement their understanding and consider how to exactly guide another person to complete the steps required, further solidifying their own knowledge (Vygotsky, 1978). This in turn gives them a head start when thinking about how they are going to document the process when the time comes for them to do so during their assessment.
Meanwhile, learners with a weaker practical understanding of the process receive guidance from a more confident student allowing them to just focus on the issues of what to click and what to do next, over time these processes become more familiar and the student grows in confidence when tackling these complex tasks.
For some of these students who are in their first year of the T-Level DSS qualification, they may have never seen the Network Connections menu in Windows prior to starting the course, let alone configuring Active Directory and Windows Deployment Services in six months. So the process of getting to grips with Windows Server is something I have been doing with students since around the forth week of the course way back in September 2024.
There are two things that I have found that can be a challenge when running practical sessions in this paired manner. Firstly, it only works well for sections of the practical tasks. If the practical task becomes to long, the students can start wain in their separate roles and begin working directly with one another. This runs the risk of one of the learners missing a step or not necessarily understanding the thought process of their partner while they are clicking if they start thinking for themselves.
Identifiable Victim Effect
An additional thought that came to me regarding how the ‘Driver and Navigator’ process lessens cognitive load was based on the identifiable victim effect.
The identifiable victim effect is the tendency for individuals to offer more support when a specific, identifiable person (the ‘victim’) is observed experiencing difficulties, compared to when a larger, more abstract group is facing the same problem (Jenni & Loewenstein, 1997).
In the context of the ‘Driver and Navigator’ technique, the identifiable victim effect can manifest in interesting ways. The navigator, who provides the specific instructions, can be seen as the ‘identifiable agent’ directly responsible for the actions taken, even though they are not physically performing them. Conversely, the driver, who is simply following the navigator’s commands, is more akin to an ‘identifiable victim’ – they are not the one making the decisions, but could be seen as the one who directly experiences the consequences if things go wrong.
This delegation of roles means the navigator may be more willing to execute actions or decisions they are unsure about, since they are not the one physically carrying them out. The driver may feel less accountable and more willing to follow the navigator’s instructions, even if they result in negative outcomes, as the driver did not make the decisions that led to those outcomes.
An interesting dynamic forms in this paired activity and can serve as an interesting learning opportunity. If the student in the navigator role is not confident in their skills, it allows them a way to be able to experiment without the pressure of failure falling directly on them, and in the driving role it allows them to strengthen their understanding while building their own self-awareness of areas of weakness that can be taken forward of a point to focus on when revising. For the class as a whole, I feel that through group activities the bonds between students and level of technical communication is also improving. the language being used is moving into the territory of what one could expect in an business environment. As this terminology works its way into their wider vocabulary, it also unlocks the potential to gain marks in the assessments later down the line.
Considerations in Practice
There are two key points to consider when applying driver and navigator style activities in a practical session: appropriate pairings, duration/timings of switching of roles. I’ve run several of these sessions at this point, the second session of which was less successful due to a couple of unbalanced pairings in my group.
Running based on a clock just won’t work. This is viable when applied in a programming environment as originally suggested by NCCE (2019), but in a process when the students will be undertaking a certain amount of waiting for the installer to finish, which varies based on their lab machines, I find it better to swap student pairings ad-hoc based while monitoring their progress through each of the setup stages. I do find that due to the time of a swap being unpredictable to students, the level of focus is much higher and there are a lot less phones out during the practical phase.
Pairings is also incredibly important, I’ve tried running these sessions with completely randomly generated pairs as well as specifically selected pairings based on attainment. Unsurprising the results from randomly generated pairs varied wildly. Some pairings completely ripped through the practical and made excellent progress while others struggled to get out of the starting gates at times and felt completely lost. Through careful planning of the groups however, learners that had previously struggled to access the practical content are able to follow the guidance of an experienced student and learn how each stage of a progress supports the next, an especially important concept when working with AD DS, DNS, DHCP, and WDS.
Conclusion
Throughout the occupational specialism drills that I’ve been running over the last couple of months, the driver and navigator pairing techniques has proven successful in certain scenarios in the T-Level Computing classroom. As with all pair work, to be effective it must be carefully planned and considerations given to pairings, ensuring fair division of responsibility in the pair, and accountability for progress for you as the teacher/lecturer to fairly assess the progress each member of the pair has made.
It is a techniques that I will continue to deploy, at first students found it quite entertaining as a way of undertaking their practical drills but as time has passed, I have had students feedback that they feel the progress that they’ve made from a session is greater than progress that they have experienced from working alone on their tasks.
References
Jenni, K. and Loewenstein, G. (1997). Explaining the ‘Identifiable Victim Effect’. Journal of Risk and Uncertainty, [online] 14, pp.235–257. Available at: https://www.cmu.edu/dietrich/sds/docs/loewenstein/identifiableVictim.PDF.
NCCE (2019). *Quick Read: Using pair programming to support learners *. [online] Teach Computing. Available at: https://teachcomputing.org/blog/quick-read-pair-programming-supports-learners[Accessed 10th February 2025].
Vygotsky, L. (1978). Mind in Society. by L. S. Vygotsky. Harvard University Press: London. 1981. Psychological Medicine, 11(04), p.866. doi:https://doi.org/10.1017/s0033291700041507.
Leave a Reply