Today, post PyCon conference, I spent the entire day immersed in an incredibly dynamic and educational workshop by Software Carpentry “Learn to Teach Programming“. I’m going to do a mix of dumping my notes in a play-by-play fashion with possible sidebars for commenting on what I experienced personally so that I have a record of this to look back on as I move forward with Ascend Project planning and execution.
Meet Your Neighbours
The event started off, as they always do, with a go-round of people introducing themselves in short form. As we started taking turns our teacher, Greg Wilson, asked for the person who just spoke to tap the next person to speak before sitting down. This proved to be our first of many small applications of the science behind learning and how it can play out in real life. While it apparently takes a room of kindergarten children 3 reminders to do this extra step during intros, it took this room of ~25 adults 14 requests before we mostly started doing so without prompting from Greg. By the way, during the intros I learned about Dames Making Games which I can now add to my mental list of awesome women-in-tech groups and if you’re reading this and are in Toronto, check them out!
Teaching Is Performance
It raises your adrenaline, brings out your nervousness, and it’s something you need to work at. A few quick tips from Greg on preparing for your ‘performance’ as teacher: always bring cough drops, and figure out what your ‘tell’ is. Like with poker, everyone has at least on thing they do when they are nervous. I suspect for me its likely that my ‘tell’ is talking fast and/or having trouble not smiling too much (at least in poker, it is). This was our first introduction to how we should be reflective about our teaching – even go so far as to record yourself if you can’t get honest feedback from people around you – so that you can spot these things about your manner and work on adjusting them to ‘perform’ teaching in a more confident and reliable manner.
Improv came up as a way to work on this where you can get feedback on how you perform and also learn to keep other people engaged. I used to do improv when I was an awkward teenager and didn’t feel like I was a superstar at it but I wonder what it could be like now that I have more confidence. I’ll be looking for classes in SF to try it out. What’s there to lose?
Why Don’t We Teach In Teams?
Greg pointed out how teaching, unlike music and comedy, is such a solo activity. Musicians typically build up their experience and skills by playing with others. The best comedians by and large spent a significant amount of time in some sort of comedy troupe before striking out on their own as a stand-up or as major film stars. Teachers though? Often alone in their classrooms and if my partner is an example of the ‘norm’, definitely alone while grading and preparing lessons. This is something worth exploring: what could teaching be like for the teacher if there was team teaching? What could we do with more feedback, more often, and with someone helping us track measurable progress towards our goals as agents inspiring learning? Finland has an excellent system of teacher feedback and peer/mentoring for their educators. Teacher’s college is harder to get into there than medical school (not sure that’s a good thing, but it’s what Greg told us).
Key Points About Teaching & Learning
- People have two kinds of memory layers – short and long term – and short term memory (which is what we are working with in classroom environments) can hold ~7 items +/- 2 so really we should aim for 5 in order to teach to our students’ capacity
- We have to balance on/off time – we lose some time switching between tasks or concepts in the teaching but working with memory limitations as mentioned above, we must let people take breaks to reset & refresh
- Avg person can take in info for about 45 minutes before their attention wanes from exhaustion. For me, this is more like 30 minutes. Hearing this from Greg reminds me that I want to propose that all meetings I’m involved with at work move the default length to 30 minutes and that we have a set of rules for how to deal with ‘overage’. Either email or mailing list post, etherpad, set up a follow-up meeting, or make a proposal and request feedback so that we are not taking an hour because we *have* an hour.
- Apparently the military has a lot of research and effective solutions for human performance. Greg mentioned being at a naval academy and the grad students he was lecturing to dropped into doing pushups when a bell sounded on the hour. This sounds like a great practice for anyone trying to learn and be engaged with others – get your blood pumping and change your position. Reminds me to get that automated rest-taking app running on my laptop again and to actually pay attention to it for a while instead of dismissing over and over.
- Continuous ‘flow’ – oh that elusive state for programmers. There was some sort of quote about coffee but I missed the first part, the gist was that when we are immersed in something and truly engaged we can override that 45 minute intake limitation from before but if we do more than pause (without switching contexts) we could end up breaking flow and it takes at least 5-10 minutes to get back into it. This is key for people who work in environments full of distractions and interruptions. I’ve been thinking a lot about this one lately as I’d like to work on breaking my very unproductive cycle of checking IRC and email in a loop as though I am event-driven. I need to make times to get into ‘flow’ and do bigger tasks with more focus.
- A sidebar of the distraction mention was the fact that, in programming, syntax can be the distraction. That is, errors in. When you get stuck trying to figure out where your semi-colon or indentation is off you break out of ‘flow’. In a language/framework like Scratch this is not possible as the blocks cannot be dragged and dropped into any order that creates errors except in ways that are related to logic and program flow – worth stopping to think about (and keeping you in your engagement ‘flow’)
- There are roughly three types of minds out there to work with in teaching: a) Novice b) Competent c) Expert. The Novice doesn’t know what they don’t know so the most important thing to do when trying to teach a Novice is to make sure their mental model of the concept you are teaching is correct. This is to become a lot of the focus in the rest of the day – methods of determining if our concept is getting across correctly. The Expert is such because they have more connections between all the facts they know about the concept/skill and so they can leap from point A to point J in one move where it takes a Competent mind all the dots in between – executed well, but with thought and intention – to complete them. It is *as hard* to get Novices to become Competent as it is to get Experts to see the concept they are trying to teach as a Competent person does. Think about something you might be and Expert at and see if you can tell what steps you assume other people will know.
- Another key point about the Expert is the idea of reflection. Being able to reflect on your skill is huge for honing it. An example would be how I went to a hockey skating workshop where they video taped us skating our fastest and when I saw that video, saw how knock-kneed I was and how my internal map that I was using wide leg strokes did not actually look like that in the tape I was a) horrified but also b) it’s a reminder of how far I have to go and how much more work I need to do in order to reach a higher level of expertise, such as that reflected to me by the instructors.
Accepting Feedback and Critique
We spent some time talking about critique. In architecture, art, music, and many other disciplines there is a built-in system for critique. It helps the student to build up their sense of self, to know their strengths and weaknesses. We do not always have this in teaching. In our workshop, Greg had people write down one piece of positive and one negative feedback on two sticky notes (yellow for positive, pink for negative) and he asked us to put them on a piece of paper at the front of the room before we headed out on our first break (just over an hour of instruction had occurred). When we returned we discussed what the anonymous feedback had provided Greg with and what he could actually work on in the moment vs. what was useful for later. He mentioned doing this, and letting it be anonymous, was a great way to build trust with your students. Also we talked about how to get better at accepting feedback, working with it, not letting it paralyze you or derail your lesson.
One of the key takeaways for me here was the idea that the most senior leader/teacher should model this for others. Show that you can hear feedback, both good and negative (hopefully constructive), and be able to move forward without crumbling under the pressure. While I’m nervous about feedback, I will do my best to ‘fake it till I make it’ on this point because it’s definitely more important to correct course and create a better experience for students than to be proud and lose their interest and especially, trust.
Our next major concept was the concept map. This is a way to help yourself understand what you are trying to teach. It’s also a way to check yourself for the 7 items +/- 2 factor. If you have more than 5 main concepts in the concept map, it’s time to evaluate it for what can be put aside for now or what can become the next lesson. The concept map can also be shared with students as a way to make sure everyone is on the same page or at least starting with the same page. Greg recommended handing out a printout of the concept map so that students could doodle and expand it in ways he might not have thought of.
We learned how the concept map should never be used for grading. It’s mostly a tool for the teacher to know if they have managed to get across the mental model well enough for the novice to reflect back a matching map and feel comfortable moving on to the next concept. It’s also a way of preventing the “blank screen” where students can be frozen trying to come up with what to put down (in programming or in writing) and having a scaffolding there in the form of map, or hints, any form of guidance can basically jump start the student and hold their hand until they need less and less of it to self-start, self-direct, and truly *learn* autonomously.
We did an exercise where we drew up concept maps for how to teach a for loop. This was my first time doing a concept map and it was hard. Definitely will take practice and likely some more reading/looking at other concept maps to drive home the concept for myself.
Key points from Greg:
- Make your concept map look ‘cheap’ so that people aren’t afraid to give you honest feedback
- Write and share maps with each other – try this with your team at work on a project you’re starting – you might see that others have a *very* different sense of what is being attempted
- Try not to need things in your concept map that you will “explain later” – if you can’t explain it now you’re going to disrupt the ‘flow’ of maximizing the short term memory limits
- Transfer your map into a list of bullet points as it will help you put the most important concepts first
- Think of concept mapping like couples dances. You both want to be doing the same dance or there will be a lot of bruised shins 🙂
Sticky Notes as Invaluable Teaching Tool
We used sticky notes at several points in this workshop. While we only had two colours today, Greg recommends three colours to be used as follows:
- Green: Students can put this up in a visible place when they have completed the exercise currently being done
- Yellow: Students can put this up when they have a question. Also this is a great tool for ensuring more participation in the classroom setting. Some people talk more than others, there are definitely certain types of people who take up more space, and the deal with the yellow stickies was: You get two, when you ask a question put one aside. Another question? Put the other aside. Now you have no more questions until EVERYONE in the class has used at least one of their yellow stickies.
- Red: Students can pop this up in a visible place when they need help on something. This is great for two reasons: 1) the student can keep *trying* instead of worrying about holding a hand up and waiting for eye contact with a teacher and 2) the student can request help without drawing too much attention to themselves. This is great for classes with people who might have learned it’s best not to speak up, ask questions, or draw attention to themselves out of fear and/or shame.
Know Your End Goal
This probably shouldn’t have *blown my mind* but it did. It’s so obvious yet I’ve never once designed curriculum with this approach. You can bet that’s all changed now. Here’s the key point:
DESIGN YOUR LESSON BY WRITING THE ‘EXAM’ FIRST
Ya. It’s maybe obvious. You want to make sure the students leave knowing what you intended to teach them? Well, figure out how you’re going to measure that success *first*, then build your lesson up to that. “They understand the for loop” is not enough. Be specific. Have a multiple choice question that tests the output of a for loop and gives 3 plausible answers and one right answer. Use this to check if you are teaching well – their failure to choose the right question is your failure to teach the concept correctly. This doesn’t have to be for actual grading (unless you want to grade yourself). Think of this like Test Driven Development for curriculum. Teach to the goal. You will develop lessons faster and more efficiently. Your learners will appreciate it. They can tell when they are learning vs. having a lecturer do a brain dump on them that goes nowhere in particular. Backwards design works. Greg’s book plug related to this section: “Seeing Like a State“
Another tip? Create one or more user profiles for your lesson. In our workshop we created Dawn: 15 year old girl who is good at science and math, learning programming in a one-day workshop. Then we did an exercise in crafting a question that would confirm if we had successfully taught how functions work to her.
We learned about Allison Elliott Tew‘s work and about “Concept Inventory” which is a way to use common mistakes in mental modeling to create multiple choice questions where the incorrect answers can help you understand *how* someone has misunderstood the concept you are trying to teach. Multiple choice is great because it’s quick to get you an assessment (teacher grading time).
Related to multiple-choice as test of understanding is Peer Instruction. This is a method that uses a multiple choice question in a really interesting, and engaging fashion.
Developed by Eric Mazur in the 1990’s this method expects students to have done some pre-work on the material before coming to class so that the entirety of the lesson can be used to compare and correct conceptual maps and understanding of the material. It goes like this (at least Greg’s interpretation – it differs in Wikipedia as to how Eric designed it):
- Provide a multiple choice question based on the pre-work content. Ensure 3 plausible answers and one correct
- Students select and *commit* to an answer (there is not yet software for this, though there are clickers) – you can also ask people to hold up the number of fingers for their choice and have classroom helpers count
- If everyone picks the right answer you can move on but otherwise you ask people to talk in groups with their neighbours to examine each other’s choices and what the correct answer might be and why. This is great for having people explain their mental model/map
- Vote again and have students commit to the answer
- Instruction reveals the answer as well as perhaps a single sentence explaining why
- Groups discuss again, this time they can explore their understanding with the correct answer alongside people who, likely, had the correct model
This teaching technique was proven in 1989 but is still widely unused (esp. in MOOCs). Greg told us that he can usually do about 10 of these types of questions in a 1 hour class. We did an example of one in the workshop to test out the method and it was a lively exercise. This was also an opportunity for Greg to help us notice how noise in the room helps a teacher determine when a good time is to check in, continue the lesson, or make sure people aren’t stuck. Active, engaged learning is boisterous and noticeably relaxed. Quiet can mean focus, and then as people complete the exercise you can hear some discussions start up as those who are done talk with each other about the exercise. I look forward to getting a bit of expertise at this level of listening and was impressed by Greg’s skills in classroom energy level reading.
F*ck It, I’m Outta Here
I have several more pages of notes but it’s getting late and this is a long post. There’s one more part of the workshop that I’d like to write about: The moment when you decided you didn’t want to learn something anymore.
This is a really great piece of advice for teachers. Greg started by saying that he used to ask students what motivated them to learn, what great experience in learning they had so he could tap into that motivation as a teacher. Now? He asks people what DE-motivated them. You get a lot out of people this way. Ask someone (or think of your own experiences): “What was something you were curious about, working on, getting into, and what happened that made you say ‘f*ck it’ and drop it? If you could go back in time what would you change?”.
For my example I spoke about returning to gym class at 12 years of age after recovering for many months from a very physically traumatic incident where I was hit by a car while on my bike (15 bones broken, 6 months in a wheelchair). Being immobilized *and* being a pre-teen caused me to put on a fair amount of weight and I was no longer very physically active or able. I also had yet-to-be-diagnosed asthma. Not only did I have to endure a gym class where those with natural talents were help up while the rest of us were discarded but I also continued to fail tremendously at getting more than a “Participation” certificate(! Every other result got a very nice badge) for the Canada Fitness Test.
My “F*ck it” moment was when I got so frustrated with never getting a badge that I stole someone’s gold badge when no one was watching. I also ended up eschewing all sports and athletic pursuits for many years if there was any hint of tryouts or actual talent needed. Years later, at 29, I taught myself how to run by using a couch-to-10K program that did repetitions of running and walking in order to build up endurance. Not only did I succeed at that but I learned to *love* running and feeling healthier in my body. If I could go back in time I would become a Physical Education teacher and make sure every kid in my class knew that it’s not about natural talent at anything. It’s about setting achievable goals for yourself and comparing your results against your OWN RESULTS. Never mind some test, and other kids. We’re all very different but no one should be denied a sense of accomplishment. It’s what keeps you coming back to learn & build on what you’ve learned.
Now Go Read More: Keep Learning How to Teach
It was an amazing day. I have more notes to transcribe for myself but I think I’ve managed to capture the major concepts I learned today that will all be invaluable in my work on Ascend and beyond. Greg is an experienced, passionate, driven teacher and his enthusiasm for *knowing* what works in education is contagious. I want to be a better scientist and educator too. The Software Carpentry movement is picking up momentum. Look for workshops, blog posts, and opportunities to participate in a town near you. See their site for up to date information and also check out their materials page for additional resources. I’ve got a few new books to read on the plane home tomorrow.
4 thoughts on “Learn To Teach Programming – Software Carpentry”
Mentoring and coaching are hard to get when the crowd is big or new. So, a way to scale up and get most of the benefits is the staged peer instruction exercise described above. To prepare this, the instructor has to find multiple choice questions — that is the hard part.
Thanks for the great notes, Lukas!
One of my favorite suggestions from the class was the “fade-in exercises” (I think that’s what they were called), where the students start with a problem that is *almost* completely solved; maybe just one line is missing. That protects them from the “terror of the blank screen”. On the next problem, two lines are missing; on the next, three lines; and so forth.
I’ll post more items from my own notes later, I hope!
Lukas – Thanks for summarizing a really great day of learning about learning.
There was something about the way the “know your end goal” section flowed out of the concept mapping exercise that threw me a bit. I had (mis?)understood Greg to suggest that one would do the concept mapping after deciding on the end goal. Your putting this into the context of lesson planning may have better established what was intended. In my context, I would be planning the curriculum for a full-semester course, and the process would be more iterative. The concept mapping would be a valuable tool to help me “chunk” the big objectives of the course into manageable pieces and make sure my end goals are the correct ones for each lesson. Even in terms of the end goals of the course and the assessment of them, what I as an “expert” might first think of as the correct goals to be evaluated might change as I deconstruct my “expertness”.
The way that novices, competent practitioners and experts were distinguished was particularly helpful. I’ve found myself on both ends of that spectrum looking toward the other end and scratching my head – this provided a framework for turning that frustration into something constructive. This is a section that would be particularly worth placing a fair bit of emphasis on as the workshop develops, IMO.
Great synopsis of a thought-provoking, enjoyable workshop. Please keep me in the loop.