Saturday, 15 February 2020

A Just Cause


I’ve been reading Simon Sinek’s “The Infinite Game” during my morning reading session with my sixth formers. 




Occasionally, I’ll read excerpts to them as it’s such an insightful book on long-lasting success. One particularly powerful chapter is chapter 2, “Just cause”. Sinek argues that every company and every leader that wishes to have sustained success needs a just cause - a vision for the future. Sinek states that a just cause must fulfil five criteria:

  1. For Something – affirmative and optimistic
  2.  Inclusive – open to all those who would like to contribute
  3. Service oriented  – for the primary benefit of others
  4. Resilient – able to endure political, technological and cultural change
  5. Idealistic – big, bold and ultimately achievable


In some countries, teachers have to write an educational philosophy. I was asked to write one for a job application once and I have attached it to the end of this post. However, the more I read Sinek's book, the more motivated I felt to write my own just cause. Why do I do what I do, what is it that I believe in and what is my ideal future. My just cause is as follows:


I believe in developing a world where more people know how to use computers to make their lives easier, better and more productive. I aim to teach computing to as many people as possible and I will do this by sharing my resources, knowledge and skillset - primarily through my books, blog, digital and physical resources and videos. Whilst I teach in a secondary school; I want to also help teachers, adults and younger children discover the beauty, fun and utility of computing.
For too many people, computing and computer science in particular seem daunting. Many people timidly or proudly admit to “not being good with computers”. I was once one of these people and I can confidently say that this can change. Everyone can learn about computing, everyone should be exposed to computing and given the opportunity to learn how to use computers to improve our lives.
The process of learning should be straightforward, accessible and involve achievable stepping stones. We should be able to learn about computing regardless of age, gender, race or income. We should be able to learn about computing without the fear of being labelled as a geek. Geeks are great, we should love them. It should be everyone’s aim to be a bit more of a computer geek and I’m here to help you achieve this.

 ----------------------------------------------------------------------------------------

Educational Philosophy – William Lau


From Nanotechnology to Synthetic Biology, from Wearable Computers to Self-Driving Cars; Computing will continue to shape the future that we live in.

Computing teaches us how to solve problems by breaking them down into manageable components. In developing our own original solutions, Computing requires us to be both logical and creative. Computing enables us to develop a skillset and mindset which will be useful in literally every other discipline.

As a teacher, leader and student of Computing, I believe that being a digital native and a mere user of technology is not enough. Technology is changing at such a rapid pace that in order to thrive and succeed in the Information age, we need to understand how computers work. One of my primary aims is to transform users of technology into creators of technology by giving all students the opportunity to think, create, persevere and grow.

To achieve this aim, we must strive to:
  • Create an environment in which all pupils enjoy Computing and feel they can do well in Computing.
  • Create well rounded users and creators of Computer technology with a focus on independent problem solving skills.
  • Engage pupils and expose them to a wide range of Computing tools and skills which will empower them in whatever career path they choose.

Too often, students come into our classrooms with a fixed mindset; the belief that ability is innate and static (Dweck, 2006). As a result some students have got into the habit of giving up easily or not attempting difficult tasks due to a fear of failure. Inspired by the work of Carol Dweck, I believe that the growth mindset is fundamental to teaching and learning Computing. We need to help our students realise that they can achieve great things if they persevere and are resilient when faced with challenges and setbacks. There is a risk of students believing that as digital natives, they have little to learn and that everything they want to do with a computer has already been created or will be invented by someone else. There is also a fear that Computer Science is difficult and too technical. However, by eliminating these misconceptions, our students will be able to push themselves and learn to enjoy the learning process despite the many challenges that they will encounter.

Computing lessons should not just be about ‘doing’; the focus should always be on what the pupils are thinking about. Lessons should aim to teach pupils the real-world relevance of Computing; this relevance comes ultimately from a Fertile Question which feeds into every lesson question.

My teaching methodology revolves around meticulous planning, modelling, formative and summative assessment, feedback and putting the individual learner at the focus of all interactions. In order for a student to understand the standard of what is required, it is important that the teacher models how an expert in the subject should think and perform. This expert may be the teacher themselves, or they may use their students as experts. Having modelled the thought processes and explained the tasks, students should be given an opportunity to demonstrate their skills either through joint construction or independent tasks. It is at this point that formative assessment and monitoring is most crucial. Unless the teachers can visualise student’s thinking, identify misconceptions and mistakes and correct these, a student is not going to make good progress over time. Through regular intervention and feedback, these interactions with the group and the individual allow the teacher to address common errors and help students improve their learning.


Saturday, 14 September 2019

Quick Fire Five


The Quick Fire Five is derived from Doug Lemov’s Do Now in Teach Like a Champion 2.0. In brief, a Do Now should:
  • Involve students putting pen to paper
  • Review previous learning (See also Rosenshine)
  • Be completed in silence without any direction from the teacher
  • Be consistent in delivery format e.g. on paper or on the board as students come in
  • Take 3-5 minutes to complete

For more detail see here

Based on cognitive science, Corinne Flett @FlettMiss designed the Quick Fire Five (QFF) in 2017 whilst working as an Assistant Head in charge of Curriculum and Assessment. QFF involves 5 questions which allow for interleaving and spaced retrieval practice. The 5 questions should be one question from:
  • Last Lesson
  • Last Week
  • Last Month
  • Last Term
  • Any time

Many have asked for my bank of QFF Do Now’s. I have included some examples here and here. However, I would say that QFFs are best designed by the teacher, as they should be based on your own students’ misconceptions and will vary based on your sequencing. Some think it will take too long to make. After a year of making them, I can now modify existing QFFs in 5-10 minutes. Writing new ones take 10-20 mins at most.

For more on cognitive science and research-based practice visit:

Further reading:
How We Learn (Carey)

Disclaimer: Whilst I embrace research, I also value experience. Context will shape your practice as will your own gut instinct as to what feels right. I’m a firm believer that there is no “single best way to teach” – if there was, there would be no innovation and no need for new theories. I think if you’re reading this, you’re open to improvement and hopefully open to the view that many of the techniques in the above texts will work but some may not.

William Lau 
September 2019

Thursday, 25 April 2019

The Little Book of Algorithms



Version 2.0 has now been released and you can read about this here


The text below refers to the original version.

The Little book of Algorithms is designed to help students build fluency in their Python programming. The book would suit students who have already been introduced to the three basic programming constructs of structured programming, namely sequence, selection and iteration.

Following the publishing philosophy of Al Sweigart, "I write books to teach beginners to code. I put them online for free, because programming is too valuable and needs to be accessible to all. (Though I sell print versions to pay rent.) Get started. It's a great journey."


You can buy printed copies directly here  or via Amazon here.


Download the PDF here which you can print yourself


An embedded book is also below:

Full description:

This book is designed to help those learning and teaching Computer Science. The aim of the book is to help students build fluency in their Python programming. The book would suit students who have already been introduced to the three basic programming constructs of structured programming, namely sequence, selection and iteration. The learning curve for programming can be quite steep and this book aims to ease this transition by encouraging practise and gradually introducing more complex concepts such as lists and 2D lists, file writing and using procedures and functions. Originally, the book was written for my 14-16 year old students studying for their GCSE Computer Science programming exam. However, I hope a wide range of students and teachers will find this book useful.

Sunday, 8 October 2017

Research-based instructional principles and mastery learning

In a review of research from cognitive scientists, master teachers and cognitive supports spanning four decades, Barak Rosenshine presents ten research-based instructional principles that all teachers should use (Rosenshine, 2012). These are as follows:

  1. Lesson starts: Begin a lesson with a short review of previous learning.
  2. Present new material in small steps with student practice after each step.
  3. Ask a large number of questions and check the responses of all students.
  4. Provide models.
  5. Guide student practice.
  6. Check for student understanding.
  7. Obtain a high success rate.
  8. Provide scaffolds for difficult tasks.
  9. Require and monitor independent practice.
  10. Engage students in weekly and monthly review.


These steps are summarised in the figure below. The rest of this blog uses Barak Rosenshine’s Principles of Instruction to outline how a typical lesson would be delivered according to the students’ current stage of mastery.

Lesson flow based on Barak Rosenshine's Principles of Instruction (Rosenshine, 2012)

Emerging stage of mastery

In the first lesson of (say) a 6-lesson unit of work, the majority of students will be in the “Emerging” stage of mastery, understanding between 0 and 25% of the concepts required to reach mastery. The lesson should start with a Do Now, a review of prior knowledge which allows students to connect to this lesson’s content.  Following the Do Now, the teacher should then model the thought processes for the new concept or skill. Collins et al state the importance of making the teacher’s thinking visible by thinking out loud in the process known as Cognitive Apprenticeship (Collins, et al., 1991).

In applying Cognitive Apprenticeship to Computing, many of the tasks we perform involve implicit steps or thinking. An example of this is closing a tag in HTML as soon as we open it. We would model this by stating that “HTML Tags generally occur in pairs and therefore it is good practice to create a closing tag immediately after creating an opening tag.” Later in the lesson, the teacher would check that students have internalised this habit by modelling the creation of (say) a  paragraph, opening a <p> tag and then asking students “As I’ve opened the <p> tag here, what should I do immediately, before I even write my paragraph?” The teacher should expect any student to be able to tell them that a closing </p> tag should be created. 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.

The teacher will follow up teacher modelling with a worked example, presenting a finished product so that students know “what a good one looks like”. This is the model which they will judge their work against. They will know if they are on the right track by referring mentally or literally to the teacher’s model. Based on Rosenshine’s research, for new material the construction process should be broken down into small steps with student practice after each step. If for example, students are studying spreadsheets, students should not be presented with four different functions to use in formulae along with formatting and the creation of graphs in one lesson. Rather, the first lesson might focus on arithmetic operators and a spreadsheet might be designed which allows for practice of individual arithmetic operators before moving onto formulae which combine several operators and brackets.


For each of the lessons, Rosenshine advises that students should be attaining a high success rate in their guided and independent practice. Students should be attaining success rates of 80% on their practice tasks. One way to gauge what the class’s current success rate and level of understanding is to stop the students after a set amount of time, model the correct processes and solutions on the board and asking students to mark their own work. At the end of this modelling and self-assessment, pupils may be asked to raise their hand if they achieved 50%, 60%, 70% 80% or more. If it is clear that students have achieved a high success rate the teacher can launch the next task or increase the complexity of the current task. Likewise, if it is clear that very few have achieved a high success rate, then the teacher may want to clarify some misconceptions.


Developing stage of mastery

By the end of the first lesson, students should be developing a sense of mastery and at this stage teacher modelling should be punctuated with increased questioning. The process of modelling at this stage will involve deconstruction of the task, activity or process. Royce Sadler who has researched this area extensively advises that exemplars should be used during the modelling process and that these should be authentic pieces of student work of varying quality (Sadler, 2002). John Sweller is another highly-respected researcher who has spent over thirty years researching Cognitive Load Theory. During this time he has also written extensively about worked examples vs. problem solving. In a recent essay, professor Sweller discusses the benefits of showing highly variable worked examples (Sweller, 2016), referencing the work of Paas and Van Merriënboer (Paas & Van Merriënboer, 1994), he states that  learners who encounter highly variable worked examples learn more than those shown more similar worked examples. The differences in quality allow students to truly understand what is meant by quality, it makes abstract specifications and criteria more concrete. There is no substitute for exemplars; Sadler emphatically states that exemplars covey messages that nothing else can.


In the second or third lesson of the unit, the teacher should still be providing scaffolding for difficult tasks. However, the intention should be that the scaffolding will be removed once the students achieve a high success rate. At this point, students should have the opportunity to complete joint construction through supervision or guided practice. This guided instruction and collaboration is supported by Pearson & Gallagher’s Gradual Release of Responsibility Model (Pearson & Gallagher, 1983) along with Lewis & Wray’s research into literacy (Lewis & Wray, 2000) and Gibbons work on reading, writing and language acquisition (Gibbons, 2002). As students develop their level of understanding, it is worth closing the lesson with a formative assessment in the form of an exit ticket or low stakes quiz.


Secure stage of mastery

By the third or fourth lesson in a six-lesson unit, in order for modelling to be truly effective, we need to encourage students to analyse the exemplars and form their own opinions of quality; by being able to judge quality accurately, students will be able to judge and improve the quality of their own work during independent practice. After initial teacher modelling, To and Carless recommend critical peer dialogue as an effective way of students participating in this deconstruction and reconstruction process (To & Carless, 2016). To and Carless found in their research that peer dialogue and critique can provide a more supportive environment for peers to ask questions about an exemplar thus greatly increasing participation. For reserved students and students who may still fear failure in front of a whole class, pair or small group discussion allows students to make their opinions without fear of judgement from their peers. One area worth guiding students with is identifying weaknesses in exemplars as students generally gravitate towards identifying strengths and rarely identify weaknesses.

Teacher guidance is certainly required during the modelling process particularly during the early stages of a unit of work when it is highly likely that the teacher is the only expert in the room. When a teacher is leading a discussion about an exemplar, possible questions might be:


  • Who is the intended audience for this piece of work? How has the student ensured their work is user friendly and suitable for the audience and purpose?
  • How many marks would you give this student and why?
  • What keywords and technical vocabulary has this student used? What technical vocabulary should a student be using in this answer?
  • What might be a more efficient way of doing this?
  • What data structure could they use for this data set?
  • State three things would you do to improve this program/poster/report/essay/answer?
  • State three strengths of this program/poster/report/essay/answer?
  • What feedback would you give this student to improve their work?
  • This piece of work scored five out of seven what is missing to ensure the student gets full marks?
  • Are there any questions you wish to ask about the exemplars?
  • Why do you think the student has used this formula here? Can you explain their thinking?
  • What is the graph trying to show? How successfully has the student done this? How could it be improved?
  • If you were to pick out the strongest sentence or argument from this paragraph, what would it be?
  • What did you like about this film trailer?
  • What three techniques has the student used effectively to communicate the genre of their film to the audience?
  • List the graphic design rules and principles each of these exemplars have used?
  • What are the similarities between the different exemplars?
  • How might this exemplar be better or weaker than your own?
  • Can you summarise the key differences between the three exemplars we have looked at this morning?


The use of teacher-led modelling, peer discussion and individual deconstruction can take place during any unit of work. These varying methodologies do not necessarily need to take place in a linear sequence as the benefits of each methodology can be reaped regardless of the stage of mastery. However, one key finding based on experience and the literature review is that the choice and range of exemplars do need to be planned in advance.

The use of teacher-led modelling, peer discussion and individual deconstruction can take place during any unit of work. These varying methodologies do not necessarily need to take place in a linear sequence as the benefits of each methodology can be reaped regardless of the stage of mastery. However, one key finding based on experience and the literature review is that the choice and range of exemplars do need to be planned in advance.

Modelling methodologies. Based on (Carless & Chan, 2016) (Sadler, 2002)


As students move from novice to expert, the guidance provided to students should be gradually reduced (Renkl & Atkinson, 2003). Whilst problem solving is a one of the key elements of Computational Thinking and is one of the skills encouraged by Knight and Benson (Knight & Benson, 2014) and Nuthall (Nuthall, 2007), Sweller and researchers who have built on his Cognitive Load Theory have found that problem solving tasks are not suitable for novices during their initial stages of cognitive skills acquisition as they will experience cognitive overload (Sweller, 2016). Once a novice has developed their understanding and skills through varied worked examples, these learners’ intrinsic cognitive load will decrease, allowing them to be exposed to problems which they are required to solve. Renkl and Atkinson go on to state that these initial problem solving tasks will require scaffolding. Through gradual fading of both worked examples and scaffolding, students should complete problem solving tasks independently.

Rosenshine notes that whilst independent practice should be extensive and successful in order for skills and knowledge to become automatic, this independent practice should still involve monitoring. Brief monitoring of no-more than 30 seconds is appropriate. However, formative assessment can also be used to check the understanding of the whole class.

The expert teacher does not simply follow a rigid lesson structure and plan; the expert teacher will elicit feedback through frequent questioning and formative assessment techniques throughout the lesson and adapt their instruction accordingly.

“An assessment functions formatively to the extent that evidence about student achievement is elicited, interpreted, and used by teachers, learners, or their peers, to make decisions about the next steps in instruction that are likely to be better, or better founded, than the decisions they would have taken in the absence of the evidence that was elicited.”- (Kingsbury, et al., 2011)

The use of formative assessment strategies by teachers is similar to the strategies employed by football managers, pilots and heart surgeons. Whilst all the aforementioned professionals approach their operations with a plan, this plan is adapted in real-time. In aviation, when a pilot checks their instruments and discovers that they have deviated from the flight plan’s destination, the pilot makes a course correction. The pilot checks these instruments regularly, not just towards the end of the flight. Similarly, in teaching, expert teachers should be regularly checking that their students are on track to meet their destination and if not, the teacher should introduce a form of intervention to change their student’s trajectory and ensure a high success rate. The formative assessment should not take place only at the end of the lesson as this does not leave sufficient time to offer immediate corrective feedback for students to act on. An expert teacher’s classroom is a responsive classroom and the corrections to the lesson delivery are made throughout the lesson.

At this secure level of mastery, teachers can also rely on peers to provide feedback, correction and instruction. Pair programming is an example of a cooperative learning and peer instruction which is supported by research and industry (Williams & Kessler, 2002) (Hannay, et al., 2009) (Denner, et al., 2014) (Franklin, 2015). The theory behind pair programming is that the programmer (driver) is required to think aloud and the observing peer (navigator) should review the program, offering advice and feedback based on the driver’s programming and thought processes. As both students regularly switch roles after timed intervals, their shared knowledge and understanding allows them to achieve more than if they were to program separately. 

Mastery

The Gradual Release of Responsibility model (Pearson & Gallagher, 1983) states that students should move from teacher-led learning to student-led learning. At this final stage of mastery, Rosenshine states that independent practice is necessary in order to build fluency. The teacher plays an increasingly passive-role with much less intervention and much more observation and monitoring.
Learners at this stage should be independent in their thinking and application of knowledge and skills. The independent practice in the form of overlearning is what leads to fluency and automation. Rosenshine’s research suggests that the material used in independent practice may involve slight variations in the material covered during guided practice. In a Computing classroom, these variations might involve subtle changes in context or content for example re-designing a poster for a different audience or using a similar selection algorithm for slightly different conditions.
At the end of each unit of work, there should also be a summative assessment which tests the students’ stage of mastery by asking them to apply their skills or knowledge to a new scenario or context. These assessments should be conducted in exam conditions and should mirror the assessment requirements at GCSE or A-Level as closely as possible. In many cases, exam boards will release their old exam papers and also supply some specimen exam papers for new specifications. Teachers are encouraged to use these official materials wherever possible to ensure that the assessments are rigorous, accurate and appropriate.

Following a summative assessment, students should spend at least one lesson reviewing their assessment. It is here that the teacher should design resources and activities to correct misconceptions and misunderstandings. Some teachers like to have a digital mark book which directly feeds into a Personalised Learning Checklist (PLC) for each student. Dr Jasper Green (Network lead for Science at Ark Schools) suggests an alternative approach which is marking an assessment with mark scheme at hand and annotating this mark scheme with misconceptions, it soon becomes apparent where the common misconceptions are for a certain unit and what these misconceptions are (Green, 2016).

Indeed, a combination of the two techniques can be used to record and analyse misconceptions.

Before students start their corrections, students could also be given the opportunity to reflect on their learning and current level of understanding. Below is an example of a reflection sheet for a Database unit which is used during the Do Now and revisited as a plenary activity in the consolidation phase. <End of excerpt>

----------------------------------------------------------------------------------------------------------
This is an excerpt from Teaching Computing in Secondary Schools. The full text is available from Routledge and Amazon.


References

Baxter, M., Knight, O. & Lau, W., 2016. GFS Teaching Handbook, London: Greenwich Free School.
Carless, D. & Chan, K. K. H., 2016. Managing dialogic use of exemplars. Assessment and evaluation in higher education, 20 July, pp. 1-12.
Collins, A., Holum, A. & Seely Brown, J., 1991. Cognitive Apprenticeship: Making Thinking Visible. American Educator: The Professional Journal of the American Federation of Teachers, 15(Winter), pp. 38-46.
Denner, J., Werner, L., Shannon, C. & Ortiz, E., 2014. Pair Programming: Under What Conditions Is It Advantageous for Middle School Students?. Journal of Research on Technology in Education, 46(3), pp. 277-296.
Franklin, J. P., 2015. Perceptions by young people of Pair Programming when learning text languages, London: Axsied / King's College London.
Gibbons, P., 2002. Scaffolding Language, Scaffolding Learning. Portsmouth, NH: Heinemann.
Green, J., 2016. Question level analysis in science. [Online]
Available at: http://thescienceteacher.co.uk/question-level-analysis/
[Accessed 29 December 2016].
Hannay, J. E., Dybå, T., Arisholm, E. & Sjøberg, D. I., 2009. The effectiveness of pair programming: A meta-analysis. Information and Software Technology, 51(2009), pp. 1110-1122.
Kingsbury, G. G., Wiliam, D. & Wise, S. L., 2011. Connecting the Dots: Formative, Interim and Summative Assessment. College Park, Maryland, Northwest Evaluation Association (NWEA).
Knight, O. & Benson, D., 2014. Creating Outstanding Classrooms. Oxon: Routledge.
Lewis, M. & Wray, D., 2000. Literacy in the Secondary School. London: David Fulton Publishers Ltd.
Nuthall, G., 2007. The Hidden Lives of Learners. Wellington: NZCER Press.
Paas, F. G. W. C. & Van Merriënboer, J. J. G., 1994. Variability of Worked Examples and Transfer of Geometrical Problem Solving Skills: A Cognitive Load Approach. Journal of Educational Psychology, 86(1), pp. 122-133.
Pearson, P. D. & Gallagher, M. C., 1983. The Instruction of Reading Comprehension. Contemporary Educational Psychology, 8(3), pp. 317-344.
Renkl, A. & Atkinson, R. K., 2003. Structuring the Transition From Example Study to Problem Solving in Cognitive Skill Acquisition: A Cognitive Load Perspective. Educational Psychologist, 38(1), pp. 15-22.
Rosenshine, B., 2012. Principles of Instruction: Research-Based Strategies That All Teachers Should Know. American Educator, Issue Spring, pp. 12-39.
Sadler, D. R., 2002. Ah! … So That’s 'Quality'. In: P. L. Schwartz & G. Webb, eds. Assessment: Case studies, experience and practice from highereducation. London: Kogan Page, pp. 130-136.
Sweller, J., 2016. Story of a Research Program. Education Review, 10 February, Volume 23, pp. 1-19.
To, J. & Carless, D., 2016. Making productive use of exemplars: Peer discussion and teacher guidance for positive transfer of strategies. Journal of Further and Higher Education, 40(6), pp. 746-764.
Williams, L. & Kessler, R., 2002. Pair Programming Illuminated. Boston, MA: Pearson.

Tuesday, 4 October 2016

New Book on Teaching Computing in Secondary Schools

UPDATE: The book is available to order HERE 


The blog has been a bit quiet over the past 12 months as I've been working on a new book entitled "Teaching Computing in Secondary Schools". It is due to be published in autumn 2017 by Routledge and a sample extract is below.



I will also be presenting on curriculum planning in computing at the Computer Science in action conference on November 17th. The event is hosted by The Guardian Education Centre and Further details here.

Wednesday, 27 July 2016

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.

Friday, 7 August 2015

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: