The Communications Web site, http://cacm.acm.org,
features more than a dozen bloggers in the BLOG@CACM
community. In each issue of Communications, we’ll publish
selected posts or excerpts.
Follow us on Twitter at http://twitter.com/blogCACM
DOI:10.1145/2492007.2492012
http://cacm.acm.org/blogs/blog-cacm
teaching Programming
the Way it Works
outside the classroom

 

Philip Guo teaching Real-World Programming http://cacm.acm. org/blogs/blog- cacm/159263-teaching- real-world-programming/fulltext January 7, 2013

In this post, I describe a ubiquitous style of programming that, to my knowledge, has never been formally taught in the classroom.

In most programming classes, students write programs in a single language (e.g., Java, Python) and its standard library; they might use a well-documented third-party library for, say, graphics. Students fill in skeleton code templates provided by instructors or, at most, write a few chunks of code “from scratch.” Specifications and interfaces are clearly defined, and assignments are graded using automated test suites to verify conformance to specs.

What I just described is necessary for introducing beginners to basic programming and software engineering concepts. But it bears little resemblance

to the sorts of programming that these students must later do in the real world.

Over my past decade of programming, I have built research prototypes, extended open-source software projects, shipped products at startups, and engaged in formal software engineering practices at large companies. Regardless of setting, here are the typical steps my colleagues and I take when starting a new project:

1. Forage: Find existing snippets of code to build my project upon. This might include code I wrote in the past or that colleagues sent to me in various stages of bit-rot. If I am lucky, I can find a software library that does some of what I want; if I am really lucky, then it will come with helpful documentation. Almost nobody starts coding a real-world project “from scratch” anymore; modern programmers usually scavenge parts from existing projects.

2. Tinker: Play with these pieces of
existing code to assess their capabili-
ties and limitations. This process in-
volves compiling and running the code
on various inputs, inserting “print”
statements to get a feel for when cer-
tain lines execute and with what val-
ues, and then tweaking the code to see
how its behavior changes and when it
breaks. (Now loop between steps 1 and
2 until I am satisfied with my choice of
building blocks for my project. Then
move on to step 3.)