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