Its not a huge surprise I haven’t written anything here since my change of direction to become software developer. A friend from primary school contacted me recently as he was about to start a code club. He had gleaned form my various fb posts that I have spent some time teaching programming and wondered if I had an advice. I wrote a massive, sprawling email, then deleted it and tried to write a list. As with most things (here) it is a work in progress, if you can add to it or refine it please do.
Teaching is probably one of the most important things we can do. Our capacity to accumulate and share wisdom that transcends generations is a defining feature of us as a species. To teach is to learn twice (Joseph Joubert) and to do it well can have the most profound impact.
(1) Prepare and Practice:
This seems obvious but is really important and worth underscoring. Knowing your material makes everything much more pleasant. The old adage “fail to prepare, prepare to fail” rings true. You don’t have to exhaustively commit it to memory but an outline of where your time is going to go is very helpful.
Spin over what you plan to do and identify any things that will go wrong. Then when you do it with learners, let the things go wrong and recover with your learners. Knowing how to get of trouble is one of the most valuable programming skills.
I remember on my first gig in Orkney taking wee Arduino robots in to classrooms I really painted my self into a corner and it had nothing to do with programming. I asked the question: “So you can use decimals for your time delay between instruction if you want. Have you all done decimals?”. They replied:“no” I then proceeded to give a very sketch off the cuff description of what decimals are and how they could be used for my robots. In an ideal world I should have known this before I went in to the class room. Though spotting the situation and backing out rather than giving a ill-prepared description of a topic that is carefully covered over a long period of time would have been fine. (Closed questions that can be handled with a yes or know are also not good, much better to invite a explanation or description of what X is and leave enough time for someone to speak up)
Every educator has experience that painful moment when you are on superb form, flowing eloquently through the nuance and complexity of your topic and you energetic delivery is met by growing numbers of blank gazes. Being prepared knowing your audience and engaging them with open questions (can any one tell me what a decimal is?) and giving them space to reflect on their understanding will help ensure the pace of the learning experience matches the pace of the learners.
(2) The Expert Novice Match Mis Match:
It seems logical and quite sensible to learn from an expert this can present some problems. One of the biggest challenges in teaching is to put yourself in the shoes of the learner.You need to be able to unpack tacit knowledge you take for granted and really peal back the layers to expose this knowledge. Being able to zoom in on a what is to you a simple concept and find a variety of way of building up to understanding is valuable skill.
A variable is a great example. Its one of the fundamental building block of programming how would you introduce it to a learner? When there is no supporting knowledge around the concept you are trying to teach it become a bit like trying to describe a flavour without referring to other flavours (or difficult!) The closer you look the more subtle and nuanced it becomes. Most common analogies begin to break down and that is fine as long as there limitations re known. Giving the learner the amount of detail they need and are motivated to receive is a tricky balance to strike.
Education is a subtle complex dance of communication and shared discovery and is inherently error prone. You will at some point not know something, get it wrong or have to back up a bit and take a different tack on your current line of attack. Humility and accepting and showing (to your learners) when things go wrong is the first step to fixing them. Programming is inherently error prone too and getting young learners to see that is important. Preparation can help control when things go wrong, but presenting a polished error free programming experience i selling them a half truth. A fair amount of my day job involves figuring out why stuff isn’t working rather than writing new stuff. The educator is guide not gate keeper, fallible and requires the courage to recover from mistakes publicly. I still remember a teacher whose pride forced them to argue tooth and nail that balsa wood was a hard wood to save face.
(4) Ceilidh or Disco: Structure vs Freedom
This is all about structure and the rules of engagement. As with most of these points its about balance and judgment, not a is bette than b. Ceilidh’s (I would argue) are generally less intimidating to the novice dancer as the dance moves are well defined and often ran through by the band prior to the commencement of the dance. At the other end of the spectrum in a disco there is music and total creative freedom which is great if you know what you are doing but intimidating if not. The same is true for a learning experience. If a topic is new to learners it probably wise to err on the side of well structured and well defined tasks. As the ability and competence increases less structure and more creative freedom will be required to continue engagement.
(5) Inspire & Underpinning
I recon we under use the inspiration in engineering in general. Its no good looking at fantastically complex systems that a learner has no chance of getting anyway near to building. There is merit in understanding where the thing we are doing has come from, I bet you can name 5 famous physicist quicker than you can computer scientists or software engineers.
It is however possible use inspiration to drive motivation and in turn learning. One of computing best kept secrets is the capacity for complexity to grow or emerge out of simple algorithms. When you follow these simple steps look what happens. Light following robots are a good example of this. I have a hunch that particles systems in Processing may provide a similarly complex behaviour that could provoke a learner to peel back the layers and work through the processes to achieve the complex behaviours. A superb route to learn about arrays and objects.
(6) Small Deliverable Goals
This is good practice in commercial dev as much as it is in a learning situation. The investment and reward cycle needs to be quite tight. It is often banded about that in an undergraduate lecture students are switched on for around the first 25 minutes and the last five minutes of a lecture. The best approach to avoid this is to structure you sessions around relatively small time blocks. With a shift in delivery modality or small disruptive activity between each chunk. In robot dance the target was for a time to first task of 10 minutes. We were able to get from hello my name is … through a bit of back story and to making the robot move in 10 minutes. The works flow form then on had a similar time frame. Code a bit, upload, test repeat. In the same fashion that small deliverables allow commercial dev to be agile and shift focus as needed, small deliverables in an education setting giving the learner constant feed back in progress and allows the educator to be flexible in their delivery. If you find your self with an extra 10 minutes there may be something additional you can pull in.
(7) Books and Movies: Expectations and Reality
This is the final point and a good one to finish on. When ever we invest time in any creative act we build our own perception of it and how it will play out and what will be. This fails to acknowledge that when the plan is enacted there is a bunch of random put into the mix in the form of your learners. What felt like a splendid concept chain in planning may fall on its face when tried out. On the flip side you may be surprised that a relatively benign section of your plan played out to be really interesting. In every case the reality of any plan in action will differ from your perception of how it was in your head. The important thing is to be comfortable with failure. Not cavalier, reflect on where things went wrong and tweak and improve as you move forward but remember if you think everything is going perfectly you probably aren’t looking hard enough, or stretching yourself. There are no codebases with no bugs, just code bases with undiscovered bugs.
“don’t apologise, learn” (~Justin the knight)