ably did not design their code with my specific use case in mind. The gulf of execution is often vast: conceptually simple features take longer than expected to implement.

6. Refactor: Notice patterns and redundancies in my code and then create abstractions to generalize, clean up, and modularize it. As I gradually refactor, the interfaces between my code and external code start to feel cleaner, and I also develop better intuitions for where to next abstract. Eventually I end up “sanding down” most of the rough edges between the code snippets that I started with in step 4.

(Now, repeat steps 4 through 6 until my project is completed.)

I do not have a good name for this style of programming, so I would appreciate any suggestions. The closest is Opportunistic Programming, a term my colleagues and I used in our CHI 2009 paper where we studied the information foraging habits of web programmers. Also, I coined the term Research Programming in my Ph.D. dissertation, but the aforementioned six-step process is widespread outside of research labs as well. (A reader suggested the term bricolage.)

Students currently pick up these hands-on programming skills not in formal CS courses, but rather through research projects, summer internships, and hobby hacking.

One argument is that the status quo is adequate: CS curricula should focus on teaching theory, algorithm design, problem decomposition, and engineering methodologies. After all, “CS != Programming,” right?

But a counterargument is that instructors should directly address how real-world programming—the most direct applications of CS—is often a messy and ad hoc endeavor; modern-day programming is more of a craft and empirical science rather than a collection of mathematically beautiful formalisms.

How might instructors accomplish
this goal? Perhaps via project-based
curricula, peer tutoring, pair program-
ming, one-on-one mentorship, or ped-
agogical code reviews. A starting point
is to think about how to teach more
general intellectual concepts in situ as
students encounter specific portions
of the six-step process described in
this post. For example, what can “code
welding” teach students about API de-
sign? What can refactoring teach stu-
dents about modularity and testing?
What can debugging teach students
about the scientific method?

Readers’ comments:

Over the last year, I’ve spent a fair number of cycles thinking about the disconnect between how people actually build code and how we teach programming in classrooms. This article hits on some of the same points I’ve thought about, especially with regard to the fact that programming today is increasingly about information foraging and composition of existing solutions. The process is defined by experimentation and iteration.

It’s also more of a social task, with online resources providing and peers providing increasing amounts of support. I’ve been thinking about these factors as I start my new job, slinging code for the Googs. As with many large companies there is a ton of existing code, and I have set up some pair programming sessions with folks on my team. These folks have a ton more experience with the tools that I will be using than I do. They can point me to resources I would have a hard time finding myself.

I wonder if coursework can mirror reality here. One idea that might work is the creation of a new course that paired undergrads across years, perhaps sophomores and seniors. The seniors should have more experience working on a project through coursework and internships.

One option is to provide open-ended
projects based on the skills the seniors
bring to the table. A senior of app
programming experience might be asked
to create a new Android or iPhone game,
whereas one that had been working on
building systems might be asked to create
a large-scale data processing app on top of
Hadoop. Another option might be to have
a two-stage course focused on a specific
project, separated between years. Current
sophomores would have to come back in
two years and share their knowledge.

Philip Guo is a visiting research scientist at edX. In the fall, he will join the massachusetts Institute of technology (mIt) computer Science and artificial Intelligence laboratory (cSaIl) as a postdoctoral scholar.