Saturday, April 26, 2014

How to teach a good primary programming lesson

Debugging is the skill of finding programming faults. It involves the understanding that making mistakes and learning from them is a normal part of programming. Implicit in this is that it is not the teachers job to fix pupils code. In fact to do so invites dependence on the teacher. Bearing this in mind, a good programming lesson will see the teacher establishing ways for pupils to fix problems themselves. In the early stages With block based programming, such as Scratch, this might involve encouraging them to compare their code with the teacher's example or a friend's. It may involve encouraging pupils to try and identify the specific problem area by reading the blocks and seeing if the narrative makes sense. With text based programming languages it may involve checking through a list of common faults types before asking for more help. The first job of the teacher is to help pupils fix errors themselves. In my experience many teachers find this very difficult and need to retrain themselves in this area. It is better to stand back as a teacher in a programming lesson than undermine pupils independence through intervening.

All programmers of whatever level accept that their first attempts at an algorithm or programming solution may be incorrect. In fact it is the struggle to develop a working solution that is intriguing and intellectually satisfying. Whilst it is good for pupils to solve many programming challenges in a lesson, teachers shouldn't be afraid to leave threads of challenge unsolved. These extra hooks can intrigue some pupils and inspire them to work on solutions in their own time. A good programming lesson will have appropriate levels of struggle and wherever possible unfinished elements or unanswered questions to intrigue.

Equally challenging for girls and boys
When I started primary programming, I read an excellent post by the CAS Include group about how some male teachers would refuse to fix boys' programming problems but when faced with girls' struggling with the same issues would provide solutions. I read this with a certain amount of smugness assured in myself that I would never carry out such inherent sexism. However, at a programming club that very afternoon I spotted myself challenging a group of boys who wanted me to fix their programming project to find the solution themselves and then giving a fully formed solution to a similar issue to a group of girls not six metres away. I was horrified that these 1950's attitudes still prevailed in my practice. I have had to train myself out of doing this and the first step was recognising I was doing it. I now have more girls attending coding clubs and everyone is equally challenged and allowed to struggle.

Maths is anticipated, embraced and expanded on when encountered
Programming is a wonderful way to prove that maths concepts work in the real world. Whether it is decimal fractions, angles, coordinates or so many other areas of maths, maths interaction needs to be anticipated and prepared for in an excellent programming lesson. For example if using decimal fractions to reduce the speed of movement of a sprite in Scratch a pre drawn line split into tenths can help illustrate the point. Pupils don't need to understand every aspect of maths to use it, however a good programming lesson will add another layer to their maths understanding.

Teacher who learn alongside their pupils
Programming is wonderfully open ended. I have found over the last few years that pupils are capable of coming up with better solutions than mine on many occasions. I am not the fount of all knowledge, I am a fellow traveller on the road towards understanding. In a good programming lesson pupils know that their contributions are valued and that the accepted perceived solution can be changed or added to by their contribution and celebrated by their teacher.

Procedures to deal with latecomers or absent pupils
Many pupils in primary classes are rushed out for booster lessons. Some form of device to help them catch up helps them to feel valued and avoids them falling further behind. I use catchup cards to help them fill in code they have missed. They won't have as much understanding as those who have fully participated in all of the lessons but their programs will work. This prevents them feeling stigmatised through never having anything finished.

During this article I have also been reflecting on what makes a good module of work but will share that in a later post.

Thursday, April 17, 2014

Flow charts in primary computing science

My first encounter with flow charts was via Flowol, a simple programming tool that uses flow chart symbols to activate simple outputs such as lights and buzzers and enabled you to control these using inputs such as switches and sensors. Three years ago, knowing that I was about to embark on a revolutionary new job teaching computing science in five primary schools, I went out and purchased some flow diagramming templates.
Before I was able to unleash these on the pupils I went to an excellent talk at our CAS hub at Southampton University on programming planning methods. The speaker talked about agile methods of planning and demonstrated noun verb analysis of the programming project to draw out and decompose the problem.  When asked if anyone still used flow diagrams to plan programs in 'the real world' the speaker replied in the negative. However the talk was mainly aimed at teachers about to embark on teaching GCSE Computing Science so I didn't take this as the final word on flowcharts for those working with younger pupils.

Before any draft computing curriculum was designed I experimented with Year 4 pupils (8-9 Years Old)
creating simple flow diagrams to explain school procedures such as what happens when you are injured on the playground. Pupils were able to describe the processes verbally. We kept to just decision diamonds and process rectangles with start and stop terminators. I started by creating a simple breakfast flow chart with the pupils before they went on to work in pairs at the main task. If I am honest it was a real disaster. Pupils were able to sequence but few were able to create a working decision. The most common error was to create a sensible decision but to have both yes and no branches go to the same block. I wondered at the time if the problem was that the task was not common enough so later tried a similar exercise with Year 3 and 4 pupils around getting up and going to school. This was more successful but still significant numbers struggled with creating a working decision.

Children s reading skills are always higher than their writing skills. It struck me that pupils might need
experience of reading and working with fully formed flow charts before they will be able to create one. With this in mind I created five playground games flow charts. Pupils were not taught how to use a flow chart apart from being told that they needed to start at the start. The Year 3 & 4 classes loved this activity and were able to work in small groups to decipher the flow charts. The only difficulty came with some SEN pupils reading ability but mixed ability groups helped with this.

I then took pupils inside and they were given a bugged version of the flow chart. They worked in pairs or threes to try and work out the error. It was fascinating listening to pupils conversations. In Year 4 all but one pair solved at least one bugged flow chart and many groups went on to solve two or three in the 25 minutes we had left. At the end I asked about strategies the group developed. Some said that they had each followed a different path once they reached a decision and then reported back, others that they had all followed the same path so they could check each others findings.

In some primary programming situations I can see the sense of using a flow diagram. A previously prepared flow chart could be shown to help pupils understand a more complex program. I used one when explaining a more complex virtual pet program. Pupils can complete a partially filled in one if it helps to see if they can spot a programming pattern. They can work with programs which are linear such as my clock planning. They are less use in programs that have multiple threads ( lots of things going on at the same time) such as game designing. Here I think a decomposed planner is more useful. 

In conclusion, I would encourage you to give your pupils opportunities to create simple 'everyday' algorithms such as brushing your teeth using basic flow chart shapes first. Then read and debug flow charts second, followed by opportunities to debug them. If you are going to use them to help plan a program I would only use them after pupils have had these earlier opportunities and when the type of programming fits with using this tool. I always ask myself if I am adding an obstacle or a gateway before using a flowchart. Will it just add complexity or aid understanding?

But if my conclusion is too long winded here it is as a flowchart.

Phil Bagge
17th April 2014

Sunday, January 26, 2014

How I teach programming to 7-11 year olds using Scratch

Many years ago I downloaded Scratch and did what I do with most programs, tried to make sense of it through trial and error. After an hour or so I gave up. I had no understanding of the underlying principles of sequence, repetition, selection or how a variable could be used. Pure trial and error left me frustrated and alienated from this wonderful programming tool. I wonder how many other teachers have had similar experiences.

Start simple with everyone
These days I start with very simple programming projects for all KS2 pupils. You wouldn't expect a pupil to understand or use long multiplication without understanding of a number system in place.  My early projects (Smoking CarMusic Machine & Dressing Up Game) link very simple key board inputs or mouse clicks to a single command or simple sequence. Promoting the idea that we can decide what each key does and that the programmer is in control of what the program does. I demonstrate how to connect these and then pupils copy the blocks and test their code. Lots of pupils finish quickly and I then give them specific challenges which use the same type of blocks to do something similar but where I haven’t shown them the solution. They love this! If you have time, projects where pupils re-purpose similar code work well. After our music machine I encourage them to make their own instruments. This also makes a good assessment opportunity.

Link new computational ideas to real world examples
When we encounter selection for the first time I relate this to real world examples inside the Scratch blocks. These examples are not perfect but relate existing knowledge to new. Before the selection parts of the Maths quiz I use theseexamples. When we encounter a repeat x times loop for the first time I get pupils dancing steps. Breaking a popular dance into its basic elements and then choosing notation for each element. Pupils can then design dances for each other combining notation with number of times to use, which is a repeat x number loop in the real world. We then take this knowledge straight back into Scratch.

Run through more complex code examples line by line before demonstrating code
If modelling a program that uses variables, I use a box(s) and pencils/post it notes (depending on context) and go through the code line by line. I do this with lots of programs that include variables. If you just run the code it runs too quickly to see what has really happened. I always get pupils to help me. You can also get pupils to demo their ideas for code by modelling it to you or their peers especially if you know that writing it down will take too long.

Multiple coding opportunities
Don’t fall into the trap of thinking that as you have used selection in one program that you have covered this. This is like using addition once and then thinking that you don’t need to use it again. Selection, repetition, variables are constructs you could take a lifetime to learn how to manipulate. Pupils need multiple opportunities to use and experiment with these ideas. The new English Computing program of study talks about, “repeated practical experience of writing computer programs” in the aims, lets work towards this.

Open ended environments
When choosing a main programming environment choose one that can grow with your pupils and is open ended rather than closed. Choose one where they can learn from others not just you. Scratch is fantastic for this with its excellent online portal. Between the ages of 7-14 pupils can progress from Scratch 1.4 into 2.0 and then onto Scratch ports likeSnap. You can even have different pupils using different versions in the same class depending on need. Be wary of expensive products that offer to solve the ‘Computing problem’ by dumbing down and limiting what can be achieved. What you probably need is good CPD. The CAS (Computing at Schools) website is a great resource for this with lots of quality CPD being advertised every month.

Computing is a fantastic tool for proving Maths concepts
In response to one of my schools need to improve their maths results I started writing Scratch modules which worked with Maths concepts. We have investigated counting using a number machine (IMHO one of my best modules),perimeter after revising greater than and less than. Created programs to calculate the angles of 2D shapes, programs to calculate what coins our change could be given in and much more. I feel I have only scratched (pardon the pun) the surface of what is possible. I though pupils would revolt over creating these rather than games so was really surprised when we had visitors and they choose to show these programs. In the long run you could reap real maths benefits from choosing programming environments that are open ended.

If you are in the South of England why not come along to our Primary Computing Science Conference at University of Southampton on 2nd of April.

If I can help you or your school please don't hesitate to contact me.

Phil Bagge (26th Jan 2014)

Saturday, May 11, 2013

Why teach Computing Science to Primary Pupils

Reflections on teaching computing science to KS2 pupils

In September 2012 I embarked on a new adventure to teach computing science in four schools. The challenge at the time was to build a new curriculum that included programming and understanding how technology works. Two terms in and we have a new draft computing curriculum that includes a substantial portion of computing science. During this time I have learnt the following things.

Programming is challenging and hard. At the CAS Wessex Workshop Miles Berry described it as ‘struggle ware’, this is an apt description. I can honestly say that in the last six months the learning opportunities and degree of challenge that I have provided have far exceeded anything I have taught in ICT over the previous 20 years. I have really enjoyed seeing pupils rise to the challenge.

Programming is very open ended, which is wonderful for pupils but can be scary for teachers who like to stay in control. There will be pupils in your class who have enough time on their hands to learn more than you. We need to embrace this, encourage them to extend their learning even further and harness their expertise to mentor others. This is one area where you are unlikely to be the expert for long. However far pupils extend their programming knowledge they will still need us to build a framework of computational thinking on which they can hang their new found knowledge and understanding.

The degree of differentiation can be enormous. Pupils enjoy a project so they download the software at home and complete the task outside school. Planning for this is important either by careful questioning that draws out the next step, having extension tasks to hand or new projects they can go on too. I often find by the end of a module of work in Year 5 & 6 that I will have small groups of pupils working on their own projects that have evolved from our common starting point.

It’s important not to be too rigid in our definition of those we see as high flyers and those we see as strugglers. As you switch from one type of programming to another, even within the same language, different pupils will shine as the new task grabs their imagination.

Pupils who have enjoyed the ordered sequence of a well thought out quiz may not be the same pupils who enjoy creating a racing game. Giving children a variety of different types of programming is important. Let’s not get stuck creating endless arcade games or we will lose some pupils interest. Programming is often seen as a male pursuit. I have not seen any evidence of this in the schools that I teach despite the fact that as a man I would expect that I am a stronger role model for boys. But then I do go out of my way to try and teach a variety of different types of programming.

Although at university level the greatest indicator of a person with an aptitude for computing science will be their maths aptitude, things are not quite as clear at primary level. Pupils with the greatest capacity for logical thinking do very well. Whether our maths and literacy schemes of work at primary have identified that capacity for logical thinking is open to question.

For some pupils, computation can be their first real taste of using mathematics in a real and applied way. Whether that is using decimal fraction to speed up a costume change or Cartesian coordinates to place objects accurately on the screen, maths is important. A smart teacher will harness their pupils’ new found interest in applied mathematics. We also don’t need to be put off by the advanced nature of some of the maths used. Pupils rarely need to understand every aspect to use it. They are adding another layer to their understanding which I believe will pay dividends in both disciplines.

We need to free pupils up so that they can make mistakes. Too much ICT is taught in a manner in which the correct outcome is expected first time. Pupils then come to believe that they should get everything right first time. The opposite is true in computing science. Most programmers will make mistakes; this is totally normal and part of the process of trial, error and debugging. For many pupils this is liberating to hear. When we combine this with the principles of debugging, finding and fixing their own errors, we enable pupils to be far more independent and have positive coping strategies to find and fix failure.

Some of the best learning takes place away from computers. In Year 3 we debug logo code, by stepping through shapes on the carpet whilst recording them using a whiteboard and pen and dance ‘Gangnam Style’ to help pupils appreciate repeat loops. In Year 4 we design algorithms for early morning routines. In Year 5 pupils write detailed instructions to program theirrobot teacher to create a jam sandwich. Some pupils moan when they realise they will not be using the computers but some of the learning in these sessions is invaluable. I have heard a few people talk about teaching computing science totally without computers, for me that would be boring but the judicious use of unplugged time is important.

Scratch and its new incarnation Scratch 2.0 is a fantastic block based programming that can be used in wonderful ways by primary pupils. It is possible for a few pupils to miss programming by concentrating on sprite and background creation. In a very small number of cases this is down to active avoidance of the programming as it is complex. In most cases it is down to the amount of time that can be taken up by this aspect of the program. I now try and negotiate limits to this side of Scratch. I suggest to pupils that they can create graphics and backgrounds at home if they want much beyond that which they can create quickly. However a teacher teaching the entire computing curriculum may wish to teach graphic manipulation through these aspects of Scratch.

Pupils work best where they can collaborate, magpie ideas and re-purpose them. They may be working individually but the importance of sharing ideas informally shouldn't be underestimated. A lot of programming starts with other people’s ideas that you use and adapt.

Phil Bagge

I work for elearn eteach on Fridays and can be booked to work with your school

Saturday, April 06, 2013

IPod Touch Setup Guide

I published this on Posterous a while back but with Posterous closing down it needs a new home.
IPod Touch Setup Guide Hants

Saturday, November 03, 2012

Should we halve the generalist teacher role in Junior schools?

Pupils deserve the best standard of education in every area of the curriculum. The days of the well meaning junior school generalist teacher are drawing to a close. To survive, prosper and enthuse, teachers need to have complete command of all the subjects they teach.

My recommendation is that junior schools split teachers responsibilities into either Maths, Science, Technology & Computing Science (Maths & Science) or Literacy, humanities, digital literacy and the creative Arts (Literacy & Humanities). Each teacher would teach two tutor groups the same material adapted for the individual needs of the pupils concerned. Many pupils in Junior school are already taught by a team that includes teacher, classroom assistants and learning support assistants, extending this team to include two teachers will not weaken teacher pupil relationships. In larger schools, where there is more timetable space to adapt, teachers would share classes across the same year group. Smaller schools might find teachers teaching more than one year group. Teachers would have less subjects matter to teach and half the planning, leading to more time to keep up to date with current practices.

Teacher training colleges would need to adapt training to reflect this new system. OFSTED would need to widen its scope to meaningfully evaluate a wider range of subjects than just Maths and Literacy. In my opinion this narrowing of importance to just Literacy and Numeracy has been one of the greatest disasters for primary pupils in the last decade.

If you teach in KS2 would you like to teach in this model? Or are you horrified by the idea of losing the generalist teacher role?


Share it