The new National Curriculum for Computing at KS1 and KS2 is, arguably, one of the few subjects that primary teachers fear their pupils will know more about than themselves.
A question I frequently get asked is ‘How do you cope when the children know more than you do’? As a Computer Scientist, it takes a lot to out-geek me but I know many teachers feel they have no hope of keeping ahead of the children they will be teaching.
There’s no need to. Children seemingly racing ahead with what look like quite sophisticated software and systems is no guarantee of them making progress in computing; because you’re teaching them much more than just programming. Here are a few tips on how to facilitate learning in computing whilst not holding your pupils back.
I’ve had reports from some schools, dipping their toes into computing, that their pupils go home, download the free software they’re using and come back to the next lesson having moved on 2-3 lessons ahead of where they planned – sending them into panic mode. Whilst everyone agrees it’s great to see such enthusiasm for a subject, how can you manage such rapid progression?
First of all, don’t assume they’ve actually progressed. Having created a seemingly sophisticated piece of software does not guarantee that it actually is. The output of programs children produce is not the sole means of assessing how they’re doing.
Computing as a subject has the potential to be Vygotsky’s theory of learning exemplified: children learning with and from each other with the teacher ‘helping children acquire the tools of their culture’. This is a golden opportunity for teachers to embrace this pedagogical approach and participate as both a learner and a facilitator.
You do not need to know the intricacies of each programming language you teach. You do, however, need to know the fundamental principles of computer science (one of the aims of the new Primary Computing Curriculum) and how to assess whether your pupils are developing and applying them.
If one of your children bounces back to school having appeared to have moved right to the end of where you intended to direct them, here are a few tips about what you can do…
Design and Planning
Ask the child to present their work to either the class, or a group of children, and explain, precisely, how they approached and developed their task.
In order to truly progress in computing, pupils need to develop computational thinking skills. Rather than letting children get on computers straight away and develop software and systems using a trail-and-error approach, my computing scheme uses classroom techniques and approaches that encourage the children to think about what they want to achieve and then break the ‘problem’ into smaller chunks drawing/documenting how they will ‘solve’ each part.
In computing this is known as decomposition – a valuable life-skill. If your apparently competent programmers are not yet planning algorithms and programs this is something you need to focus on. Classroom techniques to potentially use are:
- Partner discussion – where the children work together explaining in detail what they want to achieve and exactly how they plan to achieve it
- Story-boarding – younger children plan and draw their plans for programs piece by piece
- Designs – older children could produce detailed designs that they then swap with another child and use to program each other’s project. If they can’t do it from the design, it’s not detailed enough
Abstraction is the process of identifying a solution that can be applied to a number of different problems – a bit like designing a spanner that fits a number of different nuts and bolts. In simple terms: if the child’s code is repeatedly using the same chunks of code in various places around their program, then they’re not applying one of the fundamental principles of computing and this is an important one to develop.
You can quickly identify repeated bits of code, particularly in Scratch as it’s helpfully got nice coloured blocks. Ask the child to walk through their code (either you or a partner) reading it and explaining what each part does – without executing it. If the child needs to execute it before they can tell you what is happening then they haven’t understood how they achieved it and therefore will not be able to transfer their knowledge and skills to other situations. If you encounter this, take a screenshot of the code, print it and invite the child to come to you when they can tell you what it will do. They can then test their prediction by executing it. If they’re wrong, look at it again until they can explain, line by line, exactly what it will do when executed.
Encourage the children to identify patterns of code or those that are very similar to each other. If you, or another child, encounters repeated use of the same (or similar) pieces of code scattered around, set the child the task of designing and changing the code so that this repeated piece is only written once but ‘called’ from the other places they had it. In programming this is known as using procedures: it refines code by making it more efficient – if you want to change one command in the code, you only have to do it once as opposed to many times.
Many children are so chuffed that their software appears to work after the odd bit of rudimentary testing that they celebrate success a bit too early.
When a child thinks they’re done, or better still, a number of children think they’re done – ask them to swap projects and rigorously test each other’s work – this known as debugging. You can ask each child to produce a testing plan of their own project that ensures each and every part is tested in all permutations. This provides an excellent opportunity for them to evaluate their own work, and debug it before they pass it on for testing; thereby further developing skills of decomposition and also identifying ways of improving their work.
When it comes to testing by another child, if they cannot execute each other’s system without being told how to use it (e.g. which keys to press) then the design needs improving (e.g. a help screen). The children can work through the testing plan, documenting any bugs they encounter, explaining when/how the bugs were evident. The children could then work in pairs to fix the bugs.
After successful testing, peer assessment could be used where the children evaluate each other’s work and comment upon what’s good about it (from both a user and programmer’s perspective) and how they feel it could be improved.
Improving and Enriching
Any piece of work can be improved and always have in mind ways that the task you have set the children could be extended and/or enriched. This could take the form of adding complexity to a program (e.g. you have a maze game, now use obstacles and enemies to avoid; use variables for level-ups/bonus points) or deepening understanding through ‘off-computer’ activities (e.g. your program involved sorting numbers let’s physically model how computers use sorting algorithms)
Those were a few suggestions of the kind of things you could do, without being an expert programmer, to ensure that computing progression is being made. If you want a few more ideas about how computing lessons could be extended/enriched to help feel better prepared, check out some free computing lessons here.