For the last couple of years I've been doing sporadic teaching of electronics and programming for undergraduates and masters students across a couple of courses in my local university. This follows on from teaching we've done in primary schools, for teachers and more recently with families, and has taken the form of one on one teaching a day a week in the spring term, in a basement cupboard sized room with a soldering iron and piles of components. Students book up half an hour blocks of time to get help with their projects, find new directions or assistance developing new ideas they continually come up with.
As it's been relatively free-form and entirely driven by the students, it's been a fascinating experience. I've not really been able to predict from moment to moment what we are going to be working on - from building the right circuit to string together a load of LEDs, to analogue filter design, or programming a state machine to handle sensor input for an Arduino project.
It's also raised a lot of questions about technology and how it should or can be taught effectively. As each student is different, I get a lot of chances to try alternative ways of approaching the same subjects, and can gradually tailor the work to how they are responding individually to problems.
One significant thing that has happened during the time I have been doing this is that the "Codeclub" generation have entered university. On the one hand, given the amount of energy and money we have all piled into these initiatives, the gaps in their initial understanding feel downheartening. On the other, it is at least encouraging to show them Scratch and have them remember it with a sense of nostalgia and feel comfortable - and amazed what you can do with it when you add a bit of your own electronics.
I've collected a few observations and techniques I've developed in order to get them written down and a chance for me to think about all this a bit more outside of the crazy day to day rush of this kind of teaching.
From the notebook: Trying to plot LED brightness against voltage
You can do a lot in half an hour
Originally I thought half an hour was way too short to get anything done and while it is a challenge in some cases depending on the project, over a few months the more dedicated ones that keep plugging away at it can go from a primarily "consumer" situation (sometimes with unrealistic ambitions!) to confidently soldering and programming their own Arduino projects and needing very little extra help from me.
Top down or bottom up
There are people that when given a load of example code or an existing circuit can quite cheerfully hack away at it to make it their own by doing what they want, or just something different. These people are happy changing numbers, copy pasting code and getting a feel for how things work from the 'top down'. They treat technology as a raw material, something almost to be treated as a natural process to be slowly explored and discovered (see circuit bending below).
Then there are other people who need to understand more clearly what is going to happen before changing something, where the first feeling is "there is no way I will ever understand all this". They need to know some principles first, some physics for voltage and current, possibly a historical explanation of why programming languages work the way they do. These people get a huge amount of joy when they reach a true understanding of a fundamental process - e.g. a voltage divider or a for loop.
One of the most important things is to work out is which type of person has just walked in as quickly as possible, because the first get bored quickly by explanations and the second a rising sense of panic when given too much to chew on.
From the notebook: An attempt at stacking potentiometers
Programming culture is the main problem with programming
I think a primary issue with code is that the kind of people who like to explain it tend to think it has something to do with engineering, or an expression of a deeply objective scientific method. It seems to me that it has far more resemblance to a cargo-cult like set of cultural trends, riven with changing fashions, competing tribes and decisions based on hunches with no real evidence about anything at all. It is this of course that makes programming interesting and possible to poke fun at and celebrate in equal measure - and it seems you get further by teaching it based on this reality.
Draw diagrams instead of code
The basic activity of programming is designing a process. There is no particular need to have a process described and notated in code, therefore a good approach with someone with no prior experience in programming seems to be to suggest drawing a diagram to explain what they want to do.
This results in a couple of interesting things, the first is to observe 'how' they decide to draw the diagram - sometimes this can be a very quick abstract sketch, other times a fully worked out sequence that includes lots of extra information. This can tell you a lot about how they think and what is the right path forward for them.
However they do it, the essential thing is for them is to approach a good understanding of what they are actually trying to do by having to think through all the nitty gritty details. A lot of people who have been writing code for ages can (or at least try) do this directly in a programming language - but this is too much to start with, and certainly too much to try and explain. It's better to go through this discovery process in someone's own invented notation system, so you can start to ask questions like "what happens when these two buttons are pressed at once?", "do you need an indicator LED for this situation?" or "are you sure you really need to do this in VR?".
Once all these questions have been answered and notated, the programming has actually been done - in some cases it's then a quick and trivial task to convert these decisions into C++ for an Arduino to execute. You can for example keep the naming consistent with their diagram so they can understand and modify it later on.
From the notebook: Not a morse code device, but working out how a child's sensory toy should work.
Books are the future
I have some old books on electronics I like to take with me. It seemed a bit pointless to start with, but then the internet stopped working for a day, and it felt pretty amazing that basically everything we were trying to do was there in paper form, more easily searchable and better explained. We started using them a lot more after this, particularly for analogue electronics.
Programming makes more sense as an extension of soldering
As hinted by NAND to Tetris, there is something liberating about starting from the standpoint of "all we have are pins that are either 0 or 5 volts". We can talk about how this is all any computers ever understand, and is the same with all digital "tech" - everything else is involved with getting the outside world represented by these two voltages, or affecting the world using them.
Once we are building hardware circuits that go in either direction from these pins, it somehow takes a lot of the mystery out of programming - perhaps because you are in control of what your program 'sees', there is less magic there and it becomes clearer what is really going on. Somehow the world ceases to revolve around the code, which just becomes part of a whole.
We also had some funny discussions about transistors (usually while using them as simple motor drivers) - how a simple electrical switch has become the basis for how society organises itself and how this has changed everything. All of this is an attempt to demystify contemporary technology and provide confidence in making and adapting it.
Circuit bending
For some reason, this year circuit bending was all the rage. We mainly circuit bent kids keyboards, motorised toys and old cheap video mixers. This technique is really the pinnacle of the 'top down' thinking - take an existing artifact we don't understand and figure out how it works by doing things you are not supposed to do to it, like connecting random printed circuit board tracks to each other. This sometimes involved very challenging SMD soldering, for example to remove minuscule pitch resistors and replace them with light sensors to make light theremins. Recordings can be made during the bending process to capture fleeting results that maybe won't be able to be replicated - here the recordings themselves can be the main result. Once devices have been well and truly hacked to become personal instruments, they can then be decorated and painted to become almost but not quite unrecognisable from their origins. Circuit bending also naturally leads to construction of new breakout boxes for adding new hardware, or routing the signal from one bent instrument to another to combine them together.
The analogue video mixers were particularly interesting as they could be bought very cheaply online - and we had quite a range to explore. The oldest was entirely constructed from hand soldered passive components and transistors, later models used common integrated circuits, but were just as 'bendable'. They were all low power, and we could use a cheap USB TV card to see results on a Raspberry Pi rather than driving a potentially dangerous CRT screen.
From the notebook: More potentiometer trickiness
Analogue bubblebaths
There is a common situation with Arduino or Raspberry Pi where they are automatically used as solutions for problems. For example using a Raspberry Pi's 1.5 GHz 64-bit quad-core processor to turn on a light when a switch is pressed is a commonly typical example of over-engineering that understandably comes from a lack of confidence with the raw materials.
For a surprising range of projects, analogue electronics not only does the job, but leads to far more interesting situations to arise. A classic case of this is audio, where using a computer to make sound is unusually awkward to learn in comparison to how easily you can build an oscillator and filter with a couple of components on a breadboard.
There is definitely a point at which certain requirements for creative control and decision making means the leap to software is appropriate, but keeping to electrons alone is more appropriate for students who prefer a creative process of exploration with exploitation of chance discoveries.
Some conclusions
This teaching has taught me how important places like Adafruit and Pimoroni are, where components are documented properly, and explained well and in context - this is a clear case where diversity and the different perspective it brings benefits us all. It seems the Arduino IDE is the cause of more problems than it really solves (the error messages mainly, confusion with serial ports and needing to back up code), and how everybody learns everything from YouTube. Along with circuit bending I've tried to stress using recycled e-waste and reclaiming components while underlining safety at the same time.
We've also been developing a workshop format and a set of parts that we can roll out easily for half day courses to get people up and running, or at least an initial familiarity with this technology. I hope to write more on this soon, but it seems a key factor when you are going to students rather than them coming to you is explaining why this knowledge will be useful for them, even if they do not plan to become an "expert" in any of it. Another important factor in all of this is providing context in the form of interesting projects and applications - of course FoAM Kernow provides plenty of these, so I've been able to smuggle in the Viruscraft virus and Penelopean swarm robots to provide some distractions.
I've tried to keep track of what we have done on this github repo, with useful code, schematics, pinouts and a gradually expanding wiki.