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 as we developed the material.
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 interesting to have students record the hints themselves, along with their own informal, casual banter as part of our effort to make the hint less direct.
Later in other units, we have explored ways in which student comedy groups can "perform" the hints to make them more interesting. Clearly, not every attempt at humor is going to work so we hope you will be patient and use what you can from the hints while occasionally getting a break from the very technical details of programming.

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.

Why not use a sophisticated coding environment like Eclipse? Why pico?

This too is a deliberate choice.
Our experience is that tools like Eclipse impede learning because they do too much on your behalf and hide some important details.
Initially, we went with pico because it's extremely simple and widely available. Later, we encourage you to try out others such as: Emacs, Atom, Sublime, Notepad++.

Why the Terminal?

Tools like Eclipse also avoid the Terminal (or command-line, as it's sometimes called).
But understanding and being comfortable with the Terminal is a very useful long-term skill. And it's simple (if a bit crude) to use.

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 println'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 tutoring 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.