You've got to learn your instrument.
Then, you practice, practice, practice.
And then, when you finally get up there on the bandstand,
forget all that and just wail.
-- Charlie Parker
Getting good at design means cultivating your taste. Right now, you don't have it. Eventually you will, but until then you cannot trust your creativity. Instead, focus on simplicity, clarity, and the cold, hard science of what works.
This is hard advice for people to follow. We like to
use our brains, to create, to try out what we know. I
see this desire in many beginning programming students.
The danger grows as our skills grow. One of my greatest
frustrations comes in my Programming Languages course.
Many students in the course are reluctant to use
straightforward design patterns such as
mutual recursion.
At one level, I understand their mindset. They have
started to become accomplished programmers in other
languages, and they want to think, design, and program
for themselves. Oftentimes, their ill-formed approaches
work okay in the small, even if the code makes the prof
cringe. As our programs grow, though, the disorder
snowballs. Pretty soon, the code is out of the
student's control. The prof's, too.
A good example of this phenomenon, in both its positive
and negative forms, happened toward the end of
last semester's course.
A series of homework assignments had the students growing
an interpreter for a small, Scheme-like language. It
eventually became the largest functional program they had
ever written. In the end. there was a big difference
between code written by students who relied on "the cold,
hard science" we covered in class and code written by
students who had wondered off into the wilderness of their
own creativity. Filled with common patterns, the former
was relatively easy to read, search, and grade. The
latter... not so much. Even some very strong students
began to struggle with their own code. They had relied
too much on their own approaches for decomposing the
problem and organizing their programs, but those ideas
weren't scaling well.
I think what happens is that, over time, small errors,
missteps, and complexities accumulate. It's almost like
the effect of rounding error when working with floating
point numbers. I vividly remember experiencing that in
mu undergrad Numerical Analysis courses. Sadly, few of
our CS students these days take Numerical Analysis, so
their understanding of the danger is mostly theoretical.
Perhaps the most interesting embodiment of trusting one's
own creativity too much occurred on the final assignment
of the term. After several weeks and several assignments,
we had a decent sized program. Before assigning the
last set of requirements, I gave everyone in the class a
working solution that I had written, for reference. One
student was having so much trouble getting his own program
to work correctly, even with reference to my code, that he
decided to use my code as the basis for his assignment.
Imagine my surprise when I saw his submission. He used
my code, but he did not follow the example. The code he
added to handle the new requirements didn't look anything
like mine, or like what we had studied in class. It
repeated many of the choices that had gotten him into hot
water over the course of the earlier assignments. I could
not help but chuckle. At least he is persistent.
It can be hard to trust new ideas, especially when we don't
understand them fully yet. I know that. I do the same
thing sometimes. We feel constrained by someone else's
programming patterns and want to find our own way. But
those patterns aren't just constraints; they are also
a source of freedom.
I try to let my students grow in freedom as they progress
through the curriculum, but sometimes we encounter something
new like functional programming and have to step back into
the role of uncultivated programmer and grow again.
There is great value in learning the rules first and letting
our tastes and design skill evolve slowly. Seniors taking
project courses
are ready, so we turn them loose to apply their own taste
and creativity on Big Problems. Freshmen usually are not
yet able to trust their own creativity. They need to take
it slow.
To "think outside the box", you you have to
start with a box.
That is true of taste and creativity as much as it is of
knowledge and skill.
-----