What good programming work looks like
22 July 2022
In our previous posts we’ve argued that practical programming is of vital importance in computing education, is intrinsic to computer science, teaches useful skills and is itself great pedagogy. Here, we turn our attention to what good practical programming might look like in schools.
In primary and lower secondary, a rich experience of practical programming requires time and support from teachers and school leaders, but experience suggests that the benefits are worth it. At GCSE, freed from the constraints of controlled conditions and artificial set tasks, project work can be done in pupils’ own time, as regular homework or open-ended holiday projects. If you’re teaching Year 10 at the moment, you might use this summer to give pupils “the opportunity to develop programming skills during their course of study”?
Practical programming will include some time spent on learning the basics - the syntax of the language, the mechanics of an editor and importantly, how core constructs such as sequence, selection, repetition, variables and modularity are handled in a particular system. However, it would be a shame to stop there, when practical work offers so many opportunities to bring these ideas to life, and to give them expression through meaningful contexts.
● Pupils can engage in tasks they find personally relevant, drawing on their culture, interests outside of school or the other subjects they’re studying. They can go further and solve real-world problems.
● Pupils can collaborate with one another in practical work, perhaps through pair programming, or collaborate with mentors or peers beyond school (possibly one of the reasons why Scratch has been such a success).
● Practical work includes many opportunities for pupils to develop more autonomy in their learning by engaging in independent research, developing their knowledge of a particular programming language, being motivated through problems they encounter, building tenacity in tackling troublesome bugs, or deepening and generalising their understanding through learning a new language.
Whilst expert coders might cope well with tasks to write a program to do this or that, novices are likely to benefit much more from scaffolded tasks and worked examples.
● Pupils’ practical work can start with your program, or someone else’s - predict what this program will do? Run it! Did it do what you expected?
● Make a change to a program and predict what effect your change will have. Pupils might also rigorously test a program, trying to break it, or make sure it handles edge cases correctly.
● Give pupils a broken program and get them to fix it.
● Practical work can include simply experimenting with the language - Scratch (and other block-based languages) positively encourage this, but don’t be afraid to have your pupils experiment with code in text based languages too, for example, what does Python output if told print(10 and 7)? Or print(10 & 7)?
● If you do set programming problems or closed tasks to complete, be open to pupils extending or generalising their solutions, or refactoring their code to look for more efficient or elegant approaches.
In any practical work, take care to respond to the needs and interests of your individual pupils.
● Do you give them some choice for the context of their practical work - if you don’t at the moment, read up on universal design for learning to see how effective this can be.
● Think about how you make computing accessible to those who would otherwise struggle - many practical tasks can be made more inclusive by providing additional scaffolding or allowing block-based solutions, where others might work in text-based languages.
● Consider how you can challenge pupils to move beyond their existing comfort zone.
Without the artificial constraints of controlled assessment, practical work can include many opportunities for collaboration.
● Does your practical programming include teamwork from time to time? Do you encourage stronger pupils to support their weaker peers? If you do, help them to help in positive ways by talking together rather than them taking over the keyboard.
● Do you encourage pupils to explain what their program does and how they made it - look beyond merely adding comments to code and introduce pupils to the idea of literate programming, perhaps through Jupyter notebooks.
● Do pupils have a sense of there being an audience for their work?
● The Scratch community is great for this, but there are also coding competitions, hackathons and sharing work via GitHub.
Practical programming, particularly through project work, might need you to rethink some of the pedagogic practices and processes of your classroom, such as:
● How you identify misconceptions early on so they don’t act as a barrier to progress and a cause of frustration.
● How you teach them actively to debug their programs - debugging is a skill to be learnt too.
● How pupils receive feedback on their work, including whilst it’s in progress rather than solely as a finished product.
● How you can help pupils develop the skills they need to manage their own or group projects. There are tools and techniques you can borrow from software engineering which are worth introducing pupils to early on.
Remember you can read the full paper and comment on it in this CAS Discourse thread. There are lots of practical tips and useful links in Section 5 of the paper.