7516 & 7517
I achieved an A grade in my Computer Science AS and I can only thank Craig and Dave for that.
We provide programming resources for Python (version 3) and Visual Basic Console (2015+). In addition, we have tutorials for games design using Lua that are suitable for preparing students for their programming project. Our resources include 80+ learning tasks, problems and solutions plus 180 PowerPoint slides you can use to teach the theoretical concepts if you prefer a more traditional approach.
BUILDING ON GCSE
These are the same resources we use at GCSE. However, at A level we challenge students to try them in a new programming language. If they studied Python in years 10 and 11, they can now attempt them in Visual Basic. This consolidates their learning but also enables students to see the similarities and differences between high level languages in the same paradigm.
At GCSE students will not have attempted all of the problems included in this resource so there is also plenty of opportunity for students to try new problems too, especially the more difficult ones. In our own classrooms we accelerate the pace of programming at A level. While at GCSE the tasks we suitable for the whole of year 10, at A level we only use them between September and Christmas of year 12. After that we transition to Defold and Lua. Of course in your classroom you can use the resources in any way that suits your local context.
WHAT OUR RESOURCES ACHIEVE
Programming lessons with Craig'n'Dave resources ensure that all learners:
THE CRAIG'N'DAVE APPROACH
We don’t lead programming from the front of the class with all students learning the same programming concepts at the same time. Delivering a lesson this way may satisfy a teacher’s desire to teach, but inevitably some students will glaze over, some will find it useful and some will already know what you are teaching them! Why teach to only one proportion of the class when an independent learning approach would enable students to take ownership and the teacher to spend more time with individuals?
Therefore, students in our classroom are self-taught. This method has proven to work in a diverse range of secondary schools for many years. Our resources are based on the PRIMM model. We provide students with all the resources they need to learn to code for themselves by giving them learning tasks and problems to solve. We then intervene with individuals and sometimes take a pause to illustrate something to the whole class.
We suggest our programming resources are used in the following way:
Learning tasks – Rosenshine's new material in small steps and providing models
1. Students input a coded example we give them, run the program and see what happens. This gives students the confidence of not starting programs themselves from a blank screen when they lack confidence and need support.
2. Students follow instructions to modify the code to enable it to do something different: allowing students to begin to understand what the code means by a try and see approach.
3. Students look at the syntax guide of the commands introduced, but we limit these to introduce new material in small steps.
Problems – Rosenshine's independent practice
4. Students choose and attempt a variety of small problems using only the commands learned: enabling student to apply new knowledge gained from the learning tasks. Students aim to achieve 6 points within each objective. Each problem has a rating of 1-4: writing bigger programs with less support to become independent.
Interventions – Rosenshine's guiding student practice, asking questions and checking student understanding
5. When a student has finished a problem, have a look at their solution with them and give them oral feedback. That is much more effective for assessing programming than written feedback. Discuss with them terminology, the approach they have taken, comments, sensible variable names and indenting. Asking the student to explain how the code works.
6. As students are working help the less able understand what they are trying to achieve. By allowing students to work at their own pace independently and not directed from the from of the class, you will have more time to support those who need it without boring those who don’t!
7. Visit the more the more able too and challenge them to make their programs more robust and with extended features. Most of the programs written will crash very easily with the wrong inputs.
8. Share code a student has produced with the whole class to identify different approaches, misconceptions, fix bugs and highlight learning points.
ROSENSHINE'S NEW MATERIAL IN SMALL STEPS
Our students learn to program by building up their knowledge of commands one step at a time. We ensure the solutions to our problems only ever require the knowledge gained in the current and previous learning tasks:
GIVING STUDENTS OWNERSHIP OF THEIR LEARNING
There is no need for all learners to solve all problems. This gives you student ownership and differentiation by task without you having to do any additional work! We recommend students attempt to achieve 6 points in an objective (except for objective 1). They can do this in a number of ways:
Put a progress chart on the board if you want to motivate students to keep pace!
COMPLIMENTING OTHER SUCCESSFUL APPROACHES
From time to time you can mix up our core approach with other ideas to add variety. For example, put the output from a problem on the board and ask all students to write a program to produce that output. For example:
Hi, please enter your name: David
Please enter your date of birth: 20/5/03
Hello David. You are old enough to drive and vote in elections.
Tasks like this are still differentiated because they are extremely open ended. There are many ways to solve the problem and many potential improvements to add stretch and challenge. This approach works great for tests and with paired programming. Not just getting students to work in pairs but getting one student to write the code whilst another reviews it and adds ideas into the problem solving. After ten minutes swapping roles.
Parsons Problems (invented by Dale Parsons at Otago Polytechnic, New Zealand) gives students all the lines of code to correctly solve a problem, but the lines of code are broken into code blocks and mixed up. The student has to put them back in the correct order for the program to work. This is a great strategy for supporting students that are struggling with writing larger programs and understanding problem decomposition.