if we’re living now and always have been in the Age of Blurgs, then our strategy might change accordingly. before i go to some ideas from the modern synthesis that are targeted at blurgs & blurging, tho, i want to point at one thing that won’t work, and why.
what won’t work is “try harder”, and why it won’t work is “because humans”.
what i mean about just trying harder not to blurg being ineffective as a plan: blurging is not a failure of will or discipline. that is, blurgs don’t come from geeks goofing off or being lax or time-serving or any of those sorts of things. instead of “try harder”, the point of this set of muses is “try different”. we’ll get to some different in coming days, but for now consider it foreshadowed, and let’s take a look at why “to blurg is human”.
there are three reasons we create blurgs that are not ever going away, because they are embedded in the human and in the human processes surrounding coding. they are “bandwidth”, “distraction”, and “semantic expectation”.
bandwidth: we’ve been over and over this, but it’s worth a few sentences more for the noob. the bandwidth of the human mind – the number of independent concepts a person can hold active at one time – is extremely limited. in miller’s famous paper about the magic number 7+-2, we first met this concept, back in the middle ‘50s. since then we’ve run thousands of experiments, and the consensus today is that a human’s mental bandwidth varies between 4 and 7 items.
wait. what? four and seven? that, my friends, is a brutal limit, and it appears to be a biological one.
human minds do crazy mad tricks to work within these limits, notably naming & chunking on the one hand, and narrative on the other. (when we get to “try different’ we’ll be taking advantage of these.)
but the hard limit? 4-7. although we routinely operate in conceptual systems with thousands of concepts, moment to moment, we are constantly using tricks to fit small subsystems into our mental scope.
i know this isn’t obvious. not to me, not to most folks. but it is one of the most documented results from all of cognitive science.
distraction: this one has both an obvious and a subtle component. distraction is really almost anything that has us looking away from a coding task.
the obvious component is simply the realities of human collaboration in any enterprise. working days are chock-a-block with distractions. everything from meetings to bathroom breaks. i’ve never met a geek who didn’t think they needed more time by themselves to rock code. but any working office is constantly breaking that time up. sometimes the distraction is useful to the distractor, if not the distractee, and sadly, very often, it’s useful to neither. staff meetings, anyone?
the more subtle distraction is just inside our little brains. the human mind is rarely still. (if it were, meditation would not be so valuable and difficult.) it, not to put too fine a point on it, never shuts up. it is constantly working to maintain your body, scratch itches, suppress or release emotion, predict the day ahead, analyze the day behind, and so on. because obvious distraction is so obvious, we tend to underplay self-distraction. but if you’ve ever had a quiet coding day where you couldn’t get anything done anyway, you’ll have felt the burn of subtle distraction.
semantic expectation: this is basically seeing what you expect to see regardless of what is actually there. like the others, this a hard biological fact, not a failure of will. one of the tricks humans use to parse systems that are larger than 4-7 ideas is narrative. we build a narrative of the recent past, and we use that narrative to parse the near-term future. it is a brilliant trick, and fundamental to human cognition.
essentially, we use our narrative to create meaning, and we use that meaning to interpret what our senses tell us. that interpretation simultaneously enables us to think at all, and forces the sensory data to fit our thinking.
semantic expectation is the act of letting the meaning-we’ve-made create expectations that subvert the meaning-that’s-there. there are a million million jokes, riddles, and tricks that turn on semantic expectation. but it’s not a joke, it’s real.
we have professional proofreaders instead of ourselves because they’re better at being blind to our own semantic expectation.
anyway working near our justice system knows how wildly untrustworthy eyewitnesses are: because they have semantic expectation, they see what they expect to see.
if you’ve ever found a huge flaw during a technical review, you will know what i’m talking about. how could i not have seen this stupid thing? easy: the semantic expectation kept me from seeing it. it’s an absolutely everyday experience for most geeks.
so where are we at?
we live in the age of blurgs, of simple disconnects between what the coder thinks the code says and what the computer thinks the code says.
we can say, “i will not blurg today”, but it’s to no avail. we will blurg today, and every day, for reasons having nothing to do with how hard we try not to: bandwidth, distraction, and semantic expectation, among others. we need strategies that are stronger than “try harder”. and in the next little stretch, we’ll look at some “try different” options, both explicit and implicit in the modern synthesis.