Programming with T.I.M.E.

Your programming resources are simply the best.

Available in Python and C#, these are the programming resources you have been waiting for. At last, all the recognised and proven pedagogies for teaching programming in one comprehensive set of resources.

PRIMM, Rosenshine, block comprehension, Parsons, functions first, cognitive load reduction, stepped challenges, and design by doing. Welcome to the Craig’n’Dave T.I.M.E. approach to teaching and learning programming for GCSE and A level.


You don’t need a course to teach you how to teach programming. In typical Craig’n’Dave style, you just need resources that you can give to your students, let them work independently and watch them fly.

Over 118 programs to

Try, Investigate, Make and Evaluate

HOW IT WORKS

Students have ten workbooks to complete independently. There is no need to lead this from the front of the class. With Craig'n'Dave resources students learn by doing, not by listening!

Each workbook introduces a new programming concept.

  1. Learn how to write structured programs.
  2. Learn how to use selection.
  3. Learn how to use number data types.
  4. Learn how to use string data types.
  5. Learn how to use counter-controlled iterations.
  6. Learn how to use condition-controlled iterations.
  7. Learn how to handle user inputs.
  8. Learn how to use arrays and lists.
  9. Learn how to use serial files.
  10. Learn how to master the basics.

Students will have been taught a text-based language at Key Stage 3, but don't be fooled into thinking these objectives look too easy. There is a significantly higher expectation with a functions first approach, validation, exception handling and harder problems to solve.

Each workbook has four sections: Try, Investigate, Make and Evaluate. It's based on the PRIMM model proposed by Sue Sentence, but our T.I.M.E. acronym just makes more sense! After all, becoming a good programmer takes time!


TRY STAGE

Predict what a program will do. Type or paste the code and give it a try.


Students look at a coded solution provided to them and predict what the output will be. Students type in the code to see if they are correct. This approach aims to simulate how self-taught programmers like Craig and Dave learned to program in the 1980s using code listings in magazines and programming manuals. Not starting from a blank screen is less daunting for students, provides models and guides student practice.


Our resources use a "functions first" approach. Students are taught to structure their programs into subroutines from the very first, "Hello World" program. Inputs are left until much later because they should always be properly validated and sanitised.

INVESTIGATE STAGE

Comprehend the code. Modify the code. Debug code.


Students learn how the sample programs work, understanding the new commands introduced. A set of small tasks challenge students to modify the sample programs they have been given in order to experiment with the commands. At the end of the stage, keywords and learning points are summarised as a handy reference. The syntax of related additional commands are also presented. These were not needed in the sample programs, but could be useful to students when writing their own programs. These also include all the commands listed in examination board specifications.


A set of progressive comprehension questions also provide students with an opportunity to consider what terms mean, what commands or blocks of code achieve, how they work and why they are used. A deeper knowledge of syntax and programming constructs allows students to adapt to new commands more easily. This is based on a simplified student-friendly version of the block model of program comprehension proposed by Carsten Schulte.


  • ITEM: Asking questions about programming terminology and keywords.
  • STRUCTURE: Asking questions about the syntax of lines and identifying blocks of code.
  • PURPOSE: Asking questions about what a keyword or structure achieves, returns, or outputs.
  • REASON: Asking questions about why a keyword or structure is used.
  • RELATION: Asking questions about how structures relate to each other. Considering the wider implications for the program or computer system.
  • APPROACH: Asking questions about how a section of code can be modified to achieve a greater purpose.

MAKE STAGE

Design an algorithm. Code the solution.


Programs to write and problems to solve are presented in a mixture of written English, flowcharts, pseudocode, Parsons problems and output focused. Problems increase in difficulty indicated by the number of points.


We suggest students choose the problems they want to solve, aiming for a total of 6 points in each objective. This provides for student choice and differentiation. Students who find programming more difficult could achieve 6 points from: 1 + 1 + 2 + 2-point problems. More able students could achieve 6 points from: 3 + 3-point problems.


There are too many problems to solve in one GCSE course, so when students study Computer Science at A level, they can use familiar resources to try the problems that they didn't attempt previously using a new language.

Fully scaffolded and differentiated problems to solve enables students to take ownership of their learning.

EVALUTE STAGE

Test the code. Reflect on the approach. Refine the code.


Objectives will frequently require students to create and use test tables to test their solutions to the problems. This encourages good practice and teaches the importance of robust code.


Once students have finished an objective, they should alert their teacher. This is an opportunity to have a conversation with the student and give oral feedback on the problems attempted. Immediate oral feedback will be far more useful to the student than written feedback.

A programming progress tracker is included with our resources together with a framework for oral feedback conversations including questions to ask about comprehension, maintainability, scalability, robustness and approach a student has taken with code.


THE ROLE OF THE TEACHER

If you are not leading programming from the front of the class and students are working on different tasks at the same time, what does the teacher do?

Programming taught from the front of the class at best only ever effectively teaches a third of the class. Some can already progress further beyond what you are explaining and some are already lost and need additional support. Allowing students to learn independently at their own pace and choose their own challenges allows greater flexibility for the teacher to stretch and support individual students.


The role of the teacher is to maintain pace, provide individual interventions when students are stuck, review completed objectives and track progress.


Using these resources, students that are absent from class are not disadvantaged and can even continue their work at home. If a question is too difficult to answer, or a problem is too difficult to solve, these can be left to be discussed with the teacher. The student can still move on to the next objective or problem.

EVEN MORE FROM CRAIG'N'DAVE

A text adventure game for Python and Visual Basic, "Telium" is available in our AQA 8525, OCR J277 and Pearson Edexcel 1CP2 resources. An eight-part major project with code to try, questions to investigate and extensions to build.

Also available, our object-oriented Defold resources for games development in Lua. Ideal for A level projects, but also for extra-curricular clubs.

TRY A FREE SAMPLE

Read a more comprehensive description of how Craig'n'Dave T.I.M.E. resources work.

IN THE FUTURE

Objective 10 is a never-ending objective. Craig'n'Dave will be releasing a new problem using the T.I.M.E. approach periodically, building an enormous bank of material.

We are actively working on a Java version of T.I.M.E. now with Visual Basic to follow.

Extension modules to T.I.M.E. coming in the future will include programs with graphical interfaces and object-oriented exercises.

Registered in England and Wales: 10442992 | VAT: 290 9845 58 | 03330 164 059