The problem about art is not finding more freedom,
it's about finding obstacles.
-- Richard Rogers
I started teaching introductory programming back
in the fall of 1992. Within a year or so, I
found myself drawn to a style of teaching that
would eventually be called patterns. At the
time, I spoke of 'patterns' and 'templates',
and it took a while for me to realize that the
power of patterns lay more in understanding the
forces that shape a pattern as in the individual
patterns themselves. But even in their rawest,
most template-like form, simple patterns such
as Guarded Linear Search were of great
value to my students.
Back when I first starting talking about these
ideas with my colleagues, one of them almost
immediately expressed reservations. Teaching
patterns too early, he argued, would limit
students' freedom as they learned to write
programs, and these limitations would stunt
their development.
But my experience was exactly the opposite.
Students told me that they felt more empowered,
not less, but the pattern-directed style, and
their code improved. One of the biggest fears
students have is of the blank screen: They
receive a programming assignment. They sit down
in front of a computer, open a text editor, and
... then what? Most intro courses teach ways
to think about problems and design solution,
but they tend to be abstract guidelines. Even
when students are able to apply them, they
eventually reach the moment at which they have
to write a line of code ... and then what?
The space of all possible programs that students
can write overwhelms many novices. The most
immediate value in knowing some programming
patterns is that the patterns constrain the
space to something more reasonable. If the
problem deals with processing items in a collection,
then students need only recognize that the
problem is a search problem to focus in on a
few standard patterns for solving such problems.
And each pattern gave them concrete advice for
writing actual code to implement the pattern --
along with some things to think about as they
customized the code to their specific situation.
So, rather than limiting novice programmers,
patterns freed them. They could now proceed
with some confidence in the task of writing
code.
But I think that patterns do more than help
programmers become competent. I think that
they help already competent programmers become
creative.
You can't create unless you're willing to subordinate the creative impulse to the constriction of a form.Just as too much freedom can paralyze a novice with an overabundance of possibility, too much freedom can inhibit the competent programmer from creating a truly wonderful solution. Sticking with a form requires the programmer to think about resources and relationships in a way that unconstrained design spaces do not. This certainly seems to be the case in the arts, where writers, visual artists, and musicians use form as a vehicle for channeling their creative impulses. Because I am an academic computer scientist, writing is a big part of my job, too. I learned the value of subordinating my creative impulse to the constriction of a form when I began to write patterns in the ways advocated with the patterns community. I've written patterns in the Gang-of-Four style, the PoSA style, the Beck form, and a modified Portland Form. When I first tried my hand at writing some patterns of knowledge-based systems, I *felt* constricted. But as I became familiar with the format I was using, I began to ask myself how best to express some idea that didn't fit obviously into the form. Often, I found that the reason my idea didn't fit into the form very well is that I didn't have a clear understanding of the idea itself! Holes in my written patterns usually indicated holes in my thinking about the software pattern. The pattern form guided me on the path to a better understanding of content that I thought I already knew well. Constraining ourselves to a form is but one instance of a more general heuristic for creating. Sometimes, the annoying little problems we encounter when doing a task can play a similar role. I love this quote from Phillip Windley, reporting some of the lessons that 37signals learned building Basecamp:
-- Anthony Burgess
Look at the problems and come up with creative solutions. Don't sweep them under the rug. Constraints are where creative solutions happen.Constraints are where creative solutions happen. -----