On symbology and materialism

In a great article, Scott Bellware talks about the detrimental nature of a fixation of symbology on teaching.  This is especially true in software development, where the justification, shape and application of tools are not quite as clear as other craftsman-like jobs.  You may be able to teach an apprentice carpenter what a screwdriver is or rotary saw, but those names are quite descriptive of the function, whereas software terms like “Inversion of Control” and the like require quite a bit more introduction.

Symbology, however, is of utmost importance amongst peers.  It’s the only way to communicate.  If one carpenter called a screwdriver a “twistinator” and another called it a “binditanoid”, how could they hold higher-level conversations on the application and strategies for using a screwdriver?

Fields of work gravitate towards a common language simply because it’s easier to share and disseminate ideas.  Relatively young fields are hampered by a lack of common language, as I saw in a recent foray into software volume licensing.  Because every single vendor had a different name for a single concept, we as developers had to keep track of a bevy of translations, between ourselves and talking about each vendor’s programs.

Few things are more destructive towards communication than translations and context switching.  When definitions and names are shared amongst peers, they can move past definitions to what to do with the concepts behind the names.

Teachers must be wary of swamping a student with acronyms and definitions, but it’s a failure of teaching, not of the symbology.  Symbology is a measure of the maturity of a field, so let’s not abandon the names in favor of teaching the concepts.