2011-11-27

Regarding Difficulty

As mammals with linguistic tools handy for the structuring of thought, we are by nature inclined to analyze and categorize and tokenize, so that we might apply labels to things and speak about those things in a rough group consensus of shared meaning/experience.

Modern culture owes a great deal to this tendency, as it allows us to accumulate knowledge across generations, in volumes far surpassing the capacity of an oral transmission medium.

It seems when we're learning, however, that the tendency may get in the way. Consider the case of the word "hard":
"I am learning this new thing, and it is hard."
People who dabble in creative activities, particularly temporal arts like music or dance, would find this statement familiar. Certainly as a software engineer the statement seems like an archetypal expression of experiences encountered every few months.

What does it actually mean? The word "hard" provides a rough label encompassing all sorts of situations.
  • "I am working with a distributed database that employs eventual consistency to allow for improved availability and scalability; it is difficult to adapt my thinking to an eventually consistent model."
  • "I am learning a new piece of music that freely mixes meter and does not use functional harmony; it is challenging to get the details right because they do not move in ways I can predict."
  • "I am trying to understand how collateralized debt obligations wreaked such havoc in our financial system, and I can't make heads or tails of it because everything I read is in such financial insider speak."
  • "I am learning a new piece of music that has a lot of melismatic passages and awkward phrasing; it's difficult to keep my tone consistent and to find spaces to breathe without disrupting the line."
  • "I trying to make some configuration changes in my distributed software system and it's challenging because there are so many performance-impacting details to consider."

Of the list above, I think only the last two are truly aligned with our original statement ("I am learning this new thing, and it is hard"). These last two are not about familiarity with the problem space; they are about actual details of the problems themselves. The others are better summarized:
"I am learning this new thing and it falls outside my realm of experience."

Or better yet:
"I am learning this new thing and it is not yet familiar to me."

If a thing is outside one's experience, then one cannot authoritatively say whether that thing is intrinsically "hard" or not. Here's an accurate statement about what is hard:
"I am learning and it is hard."

Isn't that more to the point? In learning, we program ourselves. We force ourselves think differently (in the literal sense, as opposed to the Apple marketing sense). We tackle problems that we previously avoided, ignored, or were entirely ignorant of. We experience the world from a broader place. In short, we change ourselves, and that is very hard work indeed.

Take something you tackled some time in the past. A piece of music, for instance. When you first looked at it, perhaps you thought it looked hard. Perhaps those notes just wouldn't come to your ear. Perhaps you just couldn't get those rhythms. Whatever.

After you transcended the challenges of the piece, did it still feel hard to do? Did you even stop and consider it? Or did you integrate the piece into your experience, so it stopped being about hard versus easy and simply became about doing it well every time?

I cannot think of an instance in my musician life or engineer life in which classifying an unlearned thing as "hard" was useful, except as a means of identifying things that would require more effort than usual. For any given learning challenge, there's a pile of stuff you don't know well, but there's a pile of stuff you do know. In most situations, the pile of stuff you do know is larger than the other. Is it fair, then, to classify an unlearned thing as "hard" if in fact you are intimately familiar with the bulk of its parts?

It's more helpful, in my opinion, to think and speak accurately about the problem:
  • "The technical challenges of this piece are difficult and require practice."
  • "There are a lot of variables in this system and finding the optimal configuration will require careful benchmarking and analysis."
  • "I am unfamiliar with the harmonic language of this piece and need to spend more time than usual getting the harmonies in my ear."
  • "I am unfamiliar with the problem space of distributed databases and need to read some of the seminal literature on the subject to better understand the implications of this system's design."
  • "I have trouble following the metric switches throughout this piece; I need to be better about counting and pay more attention to the word stresses."
That is, shed the vague notion of "hard", isolate the real problem(s), and identify concrete solutions to each. Then the notion of difficulty changes:
  • I have not achieved familiarity with the harmonic language of this piece yet.
  • I do not have the necessary background knowledge to work effectively with this system yet.
  • I am not able to consistently execute these melismatic passages yet.

But I will. That's what's fun about challenges.

No comments:

Post a Comment

Subscribe via email

Enter your email address:

Delivered by FeedBurner

Subscribe (RSS)