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