Posts Tagged ‘Language’
Read, listen, or comprehend: choose two
I have noticed that when I am reading, I cannot simultaneously understand spoken words. If someone speaks to me while I am reading, I can pay attention to their voice, or to the text, but not both. It’s as if these two functions share the same cognitive facility, and this facility can only handle one task at a time. If someone is talking on the phone nearby, I find it very difficult to focus on reading (or writing). If I’m having a conversation with someone about a document, I sometimes have to ask them to pause the conversation for a moment while I read.
This phenomenon isn’t unique to me. In Richard Feynman’s What Do You Care what Other People Think?, there is a chapter entitled “It’s as Simple as One, Two, Three…” where he describes his experiments with keeping time in his head. He practiced counting at a steady rate while simultaneously performing various actions, such as running up and down the stairs, reading, writing, even counting objects. He discovered that he “could do anything while counting to [himself]—except talk out loud”.
What’s interesting is that the pattern varies from person to person. Feynman shared his discovery with a group of people, one of whom (John Tukey) had a curiously different experience: while counting steadily, he could easily speak aloud, but could not read. Through experimenting and comparing their experiences, it seemed to them that they were using different cognitive processes to accomplish the task of counting time. Feynman was “hearing” the numbers in his head, while Tukey was “seeing” the numbers go by.
Analogously, I’ve met people who seem to be able to read and listen to speech at the same time. I attributed this to a similar cognitive effect: presumably some people “speak” the words to themselves, while others “watch” them. Feynman found that, although he could write and count at the same time, his counting would be interrupted when he had to stop and search for the right word. Perhaps he used a different mental faculty for that. Some people seem to be able to listen to more than one person talking at the same time, and I wonder if that’s related.
I was reminded of this years later, when I came across this video on speed reading. In it, the speaker explains that most people read by silently voicing words, which they can do at a rate of only 120-250 words per minute. However, people can learn to read visually instead, and thereby read much more quickly. He describes a training technique which involves reading while continuously voicing arbitrary sounds, like the vowels A-E-I-O-U.
The interesting part, for me, was the possibility of learning. I realized that different people read in different ways, but hadn’t thought much about whether one could change this. Having learned a cognitive skill, like reading or counting time, apparently one can re-learn it a different way. Visual reading would seem, at first glance, to be superior: not only is it faster, but I have to use my eyes to read anyway, so why tie up my listening facility as well? Perhaps I could use it for something else at the same time.
So, I tried the simple technique in the video, and it had a definite effect. I could “feel” that I wasn’t reading in the same way that I had been before. I didn’t measure whether I was going any faster or slower, because I quickly noticed something more significant: my reading comprehension was completely shot. I couldn’t remember what I had read, as the memory of it faded within seconds. Before reaching the end of a paragraph, I would forget the beginning. It was as if my ability to comprehend the meaning of the text was linked to my reading technique. I found this very unsettling, and it ruined my enjoyment of the book I was reading.
I’ll probably need to separate this practice from my pleasure reading in order to stick with it. Presumably, over time, my comprehension will improve. I’m curious about what net effect this will have, though. Will I still comprehend it in “the same” way? Will it mean the same thing to me? Will I still feel the same way about it? The many levels of meaning are connected to our senses as well, and “the same” idea, depending on whether it was read or heard, may not have “the same” meaning to an individual. Even our tactile senses can influence our judgments and decisions.
I also wonder whether, if I learn to read visually, I’ll lose the ability to read any other way. When I retrained myself to type using a Dvorak keyboard layout, rather than QWERTY, I lost the ability to type on QWERTY at high speed. I think this has been a good tradeoff for me, but raises interesting questions about how my mind works: Why did this happen? What else changed in the process that might have been less obvious?
Have you tried re-training yourself in this way? What kind of cognitive side effects did you notice, if any? If you lost something, do you still miss it?
(As a sidenote, I am impressed by Feynman’s exuberance and persistence in his personal experiments, as described in his books for laypeople. Although I consider myself a very curious person, I rarely invest that kind of physical and intellectual energy in first-hand experiments. I’m much more likely to research what other people have done, and skim the surface of the subject.)
Amplify Your Effectiveness (AYE) Conference: Day 2
Morning Session: How Do I Communicate With You? (Don Gray)
This session explored interpersonal communication, in particular how to identify communication styles and preferences and apply this knowledge to communicate more effectively.
In one of the exercises, we broke into pairs and exchanged stories from recent memory. While one person told their story, the other observed their language, noting the types of predicates used (visual, auditory, kinesthetic, olfactory/gustatory and “unspecified”) as indicators of the speaker’s representational system. We used this data as the basis for a discussion about cues which indicate a person’s preferences, ranging from word choice to eye movement.
Another exercise divided the group into two based on personality type (Myers-Briggs “N” and “S”). Both groups were given identical objects (Starbucks paper coffee cups) and asked to write down descriptive phrases. The “N” group’s descriptions were wide-ranging, exploring the possible uses of the cup, the memories and meanings it evoked in them. The “S” group focused more on the physical properties of the cup, and where there were some comments on the ideas associated with it, these were carefully separated on a separate list.
A third exercise had us folding a piece of paper according to instructions read aloud. The instructions were ambiguous, and would be interpreted differently depending on how the person happened to be holding the paper, how they turned it as they folded it, or how they interpreted the sentences. Unsurprisingly, everyone ended up with a different pattern.
There was then some free-flowing discussion about communication styles where people in the group shared experiences of communication challenges. I learned more from these scenarios than from the exercises, which were covering familiar ground. The challenge, for me, is applying what I know about communication theory, by raising my awareness of patterns in real life situations. Practicing this through discussing examples was more helpful to me than exploring more theory.
Finally, the group was presented with a choice of whether to explore a canned scenario (a new executive looking for feedback from others in the organization) or a real-world scenario put forward by someone in the group. The latter option prevailed, but the scenario was a price negotiation with few details, which I didn’t think would be valuable for me. I excused myself and left early, purchasing a copy of Tom DeMarco’s Slack from the book table.
Afternoon session: Beyond the Org Chart Illusions (Jerry Weinberg)
This session alone would have made this conference worthwhile. In it, we explored the structure and dynamics of organizations from a first person point of view. The idea was to discover the tacit structures which make up organizational culture. Setting aside the “objective” description provided by an organizational chart or other such tool, we instead created individual representations of the organization as we experienced it.
To do this, we used an exercise based on Virginia Satir’s technique of family mapping. We each selected an organization we were familiar with, and drew a picture with symbols: first ourselves, then other people (both with no names or words), then physical objects and structures, and labels. We then overlaid the points of pain, pleasure, problems, plans, performance (high and low) and power in the organization.
Unsurprisingly, the diagrams were all vastly different in symbolism, structure, order, level and technique. Jerry focused the group on a pair of diagrams created by two different people in the same organization. The creators explained the meanings of the symbols they used, illustrating the problems faced by the organization. This spawned a discussion about how to address those problems, which occupied the rest of our time.
This discussion really got me thinking, and drawing parallels with my own experience. In particular, i identified with some of the fears and other roadblocks which prevented the people from taking action. One memorable point from Jerry was that you will never convince someone with logic to change something they did not arrive at through logic. I make that mistake a lot.
I also gained some insight on how companies can be successful despite poor management, at least for a time. For example, circumstances may favor the company, such as having little or no competition. Advantages like that don’t last, though, and when things change, the management gap can cripple the company.
I can’t describe here much of what I learned in this session, but I found it extremely valuable.
Bohrbugs: OpenOffice.org won’t print on Tuesdays
This is one of my favorite bugs of all time: Ubuntu bug #248619, where OpenOffice.org won’t print to Brother printers on Tuesdays (but works on other days of the week).
Read some of the duplicate reports to follow the analysis and developer/user cooperation which isolated the bug.
It’s a great example of a Bohrbug, where the circumstances which trigger the problem can be very difficult to isolate. It’s likely that many such bugs exist in Ubuntu and other software today, but have not yet been isolated, as bug 248619 has been.
We’ve all observed a complex software stack misbehaving in ways we would never expect. It’s just as confusing when things suddenly start working again, for no apparent reason. We start to doubt our senses, or the person who is reporting their observations.
In The Psychology of Computer Programming (chapter 5), Jerry Weinberg presents a case where two identical systems, physically isolated from each other but running the same software, exhibited precisely the same error at the same time. This obviously pointed to a software bug, but after two weeks of searching, the problem could not be replicated and the root cause was not found. The team gave up on finding it, and the system went into production, only to have the bug recur and cause a serious operational outage.
Bugs which occur very rarely may not always be worth investigating, but they are real, and can be explained. When it really matters, we should remember not to disregard them.
On apologies
Apologies are something I still have trouble with from time to time. I’m going to be prescriptive in this article, though, because I think I’ve learned a thing or two about the right and wrong ways to do it, thanks to some of the people I’ve hurt who have cared enough to tell me how they felt.
I was taught from a young age that the words “I’m sorry” were the cure for hurt feelings, whether they resulted from harsh words, physical pain or thoughtlessness. While I learned the ritual of it from this training, I had to learn separately what it really meant, and develop the emotional aptitude to put it into practice.
I wonder whether this ritualization of apology makes it more difficult for us to learn to do it properly. We seem to confuse the language of apology with the feeling of regret, or the act of reconciliation. Apologies are only words, unless they successfully convey regret for our actions, and a desire to do better in the future.
For example, consider the phenomenon of the non-apology apology. This happens when someone feels the need to fulfill the ritual of apology with words, but doesn’t seem to regret their actions or wish to truly reconcile. They may recognize that the other party is hurt, but not accept responsibility for it. They may conditionalize the apology so as to avoid even acknowledging the hurt. They may even blame the injured party for their own hurt, while still participating in the ritual and satisfying their trained impulses.
“I’m sorry if…”
This type of non-apology fails to acknowledge the consequences of our actions. Maybe we hurt someone, or maybe we didn’t. Who is to say? In the hypothetical scenario wherein we hurt someone, we suppose we would be sorry. Who’s to say? When it’s clear that someone has been hurt, and that our actions caused them to be hurt, a conditional apology is tantamount to a denial.
- I’m sorry if I hurt your feelings
- I’m sorry if I crossed a line
- I’m sorry if I was an asshat
“I’m sorry, but…”
These “apologies” are really excuses in disguise. They justify our actions, and thereby absolve us of responsibility. They fail to recognize that, regardless of what our intentions were, we hurt someone. It’s sometimes appropriate to offer an explanation, but that’s a separate matter from the apology, and the two don’t mix. Attaching an explanation to an apology dilutes the apology to the point of meaninglessness.
- I’m sorry, but I didn’t mean it (that way)
- I’m sorry, but I was only joking
- I’m sorry, but I’m just speaking my mind
- I’m sorry, but you must have misunderstood me
- I’m sorry, but I don’t know what I did wrong
“I’m sorry [that] you…”
These insidious non-apologies deflect responsibility away from ourselves and onto the injured party. They imply that they hurt themselves, and that our actions were incidental. They often focus on the symptoms of distress, rather than the cause.
- I’m sorry you feel that way
- I’m sorry you are upset
- I’m sorry you were offended
A proper apology
- Validates the hurt
- Takes responsibility for having caused it, regardless of intent
- Expresses regret for one’s actions
It will also convey a desire to avoid repeating the same mistake in the future. I think this is usually implicit, though, and doesn’t need to be stated unless it requires clarification. If you do something wrong and clearly regret it, it will be inferred that you’ll avoid doing it in the future.
Apologies are easiest when the mistake is a simple one: a trodden foot, a late appearance, a forgotten courtesy. The injury and the cause are both obvious in these cases. We usually get into trouble where there is a more complex emotional conflict involved. In such situations, we’re not always sure what happened or why, and may need to explore that before we can even begin to apologize. This may require cooperation with the injured party, which can be especially difficult in a conflict situation.
Nevertheless, even in an emotional conflict, it can help to draw parallels with a simple apology. It’s been years since I last made an HTML table, but here goes:
| If you stepped on a foot | If you hurt someone with words | ||
|---|---|---|---|
| Don’t say… | Do say… | Don’t say… | Do say… |
| I’m sorry, but I was just trying to pass |
I’m sorry for stepping on your foot |
I’m sorry, but I was just joking |
I’m sorry for telling that joke |
| I’m sorry if I stepped on your foot |
I’m sorry I stepped on your foot |
I’m sorry if I hurt your feelings |
I’m sorry I hurt your feelings |
| I’m sorry you were hurt by my foot |
I’m sorry I stepped on your foot |
I’m sorry you were offended by what I said |
I’m sorry I spoke to you that way |
Of course, this is still “just” language, and needs to be supported by authenticity of expression (i.e. you need to believe it for the magic words to work). An apology may be only the last step of a long process of understanding and reconciliation.
Still, watching our words helps us to notice when we’ve got it wrong, which may be half the battle.
Have you tried the “white boy” test?
From time to time, someone in the Ubuntu community writes about the experience of introducing a “normal person” (someone who has no specific expertise with computers) to Ubuntu. These accounts provide useful feedback to Ubuntu designers and developers working to make Ubuntu easier to understand and use. They are no substitute for rigorous usability studies, but are nonetheless worthwhile. By explaining where the subject got stuck, they help to identify the most obvious usability problems. By celebrating the user’s successes, they help to build a sense of accomplishment and momentum around usability. They usually go something like this:
My grandmother is 104 years old and has never used a mobile phone before, much less a computer. One lazy Sunday afternoon, I introduced her to Ubuntu. I helped her into the den, showed her the mouse and keyboard, inserted the installation CD…
They go on to describe the subject’s attempts to use Ubuntu for common tasks, without any prior experience of the system. I will boldly hypothesize, based on my own reading and without gathering any data, that the subjects are predominantly female. Perhaps the earliest examples of this were our references to Jeff Waugh‘s mother, in early Ubuntu thought experiments, as an example of an uninitiated Ubuntu user.
Thus, we generalize: Ubuntu is so easy, even your grandmother can use it, or it passes the Mother test, or the girlfriend experiment shows just how far we have to go.
These generalizations idealize women as uninformed, technological novices or intellectual inferiors, which is particularly striking to some of us who learned computing from our mothers. This is not to say that statements like these are the origin of gender stereotypes, but they do display and reinforce these (often unconscious) beliefs.
In analyzing statements about gender roles, it is sometimes helpful to substitute for gender some other trait, such as skin color or race. This helps to illustrate bias, because many of us are more sensitized to racial stereotypes: is Ubuntu so easy that a white boy could use it? Does it pass the white boy test? If my white boyfriend can figure it out, you can too! This can be a useful way to “test” language and reveal implications.
We should think twice when we read, and make the effort to investigate our own speech as well. Unfortunately, our first impulse is often to deny the possibility of bias, and treat the situation like an argument we want to win. Instead, we should try to recognize these moments as opportunities to improve our awareness, and listen for new information in the reactions of others.
It would be a huge step forward for us as a community to do better at this. We will know that Ubuntu has truly arrived, though, when becomes more popular among white people than Apple.
“I don’t have enough time”
It’s a phrase I hear every day: “I don’t have enough time to do that.”
Recently, I’ve been thinking a lot about the trivial things we say, particularly when a poor choice of words can obscure our meaning. Conventional wisdom supports “calling it like it is,” but taking an objective view is rarely as easy as that. Our use of language is inescapably tied to our personal experience of the world, and therefore pure objectivity in speech is virtually absurd. Perhaps instead we should “call it by its true name,” which is sufficiently mystical and subjective to get to the heart of the matter.
What do we mean when we say that we don’t have time? If a task would require two hours, but is due in an hour, then we don’t have time to do it. Who could argue with that? However, more frequently, we mean “I can’t do that in addition to everything else I’m doing.” If I have a full week’s work to do, and something new comes in which would require a whole day to complete, I might say that I “can’t” do it this week because “I don’t have the time.” I clearly have enough time, though, because a day is less than a week. If the task were important enough, I would do it instead of something else.
This brings us a step closer to what we really mean, which is “that is less important than my other obligations.” What a difference it makes to consider the situation in this way! I have shifted from a position of powerlessness (“I can’t”) to one of decisiveness (“I choose not to”). Nothing about my circumstances has changed, but I’m now communicating a different view of the world, one in which I’m taking responsibility for my choice. This also opens the way for discussing what your priorities are, and making adjustments if circumstances have changed.
In other news, I’m told that London youth have taken to saying “I have a lot of time for that” to mean that they like something.
Portland Businesses Recycles?
Apparently, they are also makings spellings errors.
The gift of constructive criticism
Giving and receiving feedback is a key part of working in a team, whether as a professional colleague, a volunteer contributor or a friend. It gives us the opportunity to see ourselves as others see us, to identify our blind spots, and become better at what we do.
However, it doesn’t always go as planned. Even otherwise accurate criticism, when delivered without appropriate care, can have the opposite effect. It makes us feel defensive and undervalued, and gives us no incentive to change our behavior. It can distract us away from our own problems, and lead us to focus on the person giving us feedback instead.
Here are some practical techniques which I have found to make a positive difference in giving and receiving criticism:
- Ask questions: Don’t assume that you already know what the problem is. Often, you don’t.
- Provide context: It’s easy to focus too much on the problem at hand, and neglect to put it in perspective. If you only ever hear from me when something is wrong, you probably won’t receive my feedback with openness and acceptance. Therefore, try to present criticism in the context of the bigger picture. Take the opportunity to share your overall view of the situation, particularly where it’s good, before analyzing what’s wrong with it. Many promote the simple idea of a “sandwich” which surrounds criticism on both sides with positive messages, though I think it’s more important to provide relevant perspective than to simply balance positive and negative commentary. Contrast “This function is buggy and should be rewritten” with “My understanding of this module is that it should work this way, and for the most part, it seems to, but this function doesn’t work the way I expect, and it seems like a bug to me.”
- Explain why: If you feel that a change is needed, provide rationale for it. You may have already worked out for yourself what is wrong and how to fix it, but if I haven’t been a part of that process, I won’t understand why it seems important to you that I change what I’m doing. Therefore, take a moment to explain the benefits of your proposed change from my point of view. “I suggest doing it this way, because…”
- Suggest how: It may not be obvious to me how to implement the change you’ve proposed, and this can give the impression that you’re oversimplifying the situation, or don’t understand what you’re asking me to do. Note that it’s usually appropriate to ask first whether I want this type of help, as unsolicited advice may be unwelcome. Contrast “You never answer my emails” with “Are you having trouble keeping up with the volume of email you receive? I have a similar problem, and what worked for me was…”
- Show support: Position yourself firmly on the same side, not in opposition. The problem is the enemy, and you should aim to work cooperatively with your colleague to address it. Make sure they know that they’re not on their own, that you’re available to follow through and work with them to improve the situation. Again, make sure you have their permission to help. Contrast “You really need to fix this” with “If you want, we can try this together next time, and see if the new approach works better.”
We'll see | Matt Zimmerman 