“I stopped by the bar at 3 A.M.
To seek solace in a bottle or possibly a friend
And I woke up with a headache like my head against a board
Twice as cloudy as I’d been the night before
And I went in seeking clarity” — Lyrics from The Indigo Girls: Closer to Fine

If you think programming is cognitively difficult, try parallel programming. It is generally harder to design, to code, and to debug than its sequential cousin. One of the fun projects I worked on at IBM Research was on the X10 language which was designed to enable parallel programmers to be more productive. Among other things, I fostered community among X10 programmers and used analytic techniques to show that X10 “should be” more productive. Although these analytic techniques are very useful, we also wanted to get some empirical data that the language was, in actuality, more productive. 

One part of those empirical studies involved comparing people doing a few parallel programming tasks in X10 to those using a popular competitor. But, like many other “chicken and egg” problems, there were no X10 programmers (other than the inventors and their colleagues). I was part of a team who travelled to Rice University in Houston. The design called for one group to spend a chunk of time learning X10 (perhaps half a day) and another chunk of time coding some problems.

Besides the three behavioral scientists like me who were there to make observations, there were also three high-powered Ph.D. computer scientists present who would teach the language. Programmers tend to be very smart. Parallel programmers tend to be very very smart. People who can invent better languages to do parallel programming? You do the math.

Anyway, after the volunteers students had arrived, one of the main designers of the language began to “teach them” X10. 

But — there was a problem. 

The powerpoint presentation designed to teach the students X10 was far too blurry to read!

Immediately, the three computer scientists tried to issue commands to the projector to put the images in focus. Nothing worked. The three of them began a fascinating problem solving conversation. The conversation concerned what communication protocol(s) among the PC, the projector, and the controller was the likely source of the problem. I suppose it might not have been fascinating to everyone, but it was to me. First, it fascinated me because I was learning something about computer science and communication protocols. Second, it fascinated me because I loved to watch these people think. I suppose many of the advanced computer science students who were in this classroom to learn X10 also found it interesting. Third, I found it fascinating because my dissertation was about human problem solving and I’ve been interested in it ever since.

But the study itself had completely stalled. 

After a few minutes of fascinating conversation that did nothing to focus the images, something possessed me to walk over to the projector and turn the lens by hand. The images were immediately clear and the rest of the experiment continued. 

The three computer scientists had “framed” the problem as a computer science problem and I found the discussion that sprang from that framing to be fascinating. But one of the part-time jobs I had had as an undergraduate was as a “projectionist” at Case-Western, and it was that experience that allowed me to try framing the problem differently. All of us have huge reservoirs of experience outside of our professional “training” and those experiences can sometimes be important sources of alternative ways to frame a problem, issue, or situation.

———————————-

Essays on America: Wednesday 

Essays on America: The Update Problem 

Essays on America: The Stopping Rule

The Invisibility Cloak of Habit

Labelism

Tools of Thought

Where Does Your Loyalty Lie?

Stoned Soup

The First Ring of Empathy

Travels with Sadie: Teamwork

Author Page on Amazon