How to succeed in this module
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.
The key to success is, of course, to engage both with the
materials and with the teaching staff. Both are here to help you
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:
- 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.
- 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
- 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.
- 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
- 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.
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
- 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
- Do the on-line lessons and/or attend the in-person lectures.
Make sure you do all the mini-exercises.
- Revise, study the examples, do any quizzes, look for other
information in books or on the web.
- Apply this knowledge to writing programs and develop
higher-level skills - by far the most
- 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
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.
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.
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).
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 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
- 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.
- 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.
- 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
- 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
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:
If you have problems with your coursework
outside of the class be sure to ask for help.
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.