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.)