Learning to Learn (to program): Tip 8
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 8: Immediate, frequent feedback matters
The real key to deliberate practice, to putting in hours of practice that is as effective as possible, is to have immediate and frequent feedback. You need to find ways to be sure what you are doing is right (or wrong). You need to practice the right things and fix the causes when you get things wrong. Otherwise, with all that practice you could just be getting better and better at doing it badly.
Building appropriate mental models of sub-skills is an important part of this as it can give a basis of being able to providing feedback yourself. The understanding you have can help you work out what you must have done wrong. When a musician plays the wrong note, if they can hear it sounds wrong, they have some feedback. They can work on that note until they consistently get it right.
Programming provides natural forms of feedback. If you write nonsense that isn’t a program at all, perhaps because a single bracket is missing, or because something was mis-spelled, then when you compile the program, the compiler will tell you about your mistakes. The feedback is immediate. Compile your program frequently and you will get frequent feedback.
Similarly with a good test plan, and knowing what you are trying to implement you can get immediate feedback as to whether a program does the thing you intended or not in all situations.
This will only be helpful if you were not trying to do too much at once. If you spend days (or even hours) trying to write complex programs, before compiling and running then the feedback is not immediate. You only get feedback when you finally finish the whole thing. Therefore it is really, really important you practice by writing small programs, not large ones bigger than anything you’ve tried before.
When you do write larger programs, it is important that you build them a step at a time, adding to them a little at a time, then recompiling and testing them. This requires you to have understanding of the structure of programs as you need with each change to still have what you think is a valid program. This is a skill to gradually develop too.
So again we see that it is important to not try and make too large steps at once, to learn to program effectively.
It is because there are these natural feedback mechanisms in programming that many people teach themselves to program. As long as they are not put off by making mistakes and see them as learning opportunities they can use feedback from compiling and running programs to get better and better.
If you are a:
- Practice writing small programs that introduce single new things at a time.
- Write programs a little at a time, recompiling, running and testing frequently.
- Don’t be frustrated by compiler messages, see them as feedback to help you improve.
- Test programs thoroughly, not just once and then assume it works
- Set programming exercises that are small
- For large programs encourage iterative development.
- Provide exercises with test plans, teaching debugging skills.
- Provide other mechanisms for immediate feedback if you can, eg marking programs on the spot as a student completes them, not having them handed in with feedback days or weeks later.
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)
- Tip 7: Concept maps (25 November 2020)
- Tip 8: Feedback (26 November 2020) <– this post
- Tip 9: Semantic waves (27 November 2020)