The value of simplicity and experimentation in learning programming
Way back in 1984, when I was a secondary school pupil at Dronfield Henry Fanshawe school, my maths teacher, Mr. Gibbs, introduced me to the BBC model B microcomputer – which was the cutting edge of home and school computing technology at the time, and also to a game called L: A Mathemagical Adventure, which was produced by the Association of Teachers of Mathematics (ATM).
I spent many hours exploring this game, which was a text-based game: by today’s standards it will be considered almost stone-age.
Unlike today’s computer games, the game launched within a few milliseconds (perhaps unsurprising since the graphics are almost non-existent and limited to the splash screen only). Upon launch the user was simply given two lines of instructions followed by “press the SPACEBAR to continue”.
In order to be successful in this game, players needed to be curious, patient and determined. No instant gratification with whizzbang sound effects or fancy graphics and, crucially, very few instructions. All moves had to made by typing in keyboard commands usually consisting of at most three words and often able to be abbreviated to just one character.
Unless you had an absolutely exceptional memory and vivid imagination you would not get far without a paper and pencil on hand to sketch out a map of the fantasy castle, which was depicted in the text descriptions, and to keep a note of the people, objects, puzzles and games which are encountered.
The vocabulary – by today standards – was very advanced for a game aimed at pupils aged 11 to 16. There was quite an advanced and subtle sense of humour in the language used as well. Crucially all of the puzzles, and many of the items and people encountered, were quite advanced in mathematical terms. There was no answer book for teachers. Indeed in 1996, during my own PGCE, I wrote a potential teachers’ guide including one possible set of solutions and offered it for publication, but the ATM, whilst effusively acknowledging the value of my work and praising the style and content of the book, stated that they would prefer for it not to be published, explaining “Exploring each room, finding what it has to offer, and building up a map of the whole castle takes time, but it is the exploring, problem solving and recording which are of value, rather than the achievement of any final objective.” (Clausen, T., for ATM, 1996) Therefore teachers themselves needed to explore the game in the same way as their pupils if they were to find out what the solutions to the puzzles were and how to complete the game.
As you will now have realised (through the ATM’s response to my proposed guide, if not before) the entire purpose of the game – and the whole reason that the authors wrote it – was to promote enquiry; of learning through experimentation. Unless the players (learners) are willing to take risks and happy to accept that sometimes they will make mistakes – or in common pupil parlance “get things wrong” – they will never get past the starting point of the game.
There is much in the attitudes required to play this game – and undoubtedly in the thinking of the creators – that aligns with the ideas of Dweck regarding growth mindset and “the power of yet” (Dweck, C., 2014), Vygotski’s distrust of testing to measure ability (Vygotski, L., 1934 & 1978), and Piaget’s & Bruner’s discussions on experiential learning being more effective than rote learning (Piaget, J., 1936 & Bruner, J., 1961).
I recently noted something the great Sir Ken Robinson said in a 2006 talk, in which he makes the remark “if you’re not prepared to be wrong you will never come up with anything original” (Robinson, K., 2006) and this is so important, not just to the success of the game L, but the reason that I writing this blog now.
I’ve spent the past few months working on chapters of a new textbook on mentoring beginning computing teachers. Whilst doing this, my colleagues and I have regularly discussed the necessity for successful learners of computing to be willing to take risks and not fear being wrong: if they don’t do this, they will never be able to carry out essential parts of computing work, for example debugging. Yet many computing teachers themselves fear ‘being wrong’ and regularly instil into their learners – however unwittingly – that it is necessary to reach the ‘correct’ outcome at the first attempt. This is simply incompatible with successful navigation of the computing curriculum, or successful completion of computing qualifications. Our future programmers will be hindered greatly – and indeed be unsuccessful in their work – if they are unable or unwilling to experiment and take risks without fear. To coin a phrase: by not failing, they will fail. Moving back a step we may well find that today’s computing teachers themselves grew up, and were educated, in an environment where, to quote Sir Ken Robinson on a different occasion, they are taught that “there is only one correct answer, it’s at the back of the book and it’s cheating if you look” (Robinson, K., 2010).
Last year one of my trainee teachers secured his first qualified teaching post in a further education setting. At first he was a little unsure about the setting as he had always believed that he wanted to teach mathematics in a traditional sixth-form environment, where he [thought he] would teach A-level maths to students who “wanted to learn and would be eager for challenge” (Mills, T., 2018). Shortly after taking his post, however, he commented to me how rewarding it is to work with non-traditional F.E. learners, many of whom are re-taking GCSE’s, or even working at a lower level than that. The comments that he made to me included “it’s so rewarding to see the change I’m making to these young people’s lives” (Mills, T., 2018). In more recent times my now-ex-trainee has commented to me about the rigidity of the curriculum and the necessity to move so swiftly through the topics and – significantly – about the unrelenting pressure to ensure that students get the highest possible grades (arguably sometimes the pressure is for students to obtain grades of which they are simply not capable “yet” (Dweck, C., 2016)). When I recently spoke to Tom I mentioned the game L to him, and we discussed the difference between today’s learners and the learners of the 1980’s, who were so excited and eager to play such a simplistic looking game [by today’s standards] and to take risks while spending hours attempting to work their way through a very small part of the game. I showed Tom an online emulation of the game (complete with BBC 5¼” floppy drive sound effects!) and Tom in turn showed this to some of his learners. Here is the response that he sent back to me:
“I showed it to two of my learners, both bordering 4/5 grades. They were both almost instantly intrigued by the game but confused at first by which commands work (myself included) it took us a while to attempt a puzzle but we managed to solve one where colour lights have to be alternated until you get the right sequence. They were both a little disappointed when I said I had to turn it off and they had to return to “proper” work. I might try it as a dinner time activity next week and see if I can drum up more interest as the communication in mathematical terms was really nice.” (Mills, T., 2019)
It seems to me that the environment in which all learners and teachers have been obliged to operate, for the better part of thirty years now – where success is defined by the number of high grades obtained and where the curriculum content is tightly regulated – is stifling the curiosity of our learners. It is certainly operating in a complete reversal of the mode which the writers of L knew to be of such great value and which the ATM pointed out to me when they said it was the “…exploring, problem solving and recording which are of value, rather than the achievement of any final objective.” (Clausen, T., for ATM, 1996).
In my mind I draw an analogy here between a building in which the central heating has been turned up to maximum, making the environment far too hot, but rather than switch off the central heating, the occupants turn on the air conditioning, which then fights against the central heating to control the temperature.
In a similar way, learners of computing have to be willing to experiment and take risks: to try multiple avenues, be patient, determined, and not put-off by what they may perceive as ‘failure’, and yet they are expected to do this in a learning environment where the pressures are speed, high grades and not ‘getting it wrong’.
There is a need for our teachers, perhaps even our teacher-educators, and certainly our learners, to be given permission to ‘get it wrong’, otherwise our computing students are doomed to failure: the failure of being unable to carry out required activities to be, for example, successful programmers and coders.
Dave Darwent is a Senior Lecturer: E-Learning Technologist, and course leader:
Post Graduate Certificate in Digital Teaching and Learning, at Sheffield Hallam University.
Tom Mills is a teacher of Mathematics at SHIFT Media.
Comments
The value of simplicity and experimentation in learning programming — No Comments
HTML tags allowed in your comment: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>