Edited by Christopher Douce, Friday, 16 Feb 2024, 16:01
Over the last few years, I’ve been tutoring M250 Object-oriented Java programming. During some of the tutorials that I facilitate, I share set of tips with students. What follows is a brief summary of the tips, and some accompanying notes. I hope these might be helpful to anyone studying M250, or any other OU module that involves a bit of programming.
1. You can't learn programming by reading the course books. You need to do it. You need to spend serious time playing.
It’s important to spend some quality time with the language that you’re using and the integrated development environment that you’re using to manipulate that language. You can only properly learn to get a feel for both object-oriented programming, and programming constructs by using them. Get a feel for the words and the punctuation that you’re using. Also, instrument your code with print statements, and consider using a debugger to really see what is happening. Play and mess about. Getting yourself in a tangle is all a part of the process. There is another related tip is: do one thing at a time.
2. Use the examples as a starting point; then go further.
Start to play, and then to play a bit more, and see where this will take you. Invariably, you’ll end up writing more and more code. This means that you’ll get to a point where you need to think about how to make things a bit easier again. If you’ve found a problem in a textbook, think about how might alter that problem to solve a slightly different problem, or a more general problem.
3. Accept that things are going to be uncomfortable sometimes: it’s impossible to understand everything at once, things will only make sense after you've spent the hours playing and learning.
There’s a lot going on with object-oriented programming.
There’s the key ideas of types (or classes), objects, attributes and member functions. Not to mention, of course, how objects might work with each other to solve problems. Plus, there’s constructors, libraries and iterators.
It’s all a lot of take in, and it isn’t a surprise if you start to feel a bit overwhelmed. If you see difficult things and struggle to understand what is going on, accept certain things at face value for the time being; full understanding will come a bit later.
4. Always make a backup copy.
This relates to the first tip: playing.
When you play with code, you can also mess things up and get yourself in a tangle, especially if you follow tip 2 where you build on earlier things you have earlier done. As you figure everything out, make sure you take a backup copy of your code. If you’re making lots of changes, you might want to create different versions of your code. You might create a copy, save all your files in a new directory and call it ‘version 1’, ‘version 2’ etc.
Also, do make sure you save your files in a location that is different your computer, just in case your computer goes wrong. A bit later on, you might start to use something called GitHub.
5. Try to explain your code to someone else. (Or, get a plant, and call it Dijkstra)
Sometimes coding presents some real puzzles; sometimes there’s something that isn’t quite understood, or something doesn’t quite work as expected. As a developer, I’ve sometimes had bugs which have been both weird and persistent. When this happens, I would “have a chat with Dijkstra”.
Let me explain. I once heard that in a computer lab in Cambridge, there was a houseplant, which was named called Dijkstra, named after a famous Dutch computer scientist called Edsger Dijkstra. If a student was struggling with some code, and asked themselves the question “why doesn’t this work?” they were told to explain their code to Dijkstra. The very act of explaining your code, a step at a time, has the potential to help you to understand what is happening, and what the problem is.
If you have a partner, sibling, or pet, they can all become Dijkstra.
6. If you keep going over the same things time and time again, don’t be afraid to step away from it. Sleep on it, and come back to it with fresh eyes.
In computing, there’s a term called thrashing, which is sometimes used to describe a phenomenon that occurs with computer operating systems. This needs a bit of explanation, so please do bear with me.
Your computer has two types of memory: random access memory, and backing store memory. Random access memory is fast and expensive, but your computer doesn’t have very much of it. In contrast, there is typically a lot backing store memory in your computer (which used to be held on a magnetic disk), which is pretty inexpensive in compared to random access memory. Your computer operating system provides programmers with a lot more memory than is actually available through random access memory. It does this by moving data between different types of memory.
Thrashing is what happens when your computer operating system causes your computer to spend all its time trying to get things done by moving data between different types of memory, rather than doing the work that needs to be done.
If you find yourself ‘thrashing’, you need to reboot. You need to step away from your code and come back to it after a break.
I remember once having an idea about how to solve a coding problem when I was having a shower. A break can do you the world of good. This point leads me to my final point.
7. Have fun, and be gentle with yourself.
Everyone learns at different speeds; learning isn’t a race, so do be gentle with yourself. It’s important to have fun too. I remember that one of my first object-oriented programs was a simulated card game that was based on a television gameshow. It was fun to write, and it was fun to play. This point about playing takes us back to the first point: you can't learn programming by reading the course books; you need to find the time to play.
Object-oriented programming: seven tips
Over the last few years, I’ve been tutoring M250 Object-oriented Java programming. During some of the tutorials that I facilitate, I share set of tips with students. What follows is a brief summary of the tips, and some accompanying notes. I hope these might be helpful to anyone studying M250, or any other OU module that involves a bit of programming.
1. You can't learn programming by reading the course books. You need to do it. You need to spend serious time playing.
It’s important to spend some quality time with the language that you’re using and the integrated development environment that you’re using to manipulate that language. You can only properly learn to get a feel for both object-oriented programming, and programming constructs by using them. Get a feel for the words and the punctuation that you’re using. Also, instrument your code with print statements, and consider using a debugger to really see what is happening. Play and mess about. Getting yourself in a tangle is all a part of the process. There is another related tip is: do one thing at a time.
2. Use the examples as a starting point; then go further.
Start to play, and then to play a bit more, and see where this will take you. Invariably, you’ll end up writing more and more code. This means that you’ll get to a point where you need to think about how to make things a bit easier again. If you’ve found a problem in a textbook, think about how might alter that problem to solve a slightly different problem, or a more general problem.
3. Accept that things are going to be uncomfortable sometimes: it’s impossible to understand everything at once, things will only make sense after you've spent the hours playing and learning.
There’s a lot going on with object-oriented programming.
There’s the key ideas of types (or classes), objects, attributes and member functions. Not to mention, of course, how objects might work with each other to solve problems. Plus, there’s constructors, libraries and iterators.
It’s all a lot of take in, and it isn’t a surprise if you start to feel a bit overwhelmed. If you see difficult things and struggle to understand what is going on, accept certain things at face value for the time being; full understanding will come a bit later.
4. Always make a backup copy.
This relates to the first tip: playing.
When you play with code, you can also mess things up and get yourself in a tangle, especially if you follow tip 2 where you build on earlier things you have earlier done. As you figure everything out, make sure you take a backup copy of your code. If you’re making lots of changes, you might want to create different versions of your code. You might create a copy, save all your files in a new directory and call it ‘version 1’, ‘version 2’ etc.
Also, do make sure you save your files in a location that is different your computer, just in case your computer goes wrong. A bit later on, you might start to use something called GitHub.
5. Try to explain your code to someone else. (Or, get a plant, and call it Dijkstra)
Sometimes coding presents some real puzzles; sometimes there’s something that isn’t quite understood, or something doesn’t quite work as expected. As a developer, I’ve sometimes had bugs which have been both weird and persistent. When this happens, I would “have a chat with Dijkstra”.
Let me explain. I once heard that in a computer lab in Cambridge, there was a houseplant, which was named called Dijkstra, named after a famous Dutch computer scientist called Edsger Dijkstra. If a student was struggling with some code, and asked themselves the question “why doesn’t this work?” they were told to explain their code to Dijkstra. The very act of explaining your code, a step at a time, has the potential to help you to understand what is happening, and what the problem is.
If you have a partner, sibling, or pet, they can all become Dijkstra.
6. If you keep going over the same things time and time again, don’t be afraid to step away from it. Sleep on it, and come back to it with fresh eyes.
In computing, there’s a term called thrashing, which is sometimes used to describe a phenomenon that occurs with computer operating systems. This needs a bit of explanation, so please do bear with me.
Your computer has two types of memory: random access memory, and backing store memory. Random access memory is fast and expensive, but your computer doesn’t have very much of it. In contrast, there is typically a lot backing store memory in your computer (which used to be held on a magnetic disk), which is pretty inexpensive in compared to random access memory. Your computer operating system provides programmers with a lot more memory than is actually available through random access memory. It does this by moving data between different types of memory.
Thrashing is what happens when your computer operating system causes your computer to spend all its time trying to get things done by moving data between different types of memory, rather than doing the work that needs to be done.
If you find yourself ‘thrashing’, you need to reboot. You need to step away from your code and come back to it after a break.
I remember once having an idea about how to solve a coding problem when I was having a shower. A break can do you the world of good. This point leads me to my final point.
7. Have fun, and be gentle with yourself.
Everyone learns at different speeds; learning isn’t a race, so do be gentle with yourself. It’s important to have fun too. I remember that one of my first object-oriented programs was a simulated card game that was based on a television gameshow. It was fun to write, and it was fun to play. This point about playing takes us back to the first point: you can't learn programming by reading the course books; you need to find the time to play.