Getting Ready to Teach Code: Red, Green, Refactor

Start typing “everyone should” into Google and Google wil recommend the phrase “everyone should learn to code”. Everyone from Bill Gates to Snoop Dogg are telling people that “every student in every school should have the opportunity to learn to code”. This is probably driven by the skills shortage in technology and the lack of a mainstream effort to get people involved in technology. Schools certainly don’t take computer studies as seriously as Science and Math.

Of course people can learn to code on their own but workshops/classes are a great way to introduce coding and get people interested enough to pursue further learning. There are a lot of these workshops - usually run by professionals in the software/web development field. The intention of this article is to help the wonderful professionals (with no formal training in education) who are getting ready to lead a workshop/class.

You’re a craftsperson, you know your stuff, but that doesn’t mean you’ll be an effective instructor. You might have experience presenting in front of an audience, but presenting/lecturing isn’t the same as instructing/teaching. Lecturing works to some extent, just like your first attempt at writing an algorithm might work to some extent. What makes a craftsperson is their dedication to their craft and their obsession with perfection. To be a good instructor, you need to apply the attitude of a craftsperson - something you certainly can do because you already apply it in your own line of work. One way to prepare for a workshop would be to create slides, show up, and improvise! To me this is very much like coding without writing tests first. Test-driven development (TDD) is popular for a reason: it increases the quality of the code and the coder’s productivity. I’ll be using TDD as an analogy for how to prepare and teach a lesson.

Red

Before the workshop, just like a failing test, you should plan in detail what you wish will happen during the workshop. This is your lesson plan; when you actually sit down to write what you expect to happen, you might find some surprises.

What are the learning outcomes? I.e., what do you expect that your students will learn? This should get you thinking about how realistic your expectations are. Will students be able to learn all of this in the given time?
Activity breakdown - break down everything you plan on doing along with an estimated time of completion. Try to be as realistic as possible but don’t agonize over accuracy.
Materials - make a list of software/hardware that you and students will need for the workshop. Ideally this software should be downloaded before the workshop, otherwise time will be wasted during the workshop downloading and installing.

Look at your plan and ask yourself some questions:

Is there a hook at the beginning to get people’s attention? This is your opportunity to raise the excitement level and get students a bit more motivated for the workshop. Maybe a sneak peek at the final stage of what the students will build will do the trick.
Do I give students enough time to practice what I teach? If your audience is new to programming (or the specific topic you’re teaching) you have to be careful not to overwhelm them. People are in a vulnerable situation when they’re learning something new - so they are at risk of losing their confidence very quickly. “Chunk” your lesson, i.e., after explaining a concept give your students an opportunity to try it out for themselves.
Am I addressing the learning outcomes? You have defined the learning outcomes but it’s important to make them central to your lesson. It’s good (pedagogically) to define some cornerstone concepts and then revisit them as often as possible.
Do I make opportunities for students to demonstrate their learning? If a student asks a question then avoid answering them directly - bring the question to the whole class and start a discussion. Give students an opportunity to answer their peer’s question. If you give students a few minutes to code on their own then fight the temptation to show the answer as soon as the time expires. After the coding session is over, get everyone’s attention back and have student volunteers show and explain their work/code. Explaining their work can help solidify their understanding. For the ones who had difficulties - they get a chance to hear an explanation from someone else. Peers might explain concepts in a more accessible manner than the teacher.
If I were a student, how exciting would this lesson be? Answering this question honestly will help you a great deal. If you imagine yourself being bored then chances are your students will be too. Usually just swallowing your ego and realizing that less of your “lecturing” and more hands on coding might be the solution.
Do I end the lesson by reiterating the learning outcomes? Concepts are learned by repetition, reiterate the core concepts and give students some advice for moving forward. Also, take this opportunity to get students’ feedback. An “exit card” might work well; just hand out a small piece of paper to each student and have them answer a couple of questions before they leave. “Tell me one thing you learned today” and “Make one suggestion for how this workshop could be improved” might be two good questions. The questions are worded purposefully to get students to prioritize; they are more likely to tell you the thing they learned best and your biggest weakness.

Green

Ideally you write just enough code to make the test pass (green), nothing more. The same idea applies when you’re delivering a lesson, stick to your plan as much as possible. You might need to do a bit of improvisation, but it should be minimal with a good lesson plan. As you deliver the lesson:

Don’t be distant - walk around the classroom to break the emotional and physical “barrier” between student and teacher. You’ll be better informed of how students are doing and you’ll be closer to receive questions from students. If you are presenting a slideshow then you might need a remote control (or a helping hand) so that you’re not stuck at the front.
You shouldn’t have to raise your voice - plan well in advance how long you’re going to give students to complete an exercise/activity. Communicate your expectation and it will be much easier to regain students’ attention.
If you find yourself saying “i’ll explain this later”, then stop it. There is no point in bringing up a topic without context and meaning.
Explain, don’t just show - avoid showing or copy/pasting completed code; it takes someone relatively fluent in the language to decode it on the fly. Start from scratch every time and explain each line by using the core concepts. If you run out of time, cut content out, don’t rush through it.
Don’t assume that students understand - ask questions to check for understanding.
Let students attempt to solve a question individually or in groups before showing the solution.
Observe - throughout the lesson, take every opportunity to observe your surroundings. Keep asking yourself questions like - are students getting enough time to complete exercises, what is the response to the slides, what misconceptions are students forming (if any), etc.

Refactor

After the lesson, take the time to reflect on your experience and “refactor” the lesson plan. The idea is to keep the lesson’s objectives and motives but change its implementation. Half-way through my Bachelors of Education I started to hate the word “reflect” because we had to do so much of it but I can’t deny its importance. Your first lesson plan will look different from the second because you will learn a lot the first time you implement a lesson. A lot of your assumptions will be wrong, your time estimates will be off, and your teaching strategies will improve.