why programming is hard
Dave Long
dave.long at bluewin.ch
Fri Oct 27 09:19:30 EDT 2006
> For some systematic psychological research on the cognitive
> difficulties of programming, see "Six Learning Barriers in End-User
> Programming Systems", by Andrew J. Ko et al.:
> http://www.cs.cmu.edu/~ajko/papers/Ko2004LearningBarriers.pdf
The factory metaphor alone explains why programming is hard. Running
with it a bit (although far in excess of my actual knowledge of factory
floors):
The machine operator is a little like the middle-manager. Given a
working station, he can keep it humming in production. This is a step
up from the unskilled entry-level.
The setup man can take machines and tooling and put them together so
the operators can take over. Given a station that's off in the weeds,
he can figure out how to get it back in production.
The tool and die maker makes the tools the setup men need. Given the
specifications for a part, he can develop a system that the setup men
can use to produce it.
Moving up a level takes you to the guys who are responsible for taking
the abstract idea of a production line for a complete assembly and
realizing a concrete instantiation; finding people who can do this well
is difficult enough that these guys, especially the ones who can
troubleshoot quickly, seem to be well compensated.
As the paper points out, programming is yet more dynamic, with
factory-creating factories. If we believe the factory is a good
metaphor, perhaps the question should be "why is programming easy for
those who pick it up implicitly?" rather than the other way around.
> ... programming is not well-explained, and ... a bunch of dudes in
> their prime of life laid down a whole lot of pseudo-zen language
> about it to intimidate their would-be successors.
This point is also covered in the Learning Barriers paper. They note
that the brick walls that beginners hit are technical problems
involving reading documentation and mastering basic skills: which
elements do I need to make the computer do something, how do I employ
them correctly, and how do I coordinate them?[0] Programmers who are
no longer green, on the other hand, tackle those issues by rote, and
hence get hung up on the broader, much less well-posed problems of
design and debugging: what should my program do, and how do I find out
what it's actually doing?[1]
Scott McCloud's _Understanding Comics_ points out the same progression
for comic books: when kids start out, they nearly universally want to
know how to draw characters that have a certain look. After they have
enough seasoning, then they move on to the more abstract problems, and
want to know how to tell a story in a way that will cater to the
strengths and avoid the weaknesses of a their medium. (do they also
often discover that the story they told is not quite the one they
wished they could tell?)
The pseudo-zen language is probably meant for successors, not for
beginners who may eventually become successors -- Perlis' epigrams are
aimed at people reflecting upon their programming style: more like
etudes or bouldering problems, not at people who have trouble
populating a list box: less like scales or fingertip pull-ups.
-Dave
:: :: ::
[0] in the old days, foreign languages may have provided some examples
of learning these types of skills[2]. The beginner wants to know which
words do I use, how do I conjugate/decline them properly, and how do I
build them up into phrases and sentences. The habitual speaker will be
more concerned with broader matters: what do I want to say, and did
what I just said really communicate what I had meant?
With both natural language and with programming, the ability to rapidly
try several different circumlocutions when the first attempt fails (or
to confim that the first attempt did indeed succeed!) is a skill worth
cultivating.
[1] When one has no better tools, binary chops are just as good a
hammer for debugging as for searching. Unfortunately, analyzing blobs
into their parts seems, in general, to be a practice that's picked up
more by osmosis than by being taught, as it usually involves more
difficult problems (more arbitrary choices?) than putting together
distinct parts to form a coherent blob.
[2] The french equivalent for "it's all greek to me" is "I've forgotten
my latin" (what's the greek equivalent?). The phrase works better in
english, because greek looks much more like gobbeldygook to the casual
observer -- but there is meaning behind those squiggles, and even
schoolchildren have been known to be able to find it. (Koerner notes
that mathematicians love raiding alphabets for squiggles, saying that
it is an unfortunate practice as one tends to mentally pronounce any
unfamiliar glyph as "splodge")
More information about the Kragen-discuss
mailing list