These are the mind’s ‘mechanisms’ for explaining and predicting phenomena. I have written more in my PhD, and you can find good expansions of the idea in Michael Simmons’ post or in the Wikipedia article on Mental Model The idea originated with Craik in World War II and elaborated by Johnson-Laird amongst others, leading to an interest in developing computational models(!) of mental models – a subject of interest to me in the late eighties when I was a member of the London Mental Models group.
I do not think this is the same thing as modelling phenomena in mathematics or in computer programs – these are expressions in external languages, unlike mental models, which are mostly private, interconnected, fluid, faulty and ultimately unknowable. Expressing them externally leads to the possibility of proof, execution and formal reasoning in a shared world of knowledge – but these aren’t mental models, they are in a formal linguistic form that can be communicated to others and to machines.
Nevertheless I believe the unknowable internal mental model remains a useful notion when we think about designing learning and I apply the notion in this blog to the competence to make computer programs.
Mental models in Computer Programming
This is my first draft diagram which represents four key mental models that a learner must develop (and continue to develop) as they increase competence in programming.
This mental model allows the learner to reason about the problem itself – it may develop as problem solving and design are combined to find a solution. Sometimes prior knowledge can help – for example Papert would argue that children are competent (and have mental models) about the way their body can move in the physical world, and if the problem is aligned to such competence, they can engage more effectively and debug their program.
This mental model is about the parts of the language – the distinctions between different linguistic components and their connection to create programs. Scratch supports this mental model by categorising statements and thus offers recognition rather than recall. It also reinforces appropriate syntactical combinations, so that the focus is on their meaning, in isolation and in combination.
A strong mental model of notional machine is vital to debugging. This mental model is concerned with the variables, data store, ‘program counter’ (which statement is executed next – flow of control). It is much more complex with Scratch than in the past , since multiple parallel process are easily designed using sprites. The design of solutions in this way can be quite different from that made with single process thread programming, but makes the mental model challenging. My favourite example of this was the solution I developed using three sprites to draw lines to fill in a shape, hoping to use it with TurtleStitch to make embroidery. Then I discovered that TurtleStitch ( a Snap derivative) had only one sprite – a mismatch of my mental model of notional machine for Scratch/ Snap.
Microworld / Domain
The microworld is the concept of a limited space, designed to suit a particular class of problems and usually with an ‘object to think with’. The turtle geometry microworld is the most famous, but not the first in Logo – before that came sentence construction. Making a mental model of its affordances allows the learner to map to problems and to relate to the notional machine and the programming language, within a limited but meaningful domain.
Connections between mental models
The greatest challenge to the learning programmer is in the connections and overlaps between each of the mental models. I believe the educational designer must pay attention to each of these and the questions in the diagram are to help the designer think about that.