I was asked to deliver one of the National Centre for Computing Education’s bursary funded accelerator python courses at Fulford School this week and really enjoyed working with some great teachers who came along to learn and share their experiences.
I thought long and hard before the course about how to pull together all the mistakes I’ve made and the lessons I’ve learnt over the last decade of teaching Computing into some practical advice that can help make the teaching and learning of programming more accessible for learners of all abilities, interests and backgrounds.
K PRIDE is way of making the teaching and learning of programming accessible for all students that builds on the success of the PRIMM methodology.
I really admire Sue Sentance’s research and work on how to structure the teaching and learning of programming in a classroom environment.
Her PRIMM methodology has been really influential in making programming lessons more accessible and enjoyable. Programming can be both rewarding and creative but it’s definitely not an easy thing to learn.
There are so many mistakes we can make as teachers which can make learning to write, understand and debug programs frustrating for our students so I’m really grateful to Sue and others for addressing this and coming up with practical tips to make sure no student needs to feel left behind.
Sue’s research shows that structuring teaching and learning using the PRIMM model can help support students who’d otherwise struggle as well as stretching students who make more rapid progress.
You can read more about PRIMM here.
I’d like to suggest that there are two additional but essential things that can build on the success of PRIMM in order to help make computing lessons more accessible and effective for helping students understand core programming concepts.
It’s hard to ready any programming resources without coming across a barrage of tier 3 (specialised) vocabulary which can act as an impenetrable barrier to students who just don’t understand either what they’ve been asked to do or how to ask for help.
The K of K PRIDE stands for keywords so that teachers are encouraged to explicitly teach key terminology so that students are empowered to talk about, understand and ask for support their programming learning journey.
Going through a glossary of key terms for a particular programming skill empowers them to be able to articulate what they want to achieve, search for how to solve the problems they’ll inevitably encounter and will help enable teachers and students to accurately discuss what their programs are actually doing at each stage of development.
Referring back to keywords and definitions after teaching programming concepts helps students identify and cope with the same terminology when they encounter it in reference, revision or assessment material.
The PRI of K PRIDE are borrowed from PRIMM: Predict, Run and Investigate which are types of activity which gradually but actively build up students’ confidence understanding and experimenting with code.
The other new aspect of K PRIDE is D for Debugging. This is the part of learning to program which can be most infuriating for new beginners.
The temptation for teachers with limited curriculum time available is just to show students ‘how to do it right’. However, If students are only ever given code that works, they miss out on the opportunity to build up the confidence, experience and resilience they need to cope when their own code doesn’t work first time.
Deliberately creating opportunities for students to practice fixing common mistakes means that they can learn to interpret error messages independently and also provides a really valuable opportunity for discussing why certain common errors occur and how to avoid them.
Being able to find and fix errors in code can be very satisfying and a great way of remembering and understanding how code works.
The E of K PRIDE merges the Modify and Make aspect of PRIMM into Extend. I think it’s really important to give students a choice of how to apply their knowledge, skills and understanding with clearly defined but open ended challenges.
This allows students to feel a sense of ownership and pride in their work as they refer back to all of the support and scaffolding of the resources they’ve encountered so far (Keywords and definitions, Predict / Run outcome, Investigation conclusions and Debugging results) to Extend a code template or write their own related project.
It’s important that some of these activities are sufficiently challenging to stretch the most able students but it’s equally important to make sure that less confident students can choose at least one activity which they’ll also be able to find achievable.
Tips for differentiating programming challenges for less confident students:
1) Provide a small amount of code that can act as a starting point. Starting from scratch can be very intimidating until you’ve build up the necessary experience and confidence.
2) Provide a limited number of instructions (I’d recommend 3-5) as comments as part of the template code you provide. Make sure you only use specialist terminology if you’ve already covered it as one of your keywords. Ideally the challenges will be written in order of difficulty starting with the easiest.
3) Keep your examples brief and use whitespace (empty lines) to break up your code into ‘logical paragraphs’. Dyslexic students particularly find large blocks of code very difficult to process.
4) Use a suitable IDE. Many schools use IDLE because it comes bundled with most flavours of Python. I’d recommend Thonny or Mu because both show the line number next to each line of code which I think is essential for effective dialog between teacher and student. Thonny also does a great job of making suggestions on how to fix common error messages.
5) Carefully consider any assumed knowledge from other topics or subjects. Links to maths, science, geography or music can be a great way to motivate and engage some students, programming challenges that rely on those concepts can be significant barriers for other students. Equally, if your current topic is just about input and output, don’t expect students to write a program that requires a knowledge of iteration or functions/procedures unless you’ve already covered that. By all means use those cross topic / subject links to stretch some students but make sure you’ve got at least one Extend activity that is purely related to the concepts you’re trying to teach in that lesson.
For more details about each step of K PRIDE along with some example resources, download this overview and workbook:
I know how challenging it can be as a teacher to structure our programming lessons to enable every student to enjoy making progress. I don’t have all the answers but I’ve made enough mistakes to hope that this is useful. Let me know what you think and how you get on!