Dave has fond memories of learning to program in the 1980s. Typing in programs from computer magazines to see what they would do. Inevitably, at 10 years old, he wasn’t very accurate in transcribing the listings and there were errors. He had to study the program carefully, and correct his mistakes.
The programs would eventually run, and he would be delighted that the computer did something it couldn’t do before because it had been told to. The programs were very simple, so he began experimenting with changing a few variables (not that he understood what they were back in the day) to see what would happen. This was intriguing, and having picked up the “Programmers guide” and “Programming keywords” for Locomotive Basic that had come with his Amstrad CPC464, began to experiment with adding in extra little bits to the code to see what would happen. Gradually he became more confident and wanted to know how to do something, to solve a particular problem he had set himself. Using the programming keywords as a handy reference he learned the commands he could use, their syntax, and gradually memorised them.
As he became more confident he began setting himself bigger challenges, writing code from scratch, and learning more through the process. He began to learn of more appropriate techniques, and the programs became more sophisticated.
It is this learning journey to becoming a confident programmer that we share with our students:
- Learning tasks:
- Typing up code, seeing what happens: the confidence from not starting from a blank screen.
- Modifying the code to do something different: beginning to understand what the code means.
- Studying syntax guides for the commands.
- Attempting challenges using only the commands learned: applying new knowledge gained.
- Beginning to write bigger programs with less support: becoming independent.
Whilst many teachers still lead programming from the front of the class with all students tackling the same problem at the same time, and introducing new key words at a defined pace, Craig and Dave don’t think this is the most effective approach. Programming is a skill that different learners will bring to the classroom. It will be very easy to progress either too quickly or too slowly for some learners with this approach. We think it is better that students move on to the next set of keywords when they are ready. With some students progressing at a very fast pace. We think that the learning of programming should be structured so as to introduce keywords in a logical order and not all at the same time. Starting with outputs, inputs, variables, strings, conditions then iterations etc. Once all the basic constructs are understood, then they can be applied to more challenging and larger problems.
Comments, sensible variable names and indenting are introduced at the start so as not to begin with bad habits. From there structured programming with procedures can be introduced including designing algorithms with pseudocode. It is good to expose students to a range of problems expressed descriptively, with flowcharts and with pseudocode so they gain confidence with all these methodologies.
There is a place for paired programming too. 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.
There is no need for all learners to solve all problems. It is good to be able to provide a small selection of problems of similar difficulty so students can have some ownership of the task within scaffolded boundaries. Students should complete all the learning tasks in an objective, and once complete attempt the problems for that objective. Each problem has a difficulty rating indicated with a hammer/spanner icon, 1-4. We recommend students typically attempt to achieve 6 spanners in an objective (except for objective 1). This means they could attempt three of the two spanner spanner problems, or two of the three spanner problems, or indeed two of the one spanner problems plus two of the two spanner problems. Lots of combinations allows students to have ownership and for you to differentiate very easily.
When students complete a problem, as a teacher you can then review their code, discussing techniques adopted, command words like concatenation, parameter etc. Giving them this individual and timely oral feedback is far more effective than any other type of feedback for programming. Put a progress chart on the board if you want to motivate students to keep pace!
Parsons Problems (invented by Dale Parsons at Otago Polytechnic, New Zealand) give students a programming problem, and give them all the lines of program code to correctly solve the problem, but the lines of code are broken into code blocks and mixed up. This is a great strategy and really helpful for supporting students that are struggling with putting constructs together. This is a feature of our resources we will be including in the future.