Teaching coding to a mixed-ability group can be very challenging. However our blog allowed me increased flexibility as outlined here.
Providing resources for self-learning
Self-learning is not only a 21st century skill but a particularly key skill for any programming. This lesson structure allowed me to encourage self-learning in my students, started from the very directed help as shown above to the eventual more generic ‘Why don’t you ask Google how to do that?’
Differentiated Learning
It allowed one to provide individual levels of support to different students: assignments often had further help available. This further help was passoword protected and student were aware that the password cost them a percentage of the marks.
Providing just-in-time help
Often, I made certain resources available at the start of a lesson and then uploaded further resources according to students’ need. This had various advantages, for instance it allowed students to engage more in discovery-learning and in coming up with creative solutions as certain help (E.g. flowcharts) was generally only uploaded if I realised too many students were getting stuck; at other times I added further challenges or posted help to new challenges some students set themselves.
Encouraging student creativity
At first students were given a problem to solve and allowed little creativity except in the final refinements of the application as shown in this blog entry.
However as the lessons progressed I gave students more and more leeway in determining what they worked on, which helped not only keep them motivated but aptly prepared them for coming up with their own idea for their coursework.
Because I could provide help as the need arose, I could encourage students to do more diverse projects as I could use the blog to provide links or resources different students needed.
Another case in point would be the lesson behind this blog entry were students who were still fairly new to coding developed a simple game, with each student choosing a different topic.
Providing assessment criteria for each different exercise that a student can access anywhere.
When I first gave the above assessment criteria, I realised that it had somewhat backfired in restricting student creativity. Students reasoned that if their code ticked the above required list they needen’t take their work any further…so I learnt to introduce the assessment criteria: Additional Useful Features, where students were awarded 2 marks for each such feature. This created the unusual situation of their being no ‘full marks’ which I think aptly represents the reality of software development as it moves steadfastly forward.
Critical Reflection
This methodology allowed me to get rid of the rigid worksheet and present more of a problem-solving approach to coding. This helped me bring out a streak of creativity and energy in some of the more inclined of my students that I have not seen in past years. Some eventually produced programs far beyond my expectations. Students who were either of very low ability or simply not inclined to work, didn’t fare that much better than usual.







