Working with another person can change your perception of time.
Last issue James Duncan Davidson described his and Mike Clark’s project for helping photographers work at their craft every day, The Daily Shoot. Here’s a recent Daily Shoot assignment, delivered via Twitter: “2010/01/21: Quirky things often catch your eye and make for interesting art. Make a photo of something that makes you go ‘Hmmm’ today.” Several things about the project really appeal to me.
I like how it makes perfect use of Twitter. Then there is the idea of artists supporting one another, and the way it helps photographers to improve daily. But it’s not just photographers who need to work at their craft regularly. That’s an important strategy for writers and programmers, too.
The Littlest Workshop
Duncan’s article recalled to me a discipline that a friend and I set up years ago, a paired-writing program that really improved me as a writer.
Back in my grad school days at Indiana University, no matter what graduate degree program I was in (there were a couple of them), I considered myself primarily a writer. In the summers, I signed up for IU’s excellent writer’s workshops, where I got my work critiqued by writers like Ursula K. Le Guin and Clancy Sigal and Roger Zelazny, and was immersed for a week in intense daily writing assignments.
I’ve written about workshopping here before. Dick Gabriel’s book on the subject is worth a read (but is, sadly, out of print; a PDF version can be found here).
But here’s the problem with workshops: when the workshop is over, it’s nearly impossible to keep up the energy. You lose the intense concentration, the camaraderie, the external support for self-discipline. I missed all that when the workshops ended, and pondered how to keep the energy up.
One year, I actually did just that. With a friend I’d met in one of the workshops, I set up a program of weekly assignments that went on continuously for about a year. (I’d finished school by then and was repairing computers and writing code in one of the country’s first computer stores.)
Each week we met after work and did four things:
We came up with a new writing assignment that we’d both work on during the coming week.
We swapped our completed work from the previous week.
We presented our critiques of each other’s work from the week before that.
We ate dinner. (We took turns cooking.)
Each assignment was designed to be something we could complete in a week while carrying on our regular jobs. We also deliberately tried to target our weaknesses, giving ourselves assignments that would push us to improve.
The program had much of the intensity of a writer’s workshop. Every week we felt a great relief on turning in (and turning loose of) the current assignment. Then came the pain of having our previous week’s work critiqued, followed by the unbridled playfulness of brainstorming the topic for the next assignment over dinner and wine. It was something like a romance but without benefits.
But there was one huge benefit: I was working at my craft every day, and constantly learning from doing. Plus, this two-person workshop was easier to set up than a real workshop and didn’t have to end after some arbitrary number of sessions.
After noting the parallels with The Daily Shoot, I wondered if my two-person workshop idea might have some parallels with the Agile practice of pair programming.
Regarding pair programming, Kent Beck says (in Extreme Programming Explained): “Pair programming doesn’t mean that you can’t think alone. People need both companionship and privacy. If you need to work on an idea alone, go do it. Then come back....”
Pair programmers, Kent says:
Keep each other on task.
Brainstorm refinements to the system.
Take initiative when their partner is stuck, thus lowering frustration.
Hold each other accountable to the team’s practices.
The obvious difference with my mini-workshop (and with The Daily Shoot) is that there is no shared task. But there are similarities: keeping each other on task, brainstorming, working together to clarify ideas, and holding each other accountable. And there’s the obvious similarity that both pair programming and mini-workshopping get a second pair of eyes looking at your work. The big danger in working alone is that we all have our blind spots. Another set of eyes can often see what we can’t.
There’s another benefit of working with others that I haven’t seen discussed anywhere: something that has to do with the perception of time.
The Beat of Other Hearts
I wrote a novel in November, or at least a first draft of a novel. I did it through the NaNoWriMo program, and I know I wouldn't have completed it without that support, and I say this as a fiercely independent worker.
I like working alone. I’ve worked in offices where interruptions seemed to be my whole job. It bugged me no end, and was not so great for my productivity. But I’ve also worked at the opposite extreme: twelve hours a day alone in a house at the end of a one-lane road on a mountain ridge. Sometimes when my partner came home from her two-hour-each-way commute, I couldn’t account for my day. Oh, I’d done work, I just couldn’t reconstruct the day. I had no reference points in time to tie things to. This, too, was not good for my productivity.
The past decade I’ve been able to get away by myself or to work with others around, as I choose. Having two offices, separated by a driveway, helps. It also helps to be the boss, so that when I say I’m not to be disturbed when I’m in my home office, people actually listen. I get a lot done when I’m hiding out in the home office. But I get a lot done in my other office, with people all around, too. It’s just a different kind of work. The experience has made me understand that the mere presence of others is a clock, a frame that makes time measurable.
Writing, whether articles or code, is at its core a solitary activity. Or so I find it. But learning ways that we can support each other in our solitary work is empowering. And can be a lot of fun.