Mark Brown Private Tuition

Introduction

In recent years I've had many requests to teach children and adults alike programming. Generally this is Python but the lessons in this post will cover programming in general. In the UK, programming has become a major part of the school syllabus in a new subject, 'Computer Science'. This replaced the introduction to Microsoft Office course, better known as ICT. Many things are still being figured out, so this is my attempt to present a game plan for those fighting the good fight in teaching. Enjoy!

Background and a Disclaimer!

I'm a self-taught programmer with a PhD in nothing relevant. This is not a post about Computer Science or indeed Software Engineering but about my observations into the pedagological underpinnings of learning to code. If you're interested in either of these I would recommend a look at hacker news. Please keep this in mind!

0. Choosing a Programming Language and the Environment

In 2019 the choice of what programming language to teach is a fairly simple affair. First though let's look at the factors we should use to decide

1. Examination boards have a list of allowed languages. Whilst others in theory can be used, it's probably not wise. This also means picking a language with structure similar to the pseudocode used on the written papers. For 16 years and younger, this writes off anything functional immediately.
2. Real world usage and documentation. Depressingly I do still come across schools teaching Visual Basic and Delphi. If you're about to email me, angrily claiming that such languages carry concepts in a pure way, please don't. Both are grossly out of date and are typically chosen purely because a GUI can be drawn by the student. Whilst I have absolutely nothing against Rapid Application Development (RAD) (go check out Anvil!), RADs are often chosen in an attempt to hoodwink examiners. A few buttons on a screen does not a programming project make! Secondly languages should be picked that are in active use and have good online documentation. In short, if there isn't a large quantity of posts on stackoverflow, it is a dead language as far as educators should be concerned.
3. School Home Installation Restrictions. The bane of my teaching career (so far!) has been installation of software in schools. If you can get permission to do so, which is difficult, propriety security software will cause issues. In 2019 we're unfortunately still in an era where students have unrestricted internet on their own devices and inferior tooling on school machines. Simply put, school computers are a hostile environment due to child protection measures. This is despite such rules requiring the education of students not be impeded. Unfortunately this has meant most of my A level students in the past have been forced to code on their own laptops. I mention this, as some languages are easier to setup on Windows than others.
4. Homework. Likewise if you expect students to be able to code at home, frankly they need to be able to do so! You may think you're helping by sourcing professional licences for development environments, but in reality you're just teaching children the benefits of piracy. Consistency should be key and any IDE used should be freely available.

Bearing these points in mind I would (unsurprisingly!) recommend Python. Javascript is not a bad choice however it requires many libraries to be an effective tool. Python isn't perfect. It can be difficult and confusing for new students to install and setup. Weirdly, installing the official version of Python is generally a bad choice for students. I would recommend Anaconda with VS Code or Pycharm. If you're going to be teaching more experienced students, I would also install git. For more experienced students I would recommend installing git also.

1. How to begin Teaching

A common trope of my youth was the difficulty of programming a VCR (or video cassette recorder for my younger readers). The device was used for recording television programs to be watched later. In any case it was often described as being an arduous arcane process to make work properly. That is unless you were a small child and therefore mysteriously found the whole process trivial. I mention this because it is commonly assumed children today have a natural grasp of technology. In my experience this is a complete load of garbage. The ability to navigate the walled gardens provided by the likes of Snapchat and Instagram does not remotely imply technological prowess.

I recently wrote an example lesson plan for an introductory class using turtle with a minimal Python 3 installation. Most schools are using tools such as Scratch to introduce programming. Using turtle is an excellent follow on in my experience.

Interleave this with using functionality of the environment, such as debugging and progression of variables over time. Tools such as Python Tutor [2] are frankly excellent for this.

The purpose of such an approach is to teach attention to detail and to allow new students to become comfortable with what is an alien environment. Following this, I would suggest modifying code, such as altering the contents of strings for print statements and changing values. Graphical tools such as Turtle [3] are an excellent way of relating these 'levers' of control to output.

This may seem rather basic, but in my experience attempts to rush through syntax does not help. Some students will progress quickly, however if your purpose is to teach a whole cohort simultaneously, then you simply must ensure students can follow.

As this progresses, these drills can be done from memory. Get students to write short sections of code to do basic input/output. In many ways this is not coding, but simply memorisation. Counter-intertuitive this may seem, but we want students to first be able to copy before they can create. The direct parallel here, is the many(!) programmers who begin their careers by simply trusting StackOverflow for the correct answer rather than referring to documentation.

2. Baby steps and beginning to Code

Modification and combination of the drills should be our next step. At this stage students will not fully grasp the importance of syntax. In many ways this is still an alien approach to them. This is simply because most students will not have a comprehension of command-line interfaces. The idea of not being able to 'click' their way through menus to an outcome is not immediately obvious. Due to this progression must be limited - at least initially.

I feel this is where most approaches currently fail. Burying students in syntax does nothing but fill time and dishearten educators and students alike. That said I still think the approach of beginning with input/output (IO) is a correct approach. As always, let us start with the classic helloworld example [1]. Our aim should be

[1]https://blog.hackerrank.com/the-history-of-hello-world/

1. Don't comment on style. Focus on functionality. Does it work?
2. Get students to produce anything. Games written by the student, no matter how awful are excellent. They demonstrate a desire to actually learn.
3. Code review. Explore your students code and show why some decisions are bad and how these can be improved.
4. Flow diagrams to explore structure.
5. Get students to appreciate the need for further structure. Don't bury students in syntax. Focus on conditionals and loops. Functions should come next.
6. Regular exercises using material. Drills on code.
7. For beginners, students should type out code. Practicing attention to detail is such a given but it is hard for many children.
8. Alteration of existing code to perform a slightly different task is hard. So do it. Alter something so it asks for minimum not maximum numbers. Find a different range.
9. Bring in other material. Things like data representation, mathematics, physics and art. Content in these subjects can be essential for getting students interested. Focus heavily on topics that are useful. Website design using neocities can be excellent in this regard.
10. Give students the tools to explore more themselves. Teach students how to debug. How to use help. How to use stackoverflow.