the teaching of coding

The approach I advocate here emphasises developing of personal, meaningful digital artifacts through collaboration. I also discuss known problems in the teaching of coding and suggest remedies.

An article of this nature will never be finished. At this stage I feel it is good enough to publish. The writing and redrafting process has helped clarify my own thoughts and how to present them. It may help others. I’ll put a version up on Google Docs, here, for anyone who want to develop it further or critique it.

GOAL: THE COMPUTER AS A MEDIUM FOR SELF EXPRESSION

On day one tell the students that their main task will be to “Design and build a collaborative digital project with personal and / or social relevance”

A rich, holistic task like this will achieve many of the dry, technical points on the ACARA checklist. I’ve included the ACARA goals for Years 7-8 as an Appendix.

THE LEARNING ENVIRONMENT

The teachers role is to tap into already established existing interests of the students and guide that in a direction where digital things are progressively enjoyed and mastered. If technology is seen to relate directly to personal life then this provides a tremendous incentive to learn it.

A good general theme is Children as collaborative software designers (after Idit Harel). Keeping it simple begin with Scratch and the Collabrify suite. Add in tangibles such as micro:bit if and when the time and opportunity present themselves. It depends a lot on how your school organises its computing resources. eg. in my current school Year 7s only receive 2 lessons a week for one term. I can argue for whole school reform to integrate computing into the curriculum but it probably won’t happen.

TANGIBLES

CSER has a lending library of class sets of tangibles: Beebot, Sphero, Ozobot, Makey Makey, LilyPad, Little Bits ‘Rule Your Room’, Little Bits Arduino, Dash & Dot, Bluebot, Micro:bit. They give preference to those who have completed their MOOC courses.

Kids have mobile phones and MIT App Inventor can be used to develop apps for Android phones. But given the reality that kids exposure to computer coding in Primary school has probably been patchy I suggest for Year 7s start simple with Scratch and the Collabrify suite and use programs such as App Inventor or activities with micro:bit, or whatever is available, as extension activity for those who have a strong background and can work independently.

PERSONAL, SOCIAL, COLLABORATIVE PROJECTS

What do kids like? Drawing and modifying pictures, music / sounds, games, socialising, building things, achieving something. The project, “Design and build a collaborative digital project with personal and / or social relevance”, taps into these already established behaviours and aims to develop them in the computer medium.

On day two introduce a Designer’s Notebook and Critique groups.

Designer’s Notebook: Preferably this should be online and public so the teacher and other students can read and comment on it.
Start of lesson: Write your plans and draw a picture of what will happen
End of lesson: Write about Progress, Problems, Solutions, Who I helped, Who helped me.

If and when social and emotional comments appear in the notebooks then this should be encouraged, not discouraged. Building a fully sharing community is just as or more important and helps to build the technical mastery of coding.

Critique groups: Projects need an audience for both appreciation and suggestions for improvement.

The metaphors have further evolved since Seymour Papert’s time. He coined the phase “objects to think with”; this has evolved into “objects to think and share with”. He coined the phrase “low floor, high ceiling”; this has evolved into “low floor, wide walls, open windows, high ceiling” (Kafai and Burke, pp. 55, 59)

PROJECT IDEAS

If you put out a variety of project ideas then that will send the right message, that we want our students to choose something with personal meaning:

• Add on yourself projects – eg. the initiator posts a picture of a dozen eggs and has put a face on one of them. He/she invites remixers to continue adding faces to the eggs. Kafai and Burke point out that this type of project usually has a low skill level coding requirement but they help build community involvement. Other examples include colouring in projects (with a prize for the best entry), add your icon/avatar jumping on a trampoline etc.
• Games, including Games with a story (RPGs)
• More complex group projects, eg. I took a copy of a poster, Know Your A-Z: Prevent violence against women – challenge gender stereotypes and promote respect, a different message for each letter of the alphabet; different characters and animals in the rooms of a castle
• How to projects: Tutorials which explain how to achieve a certain feature in Scratch, eg. a scrolling screen of the type seen in Mario games
• Seed project – the teacher could provide a poor version and ask students to improve it, possibilities include a rocket taking off, photosynthesis, maths drill, how to drive a car at an intersection, a vacuum cleaner which make white marks where it goes but doesn’t clean the room properly (this last one from Kafai and Burke, p.83)
• Cross age tutoring projects – years ago I duplicated the Idit Harel cross age tutoring children designers fraction project. Here.

COLLABORATIVE SOFTWARE

Blogs, wikis and Google Docs are available on many school systems. But improving on this is the Collabrify software suite (intended for Years 1 to 7) developed by Elliot Soloway and Cathie Norris. This includes Writer (co­-create documents that include text, pictures, and video), KWL (Know, Want, Learn), Flipbook(drawings or “flipbook” style animations), Chart (collaboratively create a chart and graph its data) and Map (for concept maps).

REMIX

The Scratch site has a remix feature where you are encouraged to take the work of others and modify it. This is something I want to encourage since it mirrors real life collaborative software development. But it does make it difficult to assess kids on the basis of the quality of their finished software since they have built on the work of others. The answer here is develop other asssessment parameters.

Kafai and Burke have a discussion in their book (p. 86), is remix a crutch or a spur?

KNOWN PROBLEMS

Coding is a complex activity and initially can be overwhelming to newbies. There needs to be some clarity about known problems in teaching novices to code. These are:
Design – I don’t know what I want the computer to do
Selection – I think I know what I want the computer to do but I don’t know what to use
Co-ordination - I think I know what things to use but I don’t know how to make them work together
Use - I think I know what to use but I don’t know how to use it
Understanding - I thought I knew how to use this, but it didn’t do what I expected
Information - I think I know why it didn’t do what I expected, but I don’t know how to check

Some of these problems have been alleviated through the development of block code languages. Others need to be specifically addressed.

BLOCK CODE

Scratch is now widely used in schools. This alleviates some of the above problems, as follows:

Selection – Picking a block from a pallete is far easier than remembering a word (recognition over recall)
Co-ordination – Blocks make assembling code easier by providing constrained direct manipulation of structure, eg. two incompatible concepts do not have connecting parts
Use – Coding has a high cognitive load for new programmers. Blocks reduce the cognitive load by chunking code into a smaller number of meaningful elements

What about the other three known problems (Design, Understanding, Information)?

DESIGN

Task: “Design and build a collaborative digital project with personal and / or social relevance”

Initially Design is approach through teacher modelling, discussion and recorded in the Designer’s Notebook.

The Designer’s Notebook includes this information:
Start of lesson: Write your plans and draw a picture of what will happen
End of lesson: Write about Progress, Problems, Solutions, Who I helped, Who helped me.

This is a record of “low level” design and collaboration activity.

Teacher modelling (the principle here is eat your own dogfood): For example, I have designed three versions of a computer game – bad pong (only a few features, boring to play), ok pong (more features such as randomisation of ball movement and scoring) and wicked pong (select backgrounds, unpredictable ball movement, high score, bat shrinks as your score increases). This provides various options for discussion with students. What are your favourite games? What are their design features? Split into groups and do a KWL (Know, Want, Learned – the learned comes later). Depending on how the class is progressing at some stage introduce some design tools (start / end, process and decision) to aid the process.

Some thoughts about the place of high level design in the learning process.

Simple projects have simple design.
eg. draw a square:
to square
pen down
repeat 4 [fd 100 rt 90]

Novices have to be carefully taken through this (tell the robot what to do, etc.) and yes, write it down. But conceptually, it is not particularly complex. With each increase of complexity the difficulty of holding it in your head increases. The complexity versus "grasping it" curve starts simple but is not linear. When you get to a game of pong which keeps score and stores and displays high score then you need to keep track somehow outside of the code itself.

Simple code can be written without formal design criteria. The Scratch course works more along the guidelines of play first, do something of personal interest, and later, when you want to build something more complex then design becomes necessary.

In the Creative Computing Curriculum Guide (Scratch 3.0) project planning is stressed more towards the end of the course (section 6).

For the sake of further discussion we could divide our students into those who are inclined to be top down planners and those who are inclined to be bottom up tinkerers. The way things are normally done in schools may disadvantage the bricoleurs / tinkerers. See the Epistemological Pluralism article in reference for more detail about this. As teachers of computing our prejudice may be to prefer the top down planning approach because it is “the way things are done” by professionals and it makes it far easier for us to keep track of what our students are doing for helping and assessment purposes.

IMHO one way to kill interest in some students is to put too much emphasis on top down planning and top down planning tools.

I think a reasonable compromise here (and one which is consistent with the Agile Programming approach) is this development sequence, as suggested in the App Inventor book:

1. initial ideas through group work and dialogue with teacher for desired project. Who is your audience and what features do they want?
2. build a simple prototype
3. follow the incremental development principle – code a little, test and repeat
4. at this stage produce a formal design

UNDERSTANDING and INFORMATION

Understanding - I thought I knew how to use this, but it didn’t do what I expected
Information - I think I know why it didn’t do what I expected, but I don’t know how to check

The experts, such as Juha Sorva, are advising here that the ability to trace code at run time should be explicitly taught. They also advise that Parson’s problems help to teach coding. Parson’s problems are where the blocks are provided to achieve a given task and the student has to put them together correctly.

I couldn’t find any reference to anything called Parson’s problems in the Scratch forums but did find something similar: Debug’ems, Complete’ems and Explore’ems! See reference.

Finally, students should be required to add comments to their code.

WHAT THIS ARTICLE LEAVES OUT

I support whole school reform to integrate computing into the curriculum. This idea has been around for 30+ years but hasn’t happened yet.

Tangibles. I think the new tangibles on the market are important and it’s a great idea that CSER has setup a lending library. I’d like to see more work on the evaluation of these tangibles.

I haven’t used slogans like “computational thinking”, which have become very popular. Some authors (diSessa, Guzdial) have critiqued this and I agree with their critiques. I haven't talked directly about teaching abstraction, which is part of the same bag of worms.

ACARA guidelines. Remember the saying, “School is like going to the world’s finest restaurant and being fed the menu” (Murray Gell-Mann). ACARA is cardboard, like that. Our job, as teachers, is to bring the cardboard to life.

REFERENCE
David Bau, Jeff Gray, Caitlin Kelleher, Josh Sheldon, And Franklyn Turbak. Learnable Programming: Blocks and Beyond (2017)

Beck, Kent. Manifesto for Agile Software Development.

Karen Brennan, Laura Peters, and Alexa Kutler. Creative Computing Curriculum Guide (Scratch 3.0)
 
Kafai, Yasmin. From Computational Thinking to Computational Participation in K-12 Education
 
Kafai, Yasmin and Burke, Quinn. Connected Code: Why Children Need to Learn Programming (2016)

Kerr, Bill. Educational Software: Designed By Kids For Kids (1994)

Ko, Andrew; Myers, Brad; Aung, Htet Htet. Six Learning Barriers in end user programming systems (2004)

Cathie Norris, Elliot Soloway, Jennifer Auten, Ronda Duran, Kimberly Lee, Sr. Rebecca Mierendorf, Cheryl Zuzo. We Collabrify: FREE Collabrified Apps That Support Synchronous Collaboration (2015)

Papert and Turkle. Epistemological Pluralism (1992)

Scratch Debug’ems

Jean Griffin, Quinn Burke, Elliot Kaplan. Debug'ems and other Deconstruction Kits for STEM learning (2012)

Sorva, Juha. Notional Machines and Introductory Programming Education (2013)

Wolber, David; Abelson, Hal; Spertus, Ellen & Looney, Liz App Inventor 2: Create your own Android Apps free online

APPENDIX

ACARA
YEAR 7 AND 8 CONTENT DESCRIPTIONS
Digital Technologies Knowledge and Understanding


Investigate how data is transmitted and secured in wired, wireless and mobile networks, and how the specifications affect performance (ACTDIK023)

Investigate how digital systems represent text, image and audio data in binary (ACTDIK024)

Digital Technologies Processes and Production Skills

Acquire data from a range of sources and evaluate authenticity, accuracy and timeliness (ACTDIP025)

Analyse and visualise data using a range of software to create information, and use structured data to model objects or events (ACTDIP026)

Define and decompose real-world problems taking into account functional requirements and economic, environmental, social, technical and usability constraints (ACTDIP027)

Design the user experience of a digital system, generating, evaluating and communicating alternative designs (ACTDIP028)

Design algorithms represented diagrammatically and in English, and trace algorithms to predict output for a given input and to identify errors (ACTDIP029)

Implement and modify programs with user interfaces involving branching, iteration and functions in a general-purpose programming language (ACTDIP030)

Evaluate how student solutions and existing information systems meet needs, are innovative, and take account of future risks and sustainability (ACTDIP031)

Plan and manage projects that create and communicate ideas and information collaboratively online, taking safety and social contexts into account (ACTDIP032)