5 mistakes I made when teaching Computing - Ten Year Review

5 mistakes I made when teaching Computing

This article originally appeared in Terry Freedman's Digital Education Newsletter in July 2016 and was published to his site in October 2016 . I was invited to write an article to discuss my experiences of teaching Computing over the last ten years. I am grateful to Terry Freedman for his editorial advice and for providing a platform for the original article. It is reproduced below as it appeared in the Digital Education Newsletter.

“ Nothing fails like success because we don’t learn from it. We learn only from failure” –Kenneth Boulding

Digging in

Looking back on the last ten years, I’ve learnt a significant amount about teaching and pedagogy. Based on Kenneth Boulding’s statement, this implies that I’ve failed on numerous occasions whilst teaching Computing. This is true and these mistakes are something I’ve learnt to embrace and reflect on somewhat obsessively.

Doug Lemov, in his brilliant book Teach Like a Champion* covers a technique called “Excavate Error”. He encourages teachers to “Dig into errors, studying them efficiently and effectively, to better understand where students struggle and how you can best address those points”. I think there’s great mileage in this technique, not only to help our students but also to help ourselves as reflective teachers. In this article, I will look at five mistakes I made whilst teaching Computing.

Mistake 1: Making learning easy and effortless

During my first year of teacher training, I visited many classrooms. At the time, I was lucky to be in a school with more than ten Advanced Skills Teachers (ASTs). These were excellent teachers with a subject specialism, who had chosen to continue to develop their teaching in the classroom, rather than pursue pastoral or managerial leadership roles in school. Needless to say, these teachers had impeccable behaviour in their classrooms and the students seemed to be progressing at an impressive rate; naturally then they possessed a somewhat revered status.

I remember going into one Religious Education class run by one of the school’s ASTs, Joanna. The class was studying Buddhism and in order to get them to empathise with Buddhist meditation, she asked them all to close their eyes and for five minutes, the students meditated in silence. I had just come from a lesson in which it took more than five minutes just to get my students logged on and facing the board! The students then returned to the present moment and wrote in silence for 10 minutes about their experience and why they thought Buddhists chose to meditate several times a day. I was impressed and for many years, I aspired to be just like Joanna, running a silent classroom where everyone was “working hard”.

To facilitate this hard work, I thought that I should help my students by making the challenging tasks easier. By scaffolding all the tasks so that they could complete them effortlessly. I held the false belief that effortless perfection was what a teacher should be aiming for. The reason this was such a big mistake is that quiet classrooms are a very poor proxy for learning. Graham Nuthall discusses the challenges of knowing what students have learnt in his book, The hidden lives of learners*. Dylan Wiliam would argue (based on a course I attended) that a quiet classroom could simply be one where nobody is being stretched, where students are bored or where students are afraid of taking risks. Paul Black and Dylan Wiliam’s work on formative assessment and assessment for learning in Inside the Black Box* and, especially, Embedded Formative Assessment*, tells us that the best proxies for learning need to make the learning visible. A few solutions that they suggest are using mini whiteboards, exit tickets and traffic lights to quickly see what the students are thinking.

Mistake 2: Should learning be easy?

The second mistake I made was thinking that learning should be easy. The Sutton Trust commissioned Coe et al to perform research on What Makes Great Teaching and found that:

“One paradoxical finding is that some approaches that may appear to make learning harder in the short term, and less satisfying for learners, actually result in better long-term retention.”

Mistake 3: Too helpful by far?

The third mistake I made was scaffolding the learning for students with Low Prior Attainment (LPA)  and then allowing them to become reliant on the scaffold for the remainder of the year. I remember printing out step-by-step worksheets for many students whilst teaching Spreadsheets, Databases and Control and the students would become reliant on these worksheets. Every lesson, students would ask for the worksheet, without trying the task first. David Didau and Oli Knight advise that in order to develop independent learners, scaffolding should only be provided if there is a plan for taking this away later on in the unit of work.

Moving on from there, I now accept that lessons and learning may not always be effortless and smooth. I accept that students might struggle sometimes. Many concepts in Computing are quite abstract. Explaining the difference between a For Loop and a While Loop for example or explaining the use of Master Slides in presentations are both quite challenging concepts to grasp. However, I have taught my students to embrace the challenges, struggles, setbacks and mistakes; it shows that we are trying hard and therefore learning.

To make my students more independent, I ask them to use the SPOT framework:

•        Self – Try solving the problem independently

•        Peer – Ask your peers sat near you

•        Other – Research the solution using other resources e.g. Online, video tutorials, worksheets and notes

•        Teacher – Lastly ask your teacher.

Other teachers use the 3B4Me model which is very similar, going through the Brain, Buddy, Book and lastly Boss.

This helps students become more independent and whilst the scaffolding might still be provided through a video tutorial which can be made using free software such as Open Broadcaster Software (OBS),  these tutorials or worksheets are the third option, only after they have tried solving a problem themselves and also attempted to get help from their peers. Examples of YouTube tutorials that I use in my lessons can be found here.

The Expert’s Trap

Noel Burch developed a model citing the four stages of conscious competence. 

Via @ pgballey on Flickr Creative Commons Attribution License: https://www.flickr.com/photos/pgbailey/6429568067

For many Computing teachers, they are teaching skills which they are already unconsciously competent. At this level, we might be considered experts and the expert’s trap is to attempt to teach something without explaining it fully. Collins et al. wrote a paper about Cognitive Apprenticeship in 1991, where they state the importance of making the thinking visible by thinking out loud.

In applying this to Computing, many of the tasks we do and know are implicit. An example of this is closing a tag in HTML as soon as we open it. However, unless we make these implicit habits explicit, our students will be lost as they will not be able to make the invisible conceptual leap that exists in the minds of their expert teacher.

Mark Guzdial, Professor in the College of Computing at Georgia Institute of Technology suggests that we should also teach the misconceptions. Predict misconceptions, test students on these misconceptions and teach them where they are likely to fail. This way, students can learn from our mistakes and we can minimise the number common mistakes that students make when learning these skills. He references Phillip Sadler: http://news.harvard.edu/gazette/story/2013/04/understanding-student-weaknesses/ 
“If teachers are to help students change their incorrect beliefs, they first need to know what those are…The results showed that students’ scores showed the most improvement when teachers were able to predict their students’ wrong answers.” -- Philip Sadler

In Computing lessons, I now try my best to model not only a skill but also my thinking. Thinking aloud feels very unnatural at first, but the gains are immediate and will be apparent in all lessons where you model the new skills well. Frequently, when I reflect on lessons which went less well, I realise that there was an issue with my modelling in that I forgot to think out loud and my students were lost in the silence of clicking and demonstrating.

Computing=Programming=Coding

The media frequently use the terms “Computing”, “Computer Science”, “Coding” and “Programming” interchangeably and most headlines about the curriculum reforms in the UK have used these words synonymously. This distorts the reality that programming is a skill which all Computer Science students will need to learn, but it is not the only skill which is required in Computing. Programming pedagogy is an important part of a teacher’s Pedagogical Content Knowledge. However, equally important are other key software applications and the theoretical subject knowledge which the Computing curriculum is built on.

Mistake 4: An emphasis on the programming language

When I first started teaching at my current school, I focused a lot of time and energy in teaching students how to program using Python. That was the programming language that they would eventually use for their GCSE controlled assessment which would make up 60% of their GCSE grade (for non-Brits: GCSE is the General Certificate of Secondary Education, which is usually taken in several subjects at 16 years of age. It is a school-leaving certificate, or a passport to further study).

This decision was somewhat shortsighted, because what I realised is that the programming language is not the most important thing, neither is syntax. As I reflected back on two years of teaching programming with Python, I realised that the key threshold for learning how to program and to pull students out of liminality (transitional/borderline stage) is in teaching the students the importance of logical thinking. The key to ensuring that a program works (regardless of the programming language) is the logic and the Computational Thinking. Teaching students the process of how to break down a real-world problem down into a problem that can be computed is the key to successful programming. This is where the focus should be when teaching students how to program.

Mistake 5: Not seeing the bigger picture

However, this in itself only solves part of the problem. In 2015, the qualifications regulator for England, Ofqual announced a curriculum reform which resulted in all Computer Science Controlled Assessment from 2017 onwards to be worth only 20% of the grade. Fortunately, by then I had realised that I should be focusing on other skills, concepts and knowledge besides Computing and had started to build a more-balanced curriculum map.

In designing a Computing curriculum, I have learnt not to focus too much on trends and exam boards. But instead to produce a more-balanced curriculum which will provide students with the ability to use digital technology creatively and independently. There is still a need to plan backwards from terminal exams, however the way in which we do this has to be measured and has to ensure sufficient spacing and interleaving of content. Medium term planning is itself a significant area which cannot be covered in sufficient detail in this post. However, it is something which I am happy to advise on by email or in-person. I will also be dedicating a chapter of my upcoming book to the topic.

Conclusion

To close, I would encourage all teachers to keep reflecting on their teaching, to embrace and learn from the setbacks, challenges and mistakes that we encounter every day. I’d also like to thank all the teachers that have helped me become a better Computing teacher. There are countless teachers within the Computing at Schools Network. However those that deserve a special mention (in alphabetical order) are the following. The links given are for their Twitter profiles.:

•        David Batty

•        Danny Brown

•        Simon Brown

•        Mark Clarkson

•        Dan Copeman

•        David Didau.

•        Corinne Flett

•        Mark Guzdial

•        Elizabeth Hidson

•        Peter Kemp

•        Joe Kirby

•        Oli Knight

•        Doug Lemov

•        Giles Niklaus

•        Simon Peyton Jones

•        Dylan Wiliam

•        Tom Wilkinson

About William Lau

William Lau is the Head of Computing at Greenwich Free School. Having trained through the Teach First program in 2006, he has taught Computing from Key Stages 1 through to 5 in two London schools and in an international school in Seychelles. William is currently writing a book on Computing education and pedagogy.

To enjoy further insights from William, follow him on Twitter: William Lau.

* Links marked with an asterisk are Amazon affiliate links.

7 Mistakes I made whilst teaching Computing and what I will do differently next year

Three years ago, the landscape for ICT teachers in the UK began to change. I realised that I would need to adapt to teach Computing, specifically Computer Science as the policy documents seemed to suggest that this was where the future of ICT was going. I’ve spent the last 2 years teaching Computing with a strong bias towards teaching Programming. This is what I’ve learnt so far.

Rote learning and testing

Some things are best learnt by rote. Programming is not one of them. Multiplication tables and French irregular verb endings are something which you will just have to remember. However, a function to calculate a multiplication table in Python is not something that any professional programmer would spend time memorising by rote. I remember when I first tested students, I expected them to produce working programs without referencing their prior programs or even using the Web. This is how controlled assessments and exams work in (say) Science so why not Computer Science. The reality is that, it’s not realistic or indeed necessary for 11 year old students to remember the exact syntax for sequences, selections or iterations. It’s not necessary at GCSE or A-Level (or even for professional programmers and software developers) to remember their past solutions. I did not know about this until I went on exam board training!

My leveraged observation coach had once advised me to use SPOT to make students more independent and I now consider it a vital tool for teaching programming.

Self-Persevere, be resilient and keep debugging because every failure is one step closer to success

Peer-Use your peers, ask the people sat next to you.
Other-Use other resources. All good programmers use their old code, websites (including Youtube), documentation and forums. Because there are very few problems which other programmers haven’t tackled already.
Teacher-The teacher is your last resort! He or She will be understanding and helpful provided you have exhausted all the steps above.

Expecting students to produce the same correct answer

In many Sciences, there is only one correct answer. Computer Science deceives us in that there is rarely only one correct answer! Linked to the previous mistake I made, I spent a lot of time in my first year by focussing on the correct solution.

Too much programming and too soon!

I was anxious to teach my students programming in their very first term in Year 7 for fear that they would not be able to complete their Controlled Assessment in three years’ time.  Looking back, it is quite surprising that despite my insistence on drilling the importance of Python syntax, indentations and parentheses, my students still loved programming. I think it was because of the way the subject was sold. They knew that very few 11 year olds across the country were also writing programs using Python at the time.

Whilst learning a programming language is an important part of Computing, something else needs to come first! My students were generally enthusiastic and enjoyed programming, but the focus was all wrong. JeannetteWing and Mark Dorling frequently speak about Computational Thinking and it is only after two years that the penny finally dropped for me.

In Mark Clarkson’s unofficial guide to Teaching Computing he provides the following advice for new Computing teachers:

"For the first half-term we do nothing but logic problems without going near a computer (search CAS Online for good examples) and in the second half-term we look at basic Python programming, covering input, output, variables, assignment, if statements and loops (WHILE and then FOR)…"

Jonathan Torbitt’s curriculum also reflects this, with a focus on problem solving first and programming syntax second:

Many other successful departments follow this approach of teaching the problem solving through Computational Thinking before teaching any programming.

In summary, do not rush to teach students the syntax to a programming language. Teach them decomposition-how to break down problems into smaller ones first decomposition. Then see if they can recognise any patterns-have they solved something similar before? Is there any repetition within the problem? Get them to strip away un-necessary detail and form a general model-this is called abstraction. Lastly, before students start programming, they need to plan their algorithms i.e. they need to solve the problem by planning it step by step.

Planning for success instead of failure

We all write assessments and then test it out on ourselves to see if we can do it, we’re planning for success and expect students who work hard to score 100%. Yet when students fail, we wonder why and we wonder why they all make similar mistakes. Mark Guzdial has applied an alternative approach based on Philip Sadler’s research at Harvard University. This approach involves the teacher completing an assignment themselves and trying to figure out what are the most likely wrong answers i.e. the most common ways in which students might fail or misinterpret a question. Essentially, what you’re doing is finding out all the common misconceptions and planning for these in your teaching. Philip Sadler’s research suggests that this one skill is what differentiates the best teachers from the rest:

“If teachers are to help students change their incorrect beliefs, they first need to know what those are…The results showed that students’ scores showed the most improvement when teachers were able to predict their students’ wrong answers.”- Philip Sadler

Only rewarding success

“The first thing to realise is that programming is a difficult and different skill. Students are not used to struggling, solving their own problems or repeatedly failing. They have spent 10 years or more learning to give the correct answer, and if they didn’t know it, then to learn it…

… In programming, students need to try, to fail, to realise that the sky has not fallen on their heads and to try something different. It is incredibly difficult to watch a student struggle and not dive in with the answer, but the process, the techniques and the strategies are far, far more important than simply getting a program that does what you want.”-Mark Clarkson

Computing is a unique subject in that you will spend more time failing than you do succeeding. Mark Guzdial’s advice is to create an environment where it’s OK to make mistakes. Let students know that even their teacher will make mistakes. David Batty likewise emphasises how important it is to fail in front of your students and not to over-plan your code so that it is bug free. Do the programming live and debug it live. Nobody in the world can program without making mistakes. Mistakes are teachable moments; Guzdial goes on to state that you should then talk through your debugging slowly- This is what I thought, this is what I want the code to do, this is what I will try next. Referencing Collin’s research on CognitiveApprenticeship, Guzdial states that thinking aloud plays a pivotal role in helping students become better programmers.

Karen Hume takes this rewards approach further by stating that we should reward less and celebrate more. Rewards can create a ceiling; once a student has been rewarded for success, they stop because they see success as a destination instead of a journey. Rewards also signal that the learning has not intrinsic value. By praising effort and celebrating student’s debugging, we’re more likely to develop successful programmers with a growth mindset.

But what about success?! We’d be lying to ourselves if we did not acknowledge that success is important and Brad Miller and David Ranum suggest the following for new programmers:

1) Start Small. This is probably the single biggest piece of advice for programmers at every level. Of course it’s tempting to sit down and crank out an entire program at once. But, when the program – inevitably – does not work then you have a myriad of options for things that might be wrong. Where to start? … How to figure out what went wrong?... So, start with something really small. Maybe just two lines and then make sure that runs ok. Hitting the run button is quick and easy, and gives you immediate feedback about whether what you have just done is ok or not. Another immediate benefit of having something small working is that you have something to turn in. Turning in a small, incomplete program, is almost always better than nothing.

2) Keep it working. Once you have a small part of your program working the next step is to figure out something small to add to it. If you keep adding small pieces of the program one at a time, it is much easier to figure out what went wrong, as it is most likely that the problem is going to be in the new code you have just added. Less new code means it’s easier to figure out where the problem is.

This notion of Get something working and keep it working is a mantra that you can repeat throughout your career as a programmer. It’s a great way to avoid the frustrations mentioned above. Think of it this way. Every time you have a little success, your brain releases a tiny bit of chemical that makes you happy. So, you can keep yourself happy and make programming more enjoyable by creating lots of small victories for yourself.

Pedagogy
Undergraduate Education != Secondary Education

We cannot expect eleven year olds to learn the same as we learnt at degree level or whilst programming in the real world. Providing a lecture and then expecting students to apply this material in the lab is a highly ineffective way to teach programming at Secondary school. The pedagogy for teaching programming is completely different. Guzdial’s research shows that 3 things certainly work: Paired programming, Peer Instruction and Media Computation. Clarkson has found that the following works well in his classroom:

Regular programming homework tasks and paired programming challenges during lessons ensure that students keep practising, and in a safe and secure environment where it is OK to fail. In fact failure must be celebrated as it means the student in question has moved one step closer to a solution.

Balance and flexibility
Computing != Computer Science

Computing consists of three strands, Computer Science, Digital Literacy and Information Technology. I knew this as I spent a whole year meeting Teach First ICT teachers in a focus group setting and we established that teaching only one of the three strands would be short-changing our students. The current Computing Curriculum also reflects this with all three strands equally weighted.

With exam pressure however, I have undoubtedly spent 70% of the year teaching Computing, specifically the OCR syllabus for GCSE Computer Science. My rationale was that if they start in Year 7 or 8, by Year 11 they’ll be flying. Luckily, I started early and have had ample time to learn from my mistakes! The biggest mistake has been teaching to the exam, the assessments change and even our department’s GCSE options have changed. Having visited three successful Computing departments, I have learnt that it is important to offer a balanced curriculum from Key Stage 3, all the way to Key Stage 5. In September 2016, we’ll be offering GCSE ICT alongside GCSE Computer Science and as a result, I will be re-planning Key Stage 3 to reflect this. I know that ICT won’t last much longer in its current state but this serves as a reminder to be flexible; plan for balance and plan for change.

Most of this post is about Pedagogy and is based on my own experience and the articles/videos linked throughout the document and below. I wrote a similar end-of-year reflection post last year which focussed on the logistics and practicalities of setting up a Computing department, you can read about that here.

Essential reading/viewing:

Mark Guzdial’s advice for Computing teachers:

Mark Clarkson’s unofficial teacher’s guide for GCSE Computing

Mark Guzdial introduces Media Compuation

Brad Miller and David Ranum’s guide to successful programming part 1

Brad Miller and David Ranum’s guide to successful programming part 2

BBC Bitesize guide to Computational Thinking

My Curriculum Map for 2015
My Department Handbook (work in progress)
My Year 7 and 8 Resources

Metaphors for Computing - A collaborative project

Many teachers have come to realise the power of metaphors. If this is not something you've tried or if you are slightly skeptical, I highly recommend this blog post by Alex Quigley (@HuntingEnglish).

I've found metaphors particular helpful in Computing as there are so many abstract ideas and concepts. Metaphors, analogies and similes certainly make these concepts much more accessible to our 11-13 year old students!

I've started creating some slides to document these and invite other teachers of Computing to contribute.

Click here to edit/contribute or feel free to browse through the metaphors and comment below:

1`

Key Dates for Computing

Here are some useful dates to keep in your diary. You can use these to plan units with a specific focus:

01/09/2014	Web We Want Festival (Ends May 2015)
27/09/2014	Tim Berener's Lee In Conversation
14/10/2014	Ada Lovelace Day
08/12/2014	Computer Science Education Week
10/02/2015	Internet Safety Week

Please comment if you have other suggestions.

Learning to get better

We've been waiting for a return visit from HMI for the past three weeks. In preparation, we've had two inspection teams from Outstanding schools and an actual HMI come in to look at the school.

Initially, the workload increased massively in preparation for the inevitable monitoring visit. However, looking back I think it's all been worth it. As I've mentioned in a previous post, you cannot possibly prepare for an HMI visit in 24 hours or even a week, it takes weeks if not months and therefore I think the mock inspections have not only provided us with time to prepare but also lots of practice.

In preparation, I've started filming a lot of my lessons. I teach 8 classes and I think I've filmed 5 of them so far. It's been quite insightful. There are a few things I've learnt from watching this footage back:

-There are a lot more hands up than I realise

-Body language matters a lot
-Formative assessment works

As a result of the first of these issues, I've put more of a focus on modelling during the Do Now and before the main activity.

In addressing the second issue, I've been more aware of when I'm giving instructions, where I am and how I deliver these instructions. Certainly the worst way to deliver them is sat down! I've also noticed that in some cases I have been leaning or supporting myself with a chair or the mobile white board! I'd be the first to admit that this is not the kind of body language that is favourable for information transmission or simply getting the attention of kids. I corrected this and am more conscious about this than ever before.

Amy Cuddy's brilliant talk discusses the importance of body language in more detail:

On a more positive note, I found noticed that traffic light cards and mini whiteboards, simple as they are work well. By forcing students to have 100% participation, everyone has to think to respond and therefore will learn a lot more. Linked to student participation, our observers also noted that we should script our questions more. The only way you can use questioning effectively is if you plan the question and plan who you will ask it to. This way your expectation of a student response (no opt out) can be met in the first instance.

I've told my students that the last few weeks of term are simply to improve by doing corrections on our exams. I've opened our lessons with quotations and these two quotes seem the most apt:

“Improvement begins with I.”
Arnold H. Glasow

“It’s through mistakes that you actually can grow. You have to make mistakes in order to improve”
— Paula Scher

Looking ahead to Monday's monitoring visit, I'm feeling confident because I've made so many mistakes in the past 3 weeks and indeed over the past year that I've learnt a lot and improved my teaching as a result. Looking back over the year, it is the most difficult and daunting things in teaching that offer the most benefit. Line management observations, filming yourself and being scrutinised by 3 different sets of external inspectors in 3 weeks have all been challenging and at times slightly uncomfortable. However, every significant success I have had this year has come about through either one of these forms of observation or the reflection/debriefing on these afterwards.

Lessons learnt from setting up a new Computing department

This post is a reflection on my last 12 months as the lead teacher of a new Computing department. As I transition to the role of Head of Department, there are many things that I have learnt, wish I knew from the beginning and things that I would do differently.

Curriculum

Curriculum- I would aim to teach a GCSE shadow structure right from Year 7. There is no reason why 11 year olds can’t start with Python. Even students with severe SEN including ASD have managed to write simple programs in Python. Some may argue the case for Scratch or Snap!(BYOB), but to be honest most kids will have used these a lot at primary school, things like LightBot and Blockly are a much better gateway to text-based programming. I would however only spend a short amount of time on these.

Likewise, teach your students GCSE theory up to GCSE level, most of our students understand Von Neumann Architecture and can convert between binary, hex and decimal. It just takes solid structures, but with the correct structure and support, the kids can learn anything.  

Teaching and Learning

Get observed lots, bad observations are good ones because they should inform how to improve. Observers (including support staff) often see things that you don’t see. My worst lesson observation was followed by a debriefing where I reflected with my line manager. We spent some time rethinking my pedagogy and how to deliver a lesson with lots of content. The result was that in the following observation, my line manager said that he observed the perfect lesson.  He shared some of the techniques with the rest of the school.

I can’t emphasise how valuable it is to work closely with your support staff and technicians; on any given day they will make the difference between a lesson that works and one that doesn’t.

Observe your peers in non-graded observations. Visit other schools, find the best people on Twitter or at Computing events and just ask to go and see them. Visiting other schools is always inspirational, either they’re doing great stuff that you don’t yet know about or vice versa. You’ll always end up leaving in a positive and productive mood.

Make a website to host all your documents, cover work and showcase material. Some like to use Google Sites. I value aesthetics so I use Weebly and combine this with Google Docs and Tiny URL. When students miss a lesson, their first port of call can be the school website. Some argue for a VLE or network, but nobody likes logging in and if your student is ill at home, a website is the easiest thing to access and Google Docs offers the most streamlined solution for hosting and sharing documents with colleagues and students.

Google Docs is also great for creating tests which mark themselves. I’ve heard a lot of good things about Edmodo, in that it corrects students answers too. I like the sound of that and may try it next year.

In terms of formative assessment, print out name tags for every student, Get some traffic light cards laminated and buy a class set of mini white boards. These will guarantee that you know what the students actually know during your lesson. According to Dylan Wiliam, what you do with this information is the difference between average and great teaching.

Logistics and Resources

We started the year in a temporary building with laptop trolleys. Regardless of your environment, every class needs to be inducted into conduct, rules and routines when using IT. Do not assume anything!

If you have a laptop trolley the induction should include:

• Two angles-90° and 45°. The former is the screen angle for working, the latter for when you are talking. Closing the lid forces some laptops to go to sleep, so this should be avoided.
• How to carry laptops-not by the screen as this puts stress on the hinge.

• How to stow laptops in the laptop trolley, managing cables and ensuring the laptop is on charge
• How to log off. If you close the lid midway through the log off or shutdown process, the next user will not be able to log in without clicking the subtle “switch user” button. Attempts will be met with “No log on servers available”.
• If you have not bought a laptop trolley yet, opt for two 15 capacity trolleys rather than one 30 capacity ones. The latter are heavier and difficult to move.
• Move the trolley to the classroom of intended use, not the laptops. This will reduce damage to laptops.

In a computer lab:

• Entry routine: Where to sit at the beginning of the lesson-is the routine to log on then take a seat in the centre desks?
• Moving around the room, must be on foot, never on wheely chairs as it inevitably causes silliness and damage to chairs.
• Where to save
• Pack up routine: What should a tidy Computer desk look like. Headphones stowed behind/on monitor, no trailing wires, chairs tucked under.
• No open water by the computers. Or no eating/drinking at all-the same rules as a Science lab.

Once students have been inducted, appropriate sanctions should be issued to encourage the correct conduct and routines.

Other notes:

You get what you pay for. Only trust the big brands (Dell, Lenovo, HP) and check reviews on Amazon
first.

If you are tight on budget, you can get a lot of nearly-new IT equipment for cheap from ict-direct.co.uk/ or bargainhardware.co.uk

Label and number everything with your own Avery labels or tipex. You can label your equipment with a room number, department and item number. I’d advise labelling anything that is not fixed i.e. laptops, chargers, headphones, portable speakers. It sounds petty and arduous, but this year we spent over £200 replacing lost/damaged peripherals. Damages was caused by both students and staff. Whilst this was either due to neglect or laziness (teachers having one charger at home and one at school), it can be avoided.

Student technicians-When you’re a small department, you need all the help you can get. Our school didn’t have a permanent technician, so I trained some students into the upkeep of laptops, installing printers, general troubleshooting of all things AV and Wifi. They were also taught  filming and photography skills. This means all events can be documented by students. Next year, I hope to train them to edit in iMovie too. Student technicians are also helpful to have at open days and on interview panels

Other helpers-There are lots of volunteers waiting to help you learn to program and run clubs for you. STEMNET and Code Club are a great source for CRB/DBS cleared helpers. A parent who works at an investment bank in Canary Wharf recently volunteered to come in and help me develop my programming skills. Sometimes all you need to do is ask, othertimes, the help comes to you.

Buy one of these organisers for only £11. It has a capacity of 500 sheets and once you create a tab for each of your classes, you will still have capacity for your form group, department, extension, spare sheets and helpsheet tabs. It has made teaching so much easier. I just do all my printing first thing in the morning, then carry this around with me.

·         If you need a book to learn Python and have never programmed before, I highly recommend Chris Roffey’s books:

·         

Lastly, teaching resources. Most of them are free and I have written extensively about these here.

Finances

Some Computing departments will have small budgets, particularly if you are a small school with only one or two cohorts of kids. Unless you have a full school, budgets will always be small. This section is mainly for those who have a budget of less than £1000.

Provided you have an IT suite or laptop trolley, forget the tempting gadgets and toys such as Raspberry Pi’s, Lego Mindstorms and Arduino’s. Spend most of your budget on training. There are plenty of courses on the Events page on the CAS network, some of them are free.

I know my previous statement about learning toys is contentious, but a class set of Raspberry Pi’s sounds good on paper, but really they’re just slow computers which need all the peripherals of a standard computer. When put together, they don’t sit well on a desk and are prone to damage. Even with a case, memory cards can break off and go missing, power leads can get pushed too far in. From what I’ve seen and heard, they’re great for kids to use as a learning tool/toy at home. But the classroom really needs robust computers. Not a worthy investment in my opinion.  

Recruitment

In finding someone to join your department, recruit early but don’t hire someone unless they’re absolutely right. I was lucky in finding a candidate on the third interview day that we held.

We run a fairly rigorous recruitment day including a code review, curriculum task (planning a SOW), teaching of a lesson, numeracy and literacy test. The last two perhaps are less significant, the main thing is the lesson that they teach, the subject task and the interview.

The main things you’re looking for are alignment with the school culture, subject knowledge and alignment with your own personality as you will have to work with this person for the next 1-20 years! The best advice I was given when visiting another middle leader was that there are some things you cannot change in a person e.g. their personality-“can you work with them?” is the big question.

Other big questions: If their subject knowledge isn’t quite where you need it, is the candidate trainable? Do they want to improve? In your interactions with them, do they give you energy or sap it out of you?

Top 10 Websites for GCSE Computing resources

There’s a lot of resources out there for teaching Computing. Finding resources is never an issue, there are anywhere between 10-30 new resources uploaded onto CAS every week. However, it’s sometimes difficult to follow a single scheme of work when presented with so many different resources. We also have our own preferences. The list below is based on the resources I have found most useful. This is by no means a finite list. There are many teachers out there who create resources but do not host these publicly or centrally on one single site. Those that do are listed below. Feel free to add more suggestions in the comments.

mrocallaghanedu.wordpress.com Mr O Callaghan is a Computing teacher who loves pedagogy. Like David Didau, Alex Quigley and Harry Fletcher Wood, he is an outstanding blogger. He frequently applies techniques based on educational researchers and cognitive psychologists such as Willingham, Kirby and Wiliam.

teachwithict.weebly.com Wonderful site of resources and thinking from CAS master teacher Simon Johnson

teachcomputing.wordpress.com Self-taught Computing teacher Alan O’Donohoe presents his thoughts and resources for teaching Computing. If there is an example of someone who has re-defined himself from novice to expert, it’s Alan.

www.letslearnict.com/computing.html -All round site covering Computing, ICT and IGCSE

mattbritland.com Not only does Matt Britland teach Computing, he does it with style. Great SOW and articles about EdTech.

gocompute.wikispaces.com Multimedia (Video, PDF, Word Documents) A set of comprehensive resources for Computing, ICT and Creative Media

compu2learn.co.ukGreat collection of theory and practical resources.

gcsecomputing.org.uk Resources which will help deliver OCR GCSE Computing. Some content is subscription only

thedenniglessons Ms Dennig also teaches Computer Science to her year 7’s. Lovely slides which break down complex abstract ideas into more concrete accessible ones.

gcsecomputingbalcarras A great collection of videos and websites which will take you through OCR’s GCSE

gfscomputing.net My own website where I share every resource that I use in lessons. There are links to Zipped Files and Curriculum plans.

Bonus link: This is not a website, but rather a list of websites which are useful for teaching Computing from KS1 to KS4

Open questions and lesson starts

I cam across two excellent blogs about "Do Now's" and lesson starts in general and it made me realise that a lot of my lesson starts involve closed "Do Now's". I suppose I have fallen into the trap of closed question Do Now's because it makes for quicker and easier marking/assessment and suits Computing quite well. Computing is a science afterall and so asking students to do closed problems like you might do in Maths seemed to make sense.

I then realised when I read the aformentioned article by @HFletcherWood's, that having closed questions probably encourages plaigirism and the belief in only one right answer. It also means that the activity by definitioncannot be low threshold and high ceiling-this is a big problem. Having also attended further training on Python programming, I realised that for many problems there is more than one correct answer.

  Some example Do Now's from a unit of work about Python

My aim for next week then is to plan more activities where there is room for more open responses. I also think this will help slow down the pace somewhat. Often, I feel asthough I use Do Now's simply because it is school policy. I try to rush through all the correct answers, albeit using lollypop sticks to keep kids on their toes. The rush stems from me wanting to start the main activities. Perhaps this is a result of me feeling that time is tight. I lose 10 mins every lesson simply through taking out and returning laptops from a trolley. After a 3-5 minute do now and 5 minutes feeding back, that leaves 35 minutes for the rest of my lesson. I would usually try to plan something meaningful, challenging, with a solid outcome and genuine learning. At the end of the lesson, I'd also like to do extended plenaries and exit tickets, but realistically this is sometimes just not possible, hence why the start of my lesson is rushed.

Slow down, do less, do it better

After observing lessons and thinking about the burnout at the end of last term, I promised myself to slow down, do less and do "it" better. Having tried slower paced starts, I find that students are less confused; simply slowing the pace slightly allows them to process the new material and perhaps frame their questions more carefully.

In my next post, I hope to talk more about open tasks and questions that I have tried.