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.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Misc. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://home.infusionblogs.com/kszklenski/default.aspx Kyle Szklenski

    And yet, a rose by any other name would still smell as sweet. . .unless we called it a stench blossom.

    In any case, while I largely agree with your point (names are important, and uniformity of the application of names to concepts is even more important), I disagree that we should not favor the teaching of concepts over names. Or, rather, I’m not sure why you claim we should, “Not abandon the names in favor of teaching the concepts.” I’m of the opinion that first and foremost, a person should know the concept, and then if it has or needs a name, they can apply the name to it. It’s a bit of a chicken and an egg problem. The reason I think that the concepts are more important than the names, and therefore we should not forget the names but rather teach the concepts first, is that even if a concept does not have a specific name, we can talk to people about it and they understand what we’re talking about – that’s kinda the definition of concept.

    Did I miss something more fundamental about your post? It seems like I may have confused something, but it’s not at all obvious to me.

  • http://home.infusionblogs.com/kszklenski/default.aspx Kyle Szklenski

    Okay, I went back and reread both articles (your’s and Scott’s), and I think you’re directly contradicting him. Symbology, in Scott’s sense, seems to refer to the naming of an item. He says, “In these moments, the mainstream learner often dismisses many brilliantly-simple and game-changing ideas because they’re wrapped up in intimidating symbology, like ‘Liskov Substitution Principle’, ‘Cyclomatic Complexity’, or ‘Inversion of Control’.” He is basically directly saying that the name of the concept is important, but less so much than the concept itself, and so we should choose simpler, more descriptive names to convey the same concepts that we have.

    I’m finding that I agree with Scott on this the more I read his article. I agree with you that we need to stop swamping people with acronyms, definitions, and obtuse names of concepts, but I’m still confused about your last line: Are you disagreeing with Scott, agreeing with Scott with a “but”, or completely agreeing with Scott, with your post?

  • http://www.lostechies.com/members/bogardj/default.aspx bogardj

    I’m agreeing, with a “but”. Symbols or names are not important when teaching and get in the way.

    But am I supposed to stop using names because it’s harder to teach? No, because names create a shared language, making possible to communicate between peers. I tried to create a sharp difference between communicating between teacher/learner and practitioner/practitioner.

  • http://home.infusionblogs.com/kszklenski/default.aspx Kyle Szklenski

    Well, I think you actually did. It had just confused me for a moment, because I thought you were completely agreeing with Scott (just assumed, I guess). Good post anyway.

  • http://scottbellware.com Scott Bellware

    Jimmy,

    In fact, you’re agreeing with me unconditionally. There’s no differentiation in your qualification of my point and my point itself. You’ve expanded the scope beyond the intended scope of my article, and the territory you’ve expanded into is in perfect agreement with my position.

    Kyle,

    Yes, we should pursue simpler names where possible, and it’s almost always possible.

  • http://www.lostechies.com/members/bogardj/default.aspx bogardj

    @Scott

    Ah, thanks for the clarification.

  • Matt Hinze

    In related news, it’s easier to teach with examples, and easier to learn by doing.

    What I think you are saying is this: “From one intellectual materialist to another, there’s a lot to be said for pure teaching skills. In other words, don’t discount the ability of a good teacher to convey a difficult concept regardless of symbology.”

    A good teacher has internalized what you (and Scott) are talking about.