Course Design

Structure of the course

You will notice that:

There are units, and each unit has multiple modules and some assignments.
The modules have sections. Each section has some examples and explanations, with small module exercises for you to do.
Sometimes a group of such module exercises have an audio or video that follows.

Why do we have the structure of text, followed by exercise, with some (often obscure) audio?

Since you are learning online, watching a long lecture on programming is of limited use because programming is learned best by doing.
Most of your learning is going to come from working on programming problems by yourself.
This is why we have many short examples, demonstrations, and explanations, all of which are followed by an exercise for you to do immediately.
Important: You'll get the best results if you work on the exercises immediately after reading.

So, what are the audios/videos for?

Through experience we learned that students sometimes get stuck on the module exercises. This is generally a good thing because it means you have work a little harder at understanding, which means your learning will be deeper and more significant.
But getting totally stuck can be frustrating. The standard way of getting help in an online class is to post to a forum or to email the TA. This approach has two problems:
1. The official help channel (TA or instructor) can take a while (sometimes days), which means you lose the thread of of thought at the moment you got stuck.
2. Even worse, other students will post a forum reply in which, eager to show their knowledge, will essentially give away the solution and rob you of your opportunity to learn.
Thus, our challenge in giving you a hint is to give you a hint at the moment you need it, but with only enough information to move ahead. This is why they are a bit vague.
Of course, if you don't need the hint, you are fine to proceed.

It's difficult for an experienced instructor to know when and how students get stuck. So, to get a better feel for this:

We hired students to do the course slightly ahead of you as we developed the material for the course.
The idea was, a group of students would get stuck in different ways and on different problems, and we'd use this to craft the hints.
This turned out to be highly effective in uncovering the exact nature of hints needed.
Along the way, we realized that it was more valuable to present the "student point of view", as if you were listening in on their study group. This is the kind of learning you've experienced with peers in a study group.

Typing up your own code:

You've noticed that we try as much as possible to avoid cut-and-paste: you need to type up the whole program.
This is deliberate because research has shown that personal note-taking improves learning.
We could have done this differently by giving you a whole bunch of code where you fill in a small part. But the typing up of the whole program helps build in your mind an image of the full program, and even though it's a bit tedious (like note-taking in a history class), it makes a significant difference in helping you read and understand programs.
Important: Please type up the full program where possible. It is critical to improving your reading and comprehension.

About problem-solving:

Problem-solving is the hardest part of learning programming. That is, going from a word-description of a problem into useful code that solves the problem.
You should not expect this to be easy nor should you expect something like "Oh, I'll eventually get this, after which no problem will be difficult". You are going to get better at it but through a slow learning process.
To help you through this, each assignment begins with a solved problem.
The wrong way to gain from the solved problem is to read through casually. Instead, work through the problem yourself in steps.

The best way to help yourself without asking for help:

We've consistently observed that students do NOT use the most useful form of fixing problems: copious printing.
That is, use plenty of print's (that you later take out or comment out) to tell you what your program is doing.
Again, do not expect that adding a few println's will just make the problem clear. You also have to mentally execute the program while looking at what got printed. It's still a bit of a struggle, but the printing helps.
Important: You have get used to the idea that no program is going to be correct right off the bat. Debugging is part of programming. Believe it or not, it can even be enjoyable in a puzzle-solving detective kind of way.

Other forms of help:

We will announce office or study-hall hours.
It's best to bring all your questions in an organized way rather than bring vague, sweeping questions like "Can you help me understand arrays?"

Getting "too much help":

Important: Beware of getting too much help. If you are being helped by someone outside the course, you might not know that you are getting too much help. If you are, then you won't learn enough and you won't do well on the exam.
Please do not look at anyone else's code: a mere glimpse can be too much help. You really need to do this by yourself.

In doing and submitting your work, you've noticed that:

Why do we insist on this?

It's because we have automated tools (programs!) that read your submissions and those tools expect particular naming.
You will later see, when you write programs that work with files, why naming has to be particular and specific.

As an example consider:

2.10 Exercise: Implement the above in name_clash.py and describe what happens in module2.pdf

NOTE:

The name of the Python file is name_clash.py (all lowercase letters, with an underscore).
Any of the following (and others like these) might appear "good enough" but are NOT acceptable: nameclash.py, NameClash.py, Name_Clash.py, name clash.py, name_clash.python, name_clash.
Similarly the module pdf needs to be called module2.pdf here (because this is for Module 2).
Again, any of the following (and others like these) might appear "good enough" but are NOT acceptable: Module2.pdf, module 2.pdf, module.pdf
In many cases, we will not explicitly state the name of the module pdf, and instead write something like:
2.10 Exercise: Implement the above in name_clash.py and describe what happens
Here, it should be clear that you write code in a program, and answer the "describe what happens" in your module pdf (which for Module 2 would be called module2.pdf).
If you encounter an exercise where the program is not specified, please let us know.