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 extra-curricular clubs at Key Stage 4.

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. Also included is a text adventure game, “Telium” that you can use as a project to give students a scaffolded but substantial programming experience that OCR require.

Our resources are based on the PRIMM model.

WHAT OUR RESOURCES ACHIEVE

Programming lessons with Craig’n’Dave resources ensure that all learners:

• Can make progress from different starting points.
• Can work at their own pace with appropriate challenge, and in doing so find engagement.
• Can easily catch up if they miss a lesson.
• Can make progress at their own pace and not have to wait for the next objectives.
• Can take some ownership of their own learning journey by selecting from a set of problems to solve.
• Can experience problems similar to those they will see in exams.
• Can expand beyond the scheme of learning.
• Can benefit from more interaction with you because you are not tethered to the front of the classroom.

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. 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:

• Objective 1: learn to output text strings.
• Objective 2: learn to input strings and numbers into variables.
• Objective 3: learn string manipulation functions.
• Objective 4: learn how to use selection statements.
• Objective 5: learn how to use arithmetic operations and random numbers.
• Objective 6: learn counter-controlled iterations.
• Objective 7: learn condition-controlled iterations.
• Objective 8: learn subroutines, procedures and functions.
• Objective 9: learn arrays and lists.
• Objective 10: learn serial files.
• Objective 11: learn to handle exceptions.

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:

• Most students should aim to solve one 1-point problem, one 2-point problem and one 3-point problem.
• Students could optionally choose to solve three 2-point problems.
• More able students could solve two 3-point problems.
• Less able students could solve two 1-point problems and two 2-point problems.
• Some students may also want the marathon challenge of completing as many problems as possible!

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.