Learning to Learn (to program): Tip 6

Learn by experimenting

Part of the Learning to Learn series by Paul Curzon, Queen Mary University of London

We all learn naturally but some ways of learning are more effective than others. Whether it is a skill or knowledge you want to learn there are good ways and bad ways. This series of blog posts is about how to learn quickly and effectively.

TIP 6: Build mental models by experimenting

Before you can practice effectively you need to have built the right mental models. Knowledge and skill join. One way to do this is to read explanations written by others. Sometimes there is a much better way: work it out for yourself! Learn by experimenting! For programming, this is a really powerful way to learn. Instead of building a mental model of constructs from explanations, first try and build your own mental models by reading programs others have written (simple ones to start with), and trying to work out how they work. Learn by making changes based on that and predicting what will happen, then trying by running the program.

Learn from others’ knowledge image by Free-Photos from Pixabay

This works well with programs because you can execute them and see what they do. Take a program, execute it, then look back at the program and see if you can see how it does what you can see it doing. Make a small change with a clear idea in your head now of what you think it wilo now do, then execute it again. If you were right then you have some confirmation of the mental model you have started to form. Try a different change, and so on.

To take a simple example, here is a Python program.

print "Hello World"

If you execute it, the following appears on your screen:

Hello World

Looking back at the program form an idea of what is happening… Try it before reading on.

 

The program prints messages, and there is only one line so that line must be a command to do so. Based on that, make a change to the program with a prediction that the new program will make Hello Paul (or perhaps your name) appear:

print "Hello Paul"

You execute it. It does. Now try a different change to the program:

print "Hello World"
print "Hello World"

What do you think it will do now? And so on…

You are working like a scientist, gradually building a theory based on experiment. As a good scientist you should look for changes that don’t just confirm your idea, but that will show you are wrong if you are, you want to stretch the edges of your understanding.

Once you have run out of experiments or are really stuck, then read (or listen to) the explanations. Now you have a solid basis to understand what they say. You know what they are talking about as you’ve seen it. You are also in a position to understand subtleties you have missed. If the explanations do tell you something you hadn’t worked out, go back and experiment with those aspects.

It is important that you don’t try and do too much in one go. Programs you start experimenting on should only be a little more complicated than you already understand. Changes you make should only be small and one at a time. If things go wrong, revert to a version that did work and you did understand.

Do this learning by experimentation with each new programming construct as you start to learn about it (having mastered the earlier ones first). Only read the explanations after you have experimented a little. You will understand and remember the explanations so much better that way round.

If you are a:

• student
  • Don’t just rely on explanations, experiment with existing programs.
  • Don’t spend your time copying programs, spend it making small changes to existing programs and predicting what will happen.
• teacher:
  • Encourage students to experiment and give them time to do so.
  • Provide a series of starting programs for them to experiment with.
  • Give them that code – don’t waste their time making them type it in.

Further Reading

A programming pedagogic framework that follows a similar investigative approach to this is PRIMM.

https://blogs.kcl.ac.uk/cser/2017/09/01/primm-a-structured-approach-to-teaching-programming/

A difference is we advocate above a first stage of Run code first to start a PRIMM like cycle with new constructs. The most important point though in both is that reading and predicting code in an experimental cycle matters.

 

Blog series
There will be 9 blog posts in this series, a new one will be posted every week day, but you can read the full set here: Learning to Learn series by Paul Curzon, Queen Mary University of London.

• Tip 1: Anyone can learn to program (17 November 2020)
• Tip 2: Deliberate practice (18 November 2020)
• Tip 3: Mastering skills (19 November 2020)
• Tip 4: Identify the sub-skills (20 November 2020)
• Tip 5: Mastering mental models (23 November 2020)
• Tip 6: Learn by experimenting (24 November 2020) <– this post
• Tip 7: Concept maps (25 November 2020)
• Tip 8: Feedback (26 November 2020)
• Tip 9: Semantic waves (27 November 2020)