This document describes how I run the CS111 class at USP. It is intended as a support document to clarify any assumptions that you may make about the course. The first two guidelines are:

Guideline 1

We start from the assumption that no student has had programming experience.

Guideline 2

There is no such thing as a stupid question.

When we start the course we assume everyone is at the same level of expertise. If you have previous programming experience then you may find some aspects of the course easier to pick up. However, I will place strong emphasis on the quality of your work, not just whether you produce the correct output in a given program. As such, those of you with previous experience may have to ‘unlearn’ some bad habits.

Moreover, there is no such thing as a stupid question. If you don’t understand something, then ask about it. Programming is full of things that we call threshold concepts. That is, if you understand the threshold concepts then you get to progress quickly. If you don’t grasp them, then learning programming can be a horrible slog. Even with 20 years experience I often get caught out on ‘simple’ things when I’m learning a new programming language. I often have to ask really basic questions of programmers with more experience in the language than I. I am expecting to answer many, many basic questions form my students – that’s exactly what I’m paid to do.

Guideline 3

Attendance in labs is mandatory.

Guideline 4

There will be weekly quizzes.

In a face-to-face course at USP you are required to attend 60% of the laboratory sessions. In the lab sessions there will be work that should take about 40 minutes to complete. The work is based on a flipped classroom model. That is, you will attempt to solve problems that will be described in the lecture the following week. Do expect the lab sessions to be challenging.

There is a course requirement for weekly quizzes. The quizzes are provided as Moodle quizzes and will take a maximum of 10 minutes each week. The quizzes will only be open during lab times. This means that completion of the quiz will mark you as having attended the lab session for that week. If you do not complete 60% of the quizzes, then you will fail the course.

Guideline 5

Self-assessment is the start of professional development.

Your assignments will ask you to complete some work and then to evaluate your own performance on that work. To evaluate your own performance you will be given a self-assessment work sheet. Being able to evaluate your own learning and competence is the mark of a quality professional programmer. We will use the self-assessment in CS111 to start you on that journey.

Guideline 6

Rote learning does not help.

In many countries you can do well in secondary school/high school by learning vast chunks of text by rote. This is not a skill that has a large impact on your ability to do quality programming. The programs that you will write to solve problems will be vastly differing. The skills of generalisation and abstraction (often closely associated with Maths) will help you more than learning-by-rote. We will be creating new programs each week. If you have any experience with creating this will stand you better. Examples of creating include painting, dance, playing a musical instrument, and playing chess or any team sport. In order to play chess or a team sport you have to work hard to create a performance. In the team sport example you have to solve problems to make sure your 15 players (in rugby union, or 11 in soccer, or 7 in sevens or 5 in volleyball) can outwit the other team. These creative skills are arguably higher cognitive functions than “mere” rote learning.

Guideline 7

Learn about the tools we are using.

The lab demonstrators can provide lots of help in using our development environment. However, development environment are much more powerful than the simple features that we use in first year. You should independently read the manual of the development tools that you are using. We will not be reading the manual in class. By reading the manual you both learn to understand the language that developers use day-to-day and you can be a more productive developer.

Guideline 8

Professional conduct in written work.

Some programmers swear and use comparisons that others might find insulting. We work in a multi-cultural environment. As such, I won’t accept work that contains swearing (for example, in the source code comments). I also won’t accept work that is demeaning to other students (for example, it insults a particular cultural tradition). There is no need for either of this type of professional transgression in the work that we will perform in lectures, labs or for an assignment.