Up until this lesson, we taught how to fix faults that were very evident, like broken screens and dead batteries, so we did not have the opportunity to experience fault-finding.
But many repairs are not so straight-forward. We were rather nervous about this session – partly because over the years working with adults, what we’ve learned is that it is very difficult to teach fault-finding, except in the context of extended practice at repair. Given we have one hour per session, and we wanted to ensure that students had a taste of success, we gave this session quite a bit of thought.
We started by explaining that fault-finding is often the greatest hurdle in a repair. Once we’ve identified what is wrong with something, often times a fix is just a matter of procuring parts, getting the right tools and carefully following a series of steps. But it’s the mystery of a fault that often stands between us and a successful repair.
We walked students through the need to methodically collect evidence, basing our slides on our Wiki post. We did some demos of a visual inspection (with a corroded laptop motherboard), passive (continuity and voltage testing with a multimeter, using fuses and batteries) and functional testing.
We talked about how it often helps to narrate or elaborate one’s thought process, and how collaboration and skill-sharing is an essential part of fault-finding.
Then we asked students to fault-find with game controllers, headphones (brought by students), an old multimeter, and a computer mouse. (It was a real struggle to get students to bring broken stuff, even though they have it at home – this collection we hope to solve in other schools by making a clear call out, well in advance, for a wish-list of broken items.)
In the fault-finding exercise, students were asked to take notes on their evidence-gathering process, and share their conclusions with the group. This worked quite well! Students were able to explain their process – they had really picked up on the different kinds of evidence gathering.
There really was not adequate time to actually fix any of the items, and we would definitely suggest this session has the possibility of being extended beyond 60 minutes. We did get a chance to start talking about hacking (using Sugru) and work-arounds, creative problem solving, which is something we will address in the next session!