A project-based approach in learning to code
How would you introduce programming to students? If taught in the same fashion as many other content areas, you might identify a set of basic concepts, perhaps the most commonly used commands and techniques, require some basic exercises that use these concepts, and then gradually expand this core to include logically related skills. We would not argue that this approach makes no sense, but we also want to bring a different and possibly supplemental approach to your attention. This second approach is rooted in such ideas as a community of practice, apprenticeship, and authentic tasks that we presented in the second and eighth chapters (Meaningful learning in an information age, Projects for learning). If it seems we are contradicting ourselves in terms of a more systematic approach to programming instruction, to some extent we are. The direct instruction versus constructivist division has come up several times in our description of instructional approaches. The approach we describe here involves discovery, but it is not random, trial and error.
I learned to program on my own and I learned because I promised a computer company I would develop some instructional reading games if I was given some free computers. I was given the equipment and so I had to deliver. At first, I tried to learn by using manuals. I purchased one resource that was pretty much a textbook and I had a manual that came with the equipment that provided an explanation of the BASIC programming language and how each command in the language worked. Slowly and systematically I tried to work my way through the instructional materials. It was very frustrating. I was learning some things, but what I was learning did not seem related to where I wanted to end up and my progress was so slow. It did not seem likely
I would be able to generate anything useful within a reasonable period of time. I remember trying a different approach. As strange at this might sound now, at that time you could go to bookstores and purchase a large variety of magazines written for those with different levels of computer expertise. Some of the magazines for hobbyists contained the code for various simple programs. The articles would discuss a technique or an activity and then offer a listing of the corresponding code. You could then sit at the keyboard of your computer and enter programs that seemed interesting. What these examples gave me was a way to get closer to the kinds of projects I wanted to create. Perhaps I could find a game that involved displaying text on the screen. Perhaps I could locate a way to time how long it took a user to respond to a request generated by the program. Entering line after line of code from a magazine was a difficult task and I inevitably would made errors. I would misspell a command or forget a punctuation mark. Typically, the program I entered would not run when I finished and gave it a try. I learned from this process in two ways. First, when the program did not work, I learned to search for errors - debugging. One of the things programmers must accept is that often what they generate does not work on the first try. You learn a lot from trying to figure out what went wrong. Second, once I had a program working I tried to understand how the program worked and I tried to modify it in different ways. If there was a command or technique I did not understand, I would use my books to search for an explanation and I could test my understanding of this explanation by trying to modify some part of the existing program to produce a different result. This process was purposeful rather than random. Finally, I interested a graduate student in what I was trying to do. I had equipment to share and he had a better background than me. After exploring for a while, we just started to turn our ideas into working prototypes and then refine the prototypes into more sophisticated products. Learning other languages for a wide variety of projects followed. Getting started turned out to be the most significant challenge.
Several current efforts to support the development of young programmers share characteristics that I now recognize in my own experience. Blockly (a coding environment we describe elsewhere) and Scratch (a well established community sponsored by MIT based on a visual building block approach very similar to that used in Blockly) both offer a large number and range of examples novices can explore. So, you can try the example and also examine the code. The Scratch community, an early innovator in this approach, encourages a remix approach. The Massachusetts Institute of Technology (MIT) has developed the Scratch language and maintains the online site from which you can access the language and submit projects you create. The understanding you accept when you submit a project is that others (called scratchers) can use your project, change it, and submit what they have built using your work as a starting point. When we discuss copyright issues in our chapter “Responsible Use of Technology”, we describe this arrangement as a Creative Commons Share Alike license. The sites offering these programming environments offer tutorials, but they also offer examples. You can explore what others with more experience have done and you can find examples that fit your personal interests. The online sites offer easy access to far more resources than my trips to the bookstore could make available and are available at no cost. If interested as a teacher, we encourage your exploration of these resources. The Scratch site in particular has recommendations teachers can use to guide introduction of coding in the classroom. Collaborations within a classroom are certainly a great way to develop projects (see Fundamentals for Design Teams in the chapter Authoring and Tutoring to Learn), but the Scratch site also offers suggestions for developing online collaborations.