2.6 Essential Pedagogical Content Knowledge [PCK]
Coding in the Classroom
It is one thing to learn how to code and it is another to learn how to teach students to code. Just as you would not teach a Social Studies class the same way you teach Math, coding as a sub-topic of Computer Science should be approached with a pedagogy that suits the subject. Hopefully the previous section gave you sense of what it is like to learn how to code, some of the joys and frustrations, while also offering an opportunity to think reflectively about how you would have presented those same concepts.
Coding lends itself to Project-Based Learning Models
|
First, in my experience, heavy use of Direct Instruction through lecturing about concrete skills or computing concepts is not effective. Instead, I lean heavily on Project-Based learning models. Coding is practical in the sense that you are manipulating code and observing the changes either with a desired outcome in mind or purely for experimentation. However, there is important content to cover before students are able to code and so this instruction is sometimes necessary.
I have had the most success with giving short demonstrations of new functions or concepts followed by a quick whole-group discussion to answer any student questions. Typically students want to get to work right away and holding their attention when an exciting new concept has just been presented can be difficult. Further, you don't want to stifle their enthusiasm so it's important to plan out and practice your demonstration so it doesn't drag on or get stalled by errors from 'bugs' in your code. |
Once the class engages with a concept each student will inevitably meeting varying levels of success. Some will get their program working right away and some will struggle for the rest of the lesson unless they get support. The demands of those who need help will be overwhelming for one single teacher and those who are 'finished' can quickly become restless and disruptive. Facilitating peer mentoring solves both problems. Students with a stronger understanding get exposure to the added challenge of working with code they did not write and students who are struggling gain insight from their peers. One potential pitfall is that the 'helper' student may kick the struggling student out of their seat and simply re-write their program; this is not beneficial, so it must be made clear that helpers are not allowed to type on the keyboard. Helpers instead should provide verbal support and encouragement in an effort to help their classmate fix the program for themselves.
In my experience, students would much rather have the teacher help them than a peer mentor, though in general students seem to enjoy working together and helping their classmates. A helpful rule I heard once from a colleague was this: "Ask three before me!"
This means that every student must ask three peers for help before approaching the teacher. Be strict in reinforcing this rule and you'll find that many of the trivial and repetitive problems that might bog down your lessons get resolved quickly. It will also give you more time to work with students through deeper problems or misunderstandings. |
Pump up your heart rate! Get up and stretch before scrolling down!
Working with Individual Students
Many students are much more excited about getting their program to 'work' than they are about learning the skills or understanding the concepts you are trying to teach. It can be easy at times to just take over and fix a section for them when your explanations don't seem to be getting through or the student is 'checking out'. It is very important that you do not do this. If you don't spend the time to teach a student how to fix a problem it will become a habit that eats up far too much of your time. It is worth explaining and resolving the issue once, even if it takes a while, when compared to fixing that same problem for the same student three dozen times.
One of the things you'll have to gauge as you go along is how far to push students when they get frustrated. You do want to help them build resiliency and develop strategies for when they get stuck. However, pushing too far past their zone of proximal development can lead to angry outbursts, emotional shutdowns, and general feelings of negativity toward coding. Further, a student's self-image can be damaged if they repeatedly experience frustration and failure while coding. At the end of the day the focus should be on growth, not on getting the program to work perfectly. Help students embrace the flaws in their code as an essential step to learning how to communicate with computers.
|
As a final word, be particularly careful to avoid gendered language or behaviour that might reinforce the completely false idea that coding is for boys and not for girls or individuals who identify in other ways. This is especially important because the media messages kids recieve online and even the messaging they get from home might directly or indirectly support such ideas. Learning to code in the classroom is a great opportunity to provide everyone with an equal and exciting opportunity to experience the joy of coding.
Lesson Structure
Students really need time to grapple with concepts, to experiment with their code, and to thoroughly debug their programs. You might be surprised at how little you seem to get done. Keep in mind that as you teach students to code there is a lot of skill-based knowledge and abstract concepts they are trying to process all at once. For that reason I find my lessons are typically 10% Direct Instruction by way of a short demonstration, followed by 80% individual or collaborative work time, and closing with 10% showing student examples, having reflective group discussions, and reminding everyone to save their work in the proper location.
In summary, about 20% of the class is teacher-directed (10% at the beginning and 10% at the end) and the other 80% of most lessons is reserved for individual work, for paired peer-mentoring, or for small group collaboration. |
Students often tire quickly of 'narrow' projects that offer little in the way of experimentation or expression. I strive to create projects with a solid, well-structured beginning but a very open end that allows for student creativity. Computer Science Education pioneer Seymour Papert talked about creating projects with 'low floors' and 'high ceilings'; such projects allow everyone to experience some level of success without limiting students in how far they can explore the concept. You will experience this in action during the third section of Codegogy where I walk through planning and implementing an example lesson.
Freeze & Reflect (2.6a):
|