How to succeed in this module

Comments and questions to John Rowe.

The level of this course

This course operates at the level of a module in a science degree in a Russell-Group university. So this is not one of those "learn to program without knowing what you are doing" courses, but neither is this a Computer Science degree where they are interested in the internals of how computer processors work and in pushing forward the state of the art.

This fits in well with how computer languages work. The definition of the C language (and all other programming languages) is based on a very simple conceptual model of a computer: it is a device that can execute instructions and store numbers in numbered locations in its memory. We will not be learning about the complicated (and very interesting) processes that go on "under the hood" to make this possible.

Ironically our understanding of the computer will be very, very simple as the computer is designed to hide its complexity from us and to take very simple instructions and make them happen very quickly without giving any indication that the underlying complexity even exists.

Engage

The key to success is, of course, to engage both with the materials and with the teaching staff. Both are here to help you learn.

The good news

• We do not expect you to know anything about computer programming before the start of this course.
• There is no workload after the end of term (weeks 1-12).
  
• There is a good amount of on-line material to support you
• You are always encouraged to come to me for help or to ask questions. We don't expect you to be able to magically learn this on your own.

The bad news

• We do expect you to be able to learn something new and to be willing to think logically.
• The same amount of work has to be done in less time so the term is busier.
• Continually assessed modules do not respond well to trying to busk it on the day.
  
• If you do not use the support and support materials you will still be marked as if you did.

The three basic programming skills

Fundamentally programming requires three things:

1. To be able to understand what a small piece of our program will do.
   If we look at a few lines of our computer program and we can't work out what it does then clearly we will never be able to get our program to do what we want. This is the key low-level skill.
2. To be able to organise complex tasks and their data into a logical structure that we can understand and that reduces the chance of mistakes.
   We can't just write more and more small pieces of the program until we have done the whole job in one gigantic blob: we can only think about a small number of things at a time and so we must split large problems into small independent chunks that we can think about on their own. This is the key high-level skill.
3. Finding and fixing errors.
   Sadly, we all spend a lot of our time trying to work out why our program isn't doing what we want it to to do.
   In practice this is mainly about finding mistakes; if we know where the mistake is it's usually not too hard to fix it. This is the key diagnostic skill.

The nature of the C language.

All computer languages, but C in particular, operate on the axiomatic principle of simple logical concepts consistently applied. The good news is that the concepts are simple compared to,say, quantum mechanics or calculus. The bad news is that there is no alternative to learning them and C programming does not respond well to "pattern recognition" where we don't bother to learn the concepts but just give it a go. Nor do we write assessments that can be answered even if you don't understand the material - "not bothering to learn" is not a learning strategy!

But of course, we don't really understand anything practical until we have actually done it, and the final objective will be that we recognise common patterns without having to consciously go back to the simple rules. But we will always be able to understand these patterns in terms of the simple rules if we need to.

The real challenge is combining simple principles together

The key to "simple logical concepts consistently applied" is the ability to apply combinations of concepts. In theory this sounds simple but in practice a common situation is that we think we understand concepts A and B in isolation but when we try to apply concepts A and B together we suddenly discover the limits of our understanding. It can be equally confusing to have to apply concept A twice, i.e. to apply concept A to itself.

Treat the process of combining two simple concepts together (or applying a simple concept twice) as a challenging learning objective in its own right. Expect to have to think it through but also have the confidence that since each individual concept is quite simple you will be able to. And expect to occasionally be surprised when combining two simple concepts allows us to be able to do something quite clever.

The lectures: on-line and/or in person

The lectures are designed to be accessed either on-line or by physical attendance or both. Exactly the same material is covered in the in-person lecture as on-line. For the fourth and subsequent lectures students who are not on report and who are making adequate progress can choose whether to take the on-line or in-person form or both.

On-Line lessons

• If you have not logged in look for the "Login" button at the bottom left of the page.
• Each section then has a longer "tutorial" view and a shorter "reference/revision" view.
• Clicking on the + or - next to the section heading toggles between the two.
• You can add your own notes by clicking on the large "notepad" con at the bottom left of the page and then one of the smaller icons that appears at the end of each paragraph.
• Notes are always editable and clicking anywhere outside the note will upload them to the server.

Mini-exercises etc

The notes contain small interactive mini-exercises. Students using the on-line approach should do them as they go through the lecture, students attending physical lectures should do them afterwards, before the practical class. You should expect to spend two to three hours in total on each lecture.

The most common exercises are:

• Stepping through a short piece of code to see what the program does
• Writing tiny programs ourselves to illustrate the concept. Generally these are not much more than typing but never Copy and Paste from the lecture notes, as it's the act of typing it in ourselves that will help us remember it. To aid on-line study we provide a small web-based compiler for you to do the exercises within your web browser.

In addition some lessons have a few simple questions whose aim is to get you to think about the issues before we meet them.

The basic learning cycle

1. Do the on-line lessons and/or attend the in-person lectures. Make sure you do all the mini-exercises.
   
2. Revise, study the examples, do any quizzes, look for other information in books or on the web.
   
3. Apply this knowledge to writing programs and develop higher-level skills - by far the most time-consuming part!
   

• At all times don't be afraid to ask questions or come to me for help.

A cycle not a linear process

At first sight the above looks like a linear process, not a cycle. But in practice, stages 2 and 3 tend to show up areas that we didn't understand as well as we thought we did, forcing us to go back to the beginning. So it's best thought of as a cyclic process where the level of our non-understanding decreases with each cycle.

The learning cycle in detail

The on-line lessons

Go through the on-line lessons performing the mini-exercises and adding your own notes so that these combined with the compressed view of each section give you a good reference to the material and reminder of any points you initially found confusing.

Don't try to separate learning from doing

The on-line lessons combine information with small interactive mini-exercises. The temptation then is either skip the information and just try the mini-exercises or to read the information and skip the mini-exercises and just get through the notes as quickly as possible. Or even to skip the lessons altogether and go straight to the main exercises! Don't do any of these: It is impossible to separate theory and practice.

Revising, studying the examples, and doing any quizzes

The primary purposes of this section are to accelerate the next one (which is the one you will spend by far the most of your time on), and to maximise the chance that you actually understand what you are doing rather than just trying things at random until one of them seems to work. Depending on your preferred learning style you may prefer to do this alone with a friend, with or without the recorded lecture.

When revising the lectures you should be able to understand exactly what each in-lecture example will do and in case of any doubt confirm this by stepping through it.

Quizes

Some of the earlier lectures have on-line quizzes which have been written to address problems students commonly have. All quizzes have the choice of a conventional quiz with a score of right and wrong answers, or as games for one or two players. Playing a two-player game is likely to be particularly beneficial and is recommended.

Examples

The separate examples, for study after the lecture, tend to illustrate the points in the context of a small, but complete program. Again, step through them if you are not sure what they do (or just to confirm you are right).

Common mistakes

Some lectures have a page of common mistakes with one or more incorrect or bad codes and a suggested good code. These are heavily inspired by the mistakes we see students actualy making.

Exercises

Exercises should be approached in the same way as assessments except that they are not handed in.

Appendices and optional examples

The occasional appendices and optional examples in this module are for advanced material that you will not need for this module. They are intended for enthusiastic students who are interested in going further in programming for its own sake. We recommend most students do not read these. If you have any questions about these please speak directly to the module leader, not to the demonstrators.

Time allowed for revision and quizzes

The module description has 16 hours of lectures and 58 hours of "Reading to support own learning requirements", so you do the maths!

Applying the knowledge to writing programs

Writing programs is not only the end objective of the module, it is also the main learn process by which we learn.

(At this point it is traditional to paraphrase Aristotle as saying " For the things we have to learn before we can do, we learn by doing." which has the advantage of emphasising the cyclic nature of the process.) This will be by far the most time-consuming part of the module which means it is a very false economy to skip the "Revising, studying the examples, and doing any quizzes" section to move straight on to this.

Preventing and finding problems with our programs

When we start to write programs we discover the distressing fact that it takes much longer than we expect. The two main problems tend to be:

• Working out what we want to do.
• Preventing, finding and fixing mistake (known as "bugs"). The process of fixing these is called debugging and can easily take more time than the rest of the module put together.

Working out what we want to do

1. Work out what the data is, and which parts of the program need it. For example, if we are solving a real quadratic equation the core data is the three coefficients and we will then need to work out the discriminant. We will then have one or two real solutions and either two complex solutions, or one complex solution with the understanding that its complex conjugate is also a root. These latter will only be needed by part of the program.
2. Look for separate identifiable sub-tasks Later in the module we will see how these can be made into separate functions that can be written, tested and debugged separately. Even before then, however, these can form the steps referred to below.

Preventing, finding and fixing bugs

The module has a whole lecture on Bugs and Debugging, but here are some of the key points.

Prevention

• Work in stages, writing a little code at a time and check it thoroughly before moving on to the next piece.
  
• The programs that take a lot of time to get working are the ones where we have let a bug slip through and have to find it later, not the ones where we have spent time checking for bugs as we go.
  
• Put checks into your program
  

Cure

• Mentally step through your code, making sure it does what you want it to do.
• Get more information by printing stuff out.
  
• Print out information that tells you the progress of the program.
  
• Print out information that tells you whether the program is correct so far (and check it!)
  
• Print out what the number, etc,  is, not just its value, and make sure the message identifies where it comes from in the program
  

Getting help

The ELE page has a link to the PHY2027 chat window.

See the page on acceptable and unacceptable collaboration and then chat to your friends.

If that fails, ask me:

I would suggest that if you haven't made progress for 15 minutes you should either come to my office or drop me an email with your code as plain text (copy and paste it into your email).

Helping students with their problems is an important part of my job leading a module such as this.

Log in