Mental Models in Programming

This post is made referencing Chapter 6 "Getting better at solving programming problems" from the book "The Programmer's Brain: What every programmer needs to know about cognition".  

Mental models are in general stored in the LTM, and relevant or selected ones are identified and recalled for use.  They are also stored in the WM for processing temporarily because they are learnt, created, organised and adapted there to form different representations of the code.  Hence, both flashcards and visualisations will help us to remember and use mental models.  The STM is likely used to support mental models too, although it is used more for assisting in the storage of inputs and outputs from the processing in WM.  Mental models are generally used to solve problems. 

In trying to solve the problem of understanding complex code, we can use the models of state diagrams, dependency graphs, architectural diagrams of the code, or entity relationship diagrams of a software system, which are all explicitly created outside our brains.  Hence, they are local models, which are in general computationally simpler or quantitatively smaller so that our memories can process and store them with less assistance at the start.  With the help of local models, users' WM can focus on creating larger mental models with more ease.  A mental model of code enables reasoning about the relevant elements, interactions and constraints in the code.  This means asking and answering questions about the code and refining the mental models.  Mental models can also be based on remembered schemata of trees, networks and systems from our LTM.  The details depend on the domain, programming language, and architecture of the code, but they generally have data structures, design patterns, architectural patterns, diagrams, and modelling tools.  

In general, mental models are incomplete because they simplify and abstracts away irrelevant details.  These abstractions can be specific to notional machines, which are models used for reasoning about how computers execute code at the required level of abstraction.  Mental models are not permanent and can be adapted to fit the problems.  The degree of complexity and nature of the mental models are dependent on the users' abilities, expertise and beliefs, so multiple mental models can coexist and they can be inconsistent with each other.  Simpler mental models are sometimes locally coherent, but globally inconsistent.  Mental models are usually kept simple and concrete so that users' brains consume less energy in processing the model and information inputs, and if more processing or storage is required, they are usually done outside of our brains, such as by pen and paper, and by using computers.  

This is another helpful post about mental models, with a "Hierarchy of needs for code and systems" that is quite relevant to coding: 

https://copyconstruct.medium.com/effective-mental-models-for-code-and-systems-7c55918f1b3e