Programming as Design

Programs are written firstly to be understood by people, and only secondly to be understood by computers.
some famous person

Your typical computer programming class goes something like this:

Each time the class meets, the instructor lectures on some new programming concept, and assigns homework. Then the students go home, or to the lab, and try to write programs that do what the assignment wants. Maybe they work; maybe they don't; maybe the students stay up late at night trying to find the bugs in their programs before the deadline. They hand in their programs. Somebody grades them and they get back a number that's supposed to indicate how good their program is. Then it's on to the next lecture and the next assignment.

What's wrong with this picture?

Well, the students generally work alone. They don't usually discuss code with each other because they're not supposed to plagiarize, or because it's too difficult to coordinate. When groups work on projects, they carve up the program into pieces so that each person can go off and work alone. This means no one gets to see anyone else's code.

Most of the time, the grade isn't very informative. The professors and TAs usually don't have a lot of time to write comments, so if a student gets a high or low grade, there isn't much explanation why. The only way students can evaluate their work is by running their programs and seeing if they function. But functionality is not the only measure of goodness.

Because no one sees the code except the grader, and because the students only know that their grade depends on whether the program works, they don't consider the code itself an artifact that they take pride in. It's just this thing that has to work, no matter how it looks.

How are students supposed to become better programmers, and in particular programmers who appreciate virtues other than just functionality, with so little feedback?

Programming is not mindless labour, like entering data or making coffee. Neither is it just pure problem-solving, like doing geometry problems. The act of programming is a blend of problem-solving, design, and expression. So it makes sense to teach programming more like other classes in design are taught.

In the design world, there's more emphasis on students learning from each other than in engineering. The central activity of a design class is the critique, in which students present their work for review; everyone asks questions and offers suggestions. Students come to understand what is good or bad design by looking at many examples of actual work.

The plan for the "Beautiful Code" course is to take this more design-oriented approach. I'd like the story to look more like this:

Each time the class meets, it begins with a review of the student work done that week. Maybe there isn't time to go through all of the submissions, but some of the interesting ones have been picked out. The class critiques the work together, asking the author about what they find interesting or unclear in the code. In this way, the whole class learns what makes code easy or hard to understand. Maybe a student got most of the assignment working, but wasn't able to get everything working perfectly. Instead of simply handing the student a low grade, the instructor can bring up the work for the whole class to debug together, until it works, and everyone has learned something. When the students go off to do the assignments, they know their work might be on the big screen next week. So they try hard to make it look good. The students are encouraged to talk about the assignments and work on them together. They don't have to be isolated by strict rules to prevent plagiarism, because they have to be prepared to defend their work to the class.

Naturally, in order to get to the critique stage, students have to be able to write programs. So it's best to teach in a language that will let us get through the basics and into writing real programs as quickly as possible. That makes Python an ideal choice.