Semantic Waves Legitimation Code Theory LCT | Computing At School CAS Conference for teachers

Re-presenting my conference session from the last CAS London Conference (2020)

Download the slides and resources at: http://bit.do/CAS2020WLau

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.

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