Over the past 15 years, my team and I have developed a computing curriculum that starts in middle school and goes all the way through the first software engineering course. We had two goals in mind. First, in middle school programming should be aligned with mathematics---it should demonstrate how much fun it can be to write down and then run mathematics. That way all students would benefit from the introductory course, even if they never take another course again. Second, once we had students hooked on programming, we wanted to teach them a systematic problem solving process. While teaching by example is necessary, it is impossible to rely on it exclusively; students invariably fail to grasp the implicit design lessons. Students should therefor see a method for designing programs that consists of well-defined generic steps and where each step produces checkable intermediate products.
In this talk I present the three major lessons of this projects. First we can turn mathematics into a fun programming exercise, if the language and its IDE support an arithmetic of images. Second, no off-the-shelve professional language can truly support novice programmers. We need to specify and implement language subsets, ideally an entire hierarchy of them. Third, I will sketch some of the major elements of systematic program design. For the remainder of the talk I will briefly discuss some of our technical failures and challenges.