How I Teach Coding - The Monolithic Approach

Every time I’d welcome a new cohort of my coding bootcamp We Got Coders, I’d give a speech about learning to code, and why we approached our learning the way we did. As part of this I’d usually baffle the audience with a somewhat obscure reference to Stanley Kubrick’s 2001: A Space Odyssey, and show the scene where an ape picks up a bone and proceeds to destroy the rest of the skeleton with it. After Strauss’s musical accompaniment builds to a glorious crescendo, the YouTube clip stops and I’m generally met with an awkward silence. Even if you’ve seen the film, taken out of context it is a striking image (forgive the pun!); but requires a bit of follow up to explain how on earth it has anything at all to do with learning to code.

The part that requires the most explanation is the shot of the imposing black monolith, who seems to have some kind of effect upon the ape. Nothing is said nor written down; but somehow an idea is imparted to that ape, a wonder: what might happen if I pick up that bone and hit something with it? His first attempts are timid, abortive. But as he gains confidence, he begins to see a more distinctive effect, which reinvigorates and encourages him to try more. By the end of the scene, he’s obliterating carcasses, felling beasts, fighting off other tribes, and several thousand years later, he’s orbiting the moon in a spaceship.

For the more cynical of my new recruits, there might have been something of a demotivating take from this; namely being likened to an ape that’s going to take thousands of years to reach modern standards of technological ability. However, I wanted instead to emphasise the more reassuring message, that everything we need in order to grow, to create and become who we want to be, we already have and already are. The monolith doesn’t teach the ape how to do anything. It doesn’t provide the benefits of self-paced, online coding courses with amazing interactive material. It just suggests a way forward. While the monolith is a towering and mysterious alien intelligence that we do not possess, we are the ones who do the work.

Hence our ape follows the age-old, tried and tested approach of trial and error. Start with a premise; test it out, learn from the experience.

Select bone => Pickup bone => Hit other bone => See what happens

What’s important about trial and error, is that it completely bypasses the notion of right and wrong, of success and failure. Whatever the hypothesis and however it was executed, there is something to learn from the experience. Even if that conclusion is never to do that ever again, that is a valuable lesson. We learn even from our failures and our mistakes. In fact it’s especially from our failures and mistakes; if we somehow fluke success in every experiment we do, there is nothing to compare the results against to know if the outcome is dependable.

“A person who never made a mistake never tried anything new.”
Albert Einstein

So the approach that I’ve always adopted for teaching coding is to be the Monolith. I provide suggestions, I am a guide. I know from experience that the direction is good, the exercise worth persuing. I know when you’ll run into obstacles and how to overcome them. One of the biggest challenges in teaching coding is knowing how to isolate a subject, so that when we sit down to learn, we can focus on one topic. Programming relies on a huge subset of presumed knowledge: how to use a keyboard or a mouse, how to use a command line shell, basic UNIX user administration, how to get on the Internet. The Monolith would have a huge task on its hands if it had to try and explain coding to an ape!

So instead I prefer to lay out a bit of theory, some ideas (see that bone over there – it can be used for hitting things with), create some programming exercises that illustrate the concept and isolate or reduce the number of irrelevant dependencies and sub tasks required in order to attempt them (try hitting things for yourself) and then leaving you an assignment to do in your own time (practice hitting bones and let me know how you get on). It’s this approach that all self-taught engineers adopt, and the one that works for many of my students.

Test Driven Development as a Teaching Tool

I didn’t learn the word pedagogy (and took longer to learn to pronounce it properly) until well after I’d established my training courses. The science of how we learn is an interesting branch of psychology and social sciences, but one that is not as well understood as many might think. There is a huge gulf of difference between how you will learn from a University, a bootcamp or on-line courses and different approaches suit difference people at different times. I don’t know anyone in the bootcamp industry who is a qualified teacher in the classic sense and many more have no teaching experience at all. Yet student outcomes for bootcamps and on-line courses is very promising.

One reason that might be is that software developers have the enormous fortune to possess an array of learning aids that they use on a daily basis, without necessarily realising it. Debugging and profiling software provides useful insight into programs, and lets their authors understand how things work by seeing the moving parts in isolation and testing their assertions. This has been perfected in the development approach known as Test Driven Development (TDD), which is industry best practice for many disciplines of software development, especially Agile development.

Knowing TDD gave me an unexpected boost at the start of my training career. Using tests to demonstrate functionality provides a great way of examining a piece of code in isolation from the rest of a program, setting up a context and all the requirements to get the program running in a simple way. By focussing on a method or function at a time, we encourage our students to break down hard problems into easier ones, which can be solved one at a time. Rather than expecting them to create their own tests, I provide repl exercises on my courses with a detailed walkthrough, which allow my students to experiment on some code and see whether their changes worked or not with instant feedback, almost like observing the effect of hitting the skeleton with the bone. Once they see results, the exercise will add more functionality, requiring further adjustment.

In this way, we frame coding as a problem solving exercise that is solved iteratively. It’s this process of feedback on gradual changes with the benefit of hindsight, rather than some divine inspiration, that supercharges the learning process and makes programming fun; all whilst learning some industry best practices along the way. After all, there were quite a few iterations between smacking a skeleton to rocketry and space flight; but this feedback loop is daily life for many developers.