Monday, October 26, 2015

Attitudes to Computing: Dispelling the debilitating myth of the digital native

In every group of primary teachers I work with I hear that, “Pupils know more about computers than us.” Often this idea stems from the theory of the "Digital Native" that people who were bought up with technology are implicitly better at understanding & using it than those who didn't.

When teachers say this It is often accompanied by the statement that I am just learning alongside the children. At first glance this sounds very noble. It recognizes that we are all learning and that information exchange can go both ways. However there are intrinsic problems with the belief and the typical response to it.

The problem with this is that it is at best a half-truth. Pupil access to technology can be very varied in homes from almost identical social backgrounds. Without formative assessment of key skills you won't know what digital literacy skills they are capable of or what they have been exposed to at home.

There is a good research paper on the myth of the digital native here

The wider truth is that there are large swathes of computing that they won't know anything about. Very few have any idea how networks, the Internet and the Web function or how computing devices are programmed. They don’t understand the fundamental computational thinking skills of Algorithm and algorithm evaluation, decomposition, abstraction and generalization. They don’t appreciate sequence, repetition, selection or variable use or the resilience and logical thinking that come from computational doing. Even if they are keen users of web resources few will have inculcated the essential knowledge to develop into safe digital citizens or to question the veracity of information.

The problem for teachers is that if you don’t believe that you have anything valuable to teach because pupils know it all already this affects what you teach and the time you spend resourcing and planning it.

Teachers and school leaders who believe the myth of the digital native often find excuses to leave computing out of their timetables. When they do teach computing they tend to rely very heavily on unplanned exploration and they justify this by recourse to the shared journey narrative.

I wonder if they would be happy to learn Maths or Literacy alongside their pupils in this same woolly way?

Please don’t think I am attacking exploration, it’s a fundamental part of a good computing lesson but it needs to be balanced alongside instruction in some form(1). Instruction assumes that there is knowledge and skills worth teaching to pupils.

By way of balance too much instruction without any exploration leads to shallow learning, concepts grasped at but not internalised fully.

We can sum up this fundamental balance like this.

In conclusion as leaders in computing in our schools it is important to challenge the debilitating myth of the digital native and promote curricular that includes instruction and exploration.

For a humorous secondary school look at the myth of the digital native @codeboom article is well worth a read.

(1) The form of instruction should always be down to the needs of the students and the professional judgement of the teacher. Instruction can be as diverse as creating knowledge videos favoured by the flipped classroom model to whole class teaching.

Wednesday, February 11, 2015

Eight steps to promote problem solving and resilience and combat learnt helplessness in computing

In my experience learnt helplessness is particularly prevalent in Computing/ICT. In the last three years I have taught nothing but computer science in six primary schools, over 1200 hours and have seen learnt helplessness in varying degrees in all of my schools.

In this article I will look at what learnt helplessness is and how it will manifests in computing lessons. I will also suggest reasons as to why pupils have learnt this strategy and offer ways to promote independence, resilience and problem solving. I will also look at how learnt helplessness can also manifest in teachers and teaching support staff and suggest ways to help them move on.

Learnt helplessness is a strategy for getting other people to solve problems for you. In the classroom, for pupils, these others may be the teacher, LSA, classroom assistant or other pupils.

In computing/ICT learnt helplessness can be seen in various ways. Sweet helplessness often manifests to the teacher as a pupil putting on a sweet helpless voice and declaring they are stuck. Aggressive helplessness manifests with a cross tone and the implication that they think the work is ‘stupid’ or they don’t get it. Being stuck is never a problem but if you ask what they are stuck on and the pupil cannot tell you or describe the problem or they give vague indications that they are stuck on everything then there is a good chance they are using learnt helplessness to get you to solve their problem. Similar strategies will often be used with their peers, tailored to make the problem solver feel valued, superior or pressured into helping.

The problem is that many teachers and pupils will respond to this strategy in Computing/ICT by solving the problem for the pupil. Often excellent teachers, who wouldn't dream of doing work for pupils in other areas of the curriculum, will jump in and solve the problem for the pupil. The fact that so many pupils use learnt helplessness suggests that it has been a successful strategy for many.

Getting someone else to do your work for you would be an issue in any subject, but it is the antithesis of computing science with its emphasis on problem solving and debugging. In fact to solve a problem for a child is to deny them the opportunity to debug code or fix algorithm and as such is debilitating.

How has it become so prevalent in computing/ICT? I suspect that it has grown out of teacher fear or unfamiliarity with the subject material coupled with a belief that pupils know more about technology than adults combined with an emphasis on the finished product rather than the process. All of these factors lead teachers to fix things for pupils rather than steer them to find solutions for themselves.

If we recognise this as an issue, how can we counter this and encourage resilience and problem solving?

1, Recognising that this as an issue is the first step. We can’t effect any change without recognising that something needs to change.

2, It helps to know that this will take time both to change your own practice and move pupils onto better strategies. I estimate it took me several months to change my own practice and about five weeks to change pupils in KS2 where learnt helplessness had become a way of life.

3, It is very important to establish a positive class attitude towards problem solving. Computing science is very useful in that it calls errors bugs and finding errors debugging. Although all bugs are caused by humans, the language is much more impersonal than mistakes which imply blame or fault. Using bug and debugging language is helpful. It is also important to let pupils know that mistakes/bugs are a normal part of computing, that they are to be expected, that professional programmers write code that have bugs all the time and that you will not be cross or upset if their work has bugs/mistakes. This for me is a mantra for new classes for the first few weeks and once they know I mean it there is collective sigh of relief!

4, Alongside this I also promote the idea that it is not my job to fix their algorithms or debug their code. It is my job to promote useful strategies that they can use to fix things themselves. So when they come to me they know they are looking for strategies to find and fix things themselves.

5, For those pupils transitioning from learnt helplessness to useful problem solving they need to see what they are doing. I have asked pupils; ‘are you trying to get me to fix your code?’ ‘Are you trying to get me to solve the problem for you?’ In the same way that we couldn’t move on until we recognised the issue, some pupils won’t either. Of course good teachers do this tactfully and with regards to pupils known issues but an element of challenge is inevitable to identify the issue.

6, Encourage the class to join you in this by putting a ban on doing things for other people. They can describe what to do but are not allowed to do it for them or give them a full solution to programming solutions. As you model this they will reflect this attitude to their peers. Having a ban on touching anyone else’s mouse, keyboard or touchscreen is a good start. I often compare this to writing in someone else’s maths or literacy exercise book.

7, Move pupils away from language that personifies digital machines. “My computer hates me,” is typical. Miles Berry describes computers as deterministic which means that if all the inputs are the same you will always get the same output. Personification encourages pupils to think that an answer might not be available due to the capriciousness of the machine, an attitude that is anti problem solving and frankly incorrect.

8, Don’t neglect the other adults in the class, all your good work could be being undone by your LSA or classroom assistant. Train them to help using good strategies and hints rather than solutions. If you are providing training on the new curriculum don’t neglect your class room assistants, they are important.

Finally you may notice learnt helplessness in teachers and learning support assistants. Is it worth the hassle to challenge this? As a parent I know that my children don’t do what I say but what I do. I lead mostly by example or lack of it as my wife will testify. This is just as true in the classroom or computer suite. Of course we need to be tactful and recognise the good practice of teachers and the excellent problem solving strategies in other curriculum areas, but if we don’t identify the problem, nothing will change. I have found that talking about my own struggle to change has enabled others to do likewise.

Sunday, September 21, 2014

Computational Thinking in the Primary Computing Curriculum

Over the summer I have been reflecting on what computational thinking is and how it affects primary computing understanding and practise. In this short article I am going to look at the following questions.
·       What is computational thinking?
·       Who first thought of the term?
·       Is it a new idea?
·       What thinking skills are included?
·       What do these thinking skills mean for primary pupils and teachers?
·       Computational thinking in the Computing National Curriculum
·       Cross curricular?
What is computational thinking?
Wikipedia2 describes it as “problem solving method that uses computer science techniques”
ITSE1 in their article on computational thinking describe computational thinking as critical thinking ideas combined with the power of computing. They also have a short video to help define it which is worth viewing 1a
Who first thought of the term?
The first3 person to popularise computational thinking and call for computational thinking skills to be taught to all was Jeanette Wing,4 a prominent American computer scientist. She argued that, “To reading, writing, and arithmetic, we should add computational thinking to every child’s analytical ability.”5
Is it a new idea?
The idea that problem solving methods used by computer scientists should be taught to every child is relatively new (2006) however the toolkit of useful critical thinking tools are much older.
What thinking skills are included?
Computer scientists and educationalist are in broad agreement as to what should be included. Miles Berry6 included algorithms, decomposition, patterns, logical reasoning and abstraction. A recent CAS working group included algorithmic thinking, evaluation, decomposition, abstraction and generalisation in their very helpful framework document7.
What do these thinking skills mean for primary pupils and teachers?
I am going to limit myself to the CAS working group list of computational thinking skills as I find these particularly helpful.
Algorithmic Thinking
Defining a precise set of instructions or rules to achieve an outcome or solve a problem. A recipe can be an algorithm, musical notation can be an algorithm. Instructional writing can be an algorithm. All working computer programs started life as human ideas that were expressed as algorithms in thoughts, words, symbols or flow charts. Programming is the challenge of turning precise ideas (algorithms) into code that can be read by a machine. When we define a precise set of instructions we save time as this algorithm can be reused to solve a problem over and over again and adapted to solve similar problems.
Evaluation is how we look at algorithms and determine how useful they are, how adaptable, how efficient, how correct. There may be many algorithmic solutions to a problem, evaluation asks which one was best and why? Evaluation is also concerned with the people who use an algorithm. Did it solve their problem? Was it better on paper than in practice? Evaluation is also a very useful skill to extend into programming as well. Getting pupils to think about an end user in the design (algorithm) stage can help focus ideas. I think there is a lot of similarity between logical thinking in the national curriculum and evaluation.
Decomposition is the skill of breaking a complex problem up into smaller manageable chunks and solving these chunks separately. I have found this to be a wonderfully useful skill in games design. Faced with the task of creating a new game8 pupils are often overwhelmed by the amount to think through. We use a decomposed planner where they jot down what they want the game to do first before circling objects and ideas and describing these in detail. This allows them to focus on designing a small parts of the game separately before recomposing these ideas into the whole.
Abstraction is the skill of reducing complexity by hiding irrelevant detail and focussing on the most important element. This is a really useful computational skill as once the irrelevant detail has been stripped away computer scientists can focus on what really needs doing. Imagine I wanted to turn the game matching pairs into a computer game. The most important element is; you win if items are the same. This can be abstracted further into A = B win, A ≠ B lose. We recently used abstraction to turn a musical sound track on a video into an algorithm and then into musical programming in Scratch. We started by listening to a video and identifying all the elements on the video, singing, high and low pitch notes, moving pictures, backing track etc. We then looked at what detail was important to turn into notes on Scratch and what was irrelevant. We ended up only keeping the high and low pitch notes. We swapped to a much simpler music track with notes only and listened to this to write a musical algorithm before converting this into code.9
Generalisation is adapting a solution that solved one problem to solve another. In our abstraction example earlier we reduced matching pairs to A = B win A ≠ B lose. We could then use generalisation to adapt this solution to think about creating a quiz. In a quiz, if the answer we have thought of is the same as the users answer we say it is correct. If the answer is not the same we say it is wrong. This is almost identical to A = B win A ≠ B wrong so we can adapt one solution to solve a similar problem. In our Scratch perimeter program10 we discover a simple way to calculate the diameter of a circle by multiplying the radius by two. Pupils then use the principle of generalisation to adapt this solution to calculate the perimeter of regular 2D shapes.
Computational Thinking in the National Curriculum
The opening statement of the introductory paragraph of the 2014 computing national curriculum11 says, “A high-quality computing education equips pupils to use computational thinking and creativity to understand and change the world.” This is a wonderful opening statement which highlights the importance of computational thinking. I also like the way it highlights that computer science is both a science and an engineering discipline. Understanding the world is a scientific endeavour and changing it is an engineering one. Computer science doesn’t just think about things it turns this thinking into digital artefacts to be tested and evaluated by society.
In the aims we find mention of abstraction, logic, algorithms and evaluating and the exhortation to “analyse problems in computational terms, and have repeated practical experience of writing computer programs in order to solve such problems”
In KS1 we find mention of algorithms and logical reasoning. In KS2 we find decomposition and logical reasoning. In KS3 abstraction, algorithms and logical thinking are included.
I see the national curriculum as a minimum entitlement and would urge teachers to make full use of the full range of computational thinking skills when they are appropriate.
Cross curricular?
The good folk at the Barefoot12 project are developing some cross curricular computational thinking activities and I think it is a laudable aim to include computational thinking ideas into the wider primary curriculum. In my resources I have mainly focused on computational thinking through algorithm design and programming. I think ideally we should do both. Recognising that these ideas are special because they have grown out of computer scientists desire to create artefacts and systems to evaluate and change the world but that there is real traction in understanding that is broad and multidisciplinary.

1 David Barr, John Harrison, and Leslie Conery (2011). “Computational Thinking: A Digital Age Skill for Everyone”
3 Seymour Papert mentions computational thinking but doesn’t really expand what it means or call for these skills to be taught to all. However I haven’t read all of his works so am happy to be corrected. He mentions computational thinking in "An exploration in the space of mathematics educations". International Journal of Computers for Mathematical Learning (1996) I couldn't find a comprehensive treatment of computational thinking in this journal.
5 Jeanette M Wing Viewpoint (2006)
7 Professor Paul Curzon, Mark Dorling, Thomas Ng, Dr Cynthia Selby & Dr John Woollard (2014) Developing computational thinking in the classroom: a framework (second document link on right)
8 Primary Games maker planning including decomposed games planner
12 Barefoot Computing Project


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


There was an error in this gadget