Contributed by Brian McNely
“What is it that you do?” asked the gentleman sitting across the large round table in the cafe area during lunch at Google I/O, the annual software developer’s conference held in San Francisco.
“I’m a professor at Ball State University,” I said.
“Oh? What department?” he replied, no doubt wondering if I worked in HCI, computer science, or informatics.
“I’m actually in a department of English,” I said, noting the raised eyebrows and grins from the three others sitting at the table. “I study and help develop applications for distributed work, especially to facilitate networked writing collaboration,” I explained.
“Man, you must be the only English Professor here!” he said.
He’s probably right. I was likely the only English Professor at Google I/O, both this year and last, when I traveled to the conference with my research partner, Paul Gestwicki, a computer scientist at Ball State. But that probably shouldn’t be the case. Those of us in the computers and writing community should probably be spending more time hanging out with developers at developers’ conferences (e.g., OSCON, PyCon, Defrag, etc). And software developers should probably be spending more time with hanging out with computers and writing researchers.
Why? Let me tell you about the most popular breakout session I observed at this year’s I/O, by far: “Programming Well with Others: Social Skills for Geeks.”
At the 2010 version of this conference, attending breakout sessions was much as you might expect; you peruse the agenda, select a session based on subject matter, presenters, or (ideally) both, and amble casually into the room a couple minutes before the start. That’s what I’d planned to do about 10 minutes before the Social Skills for Geeks session, and that’s when I noticed the line of people waiting to get in, stretching down the hall for about 150 feet, and out into the Developer’s Sandbox venue, where start-ups displayed their wares.
This was nuts. Here, at a conference comprised of 5,000 or so developers, were a couple hundred people standing in line to attend a breakout session about social skills and collaboration. In other words, here were a lot of folks passionately interested in the very things that many in the computers and writing community study…
The session itself, led by Brian Fitzpatrick and Ben Collins-Sussman, was fascinating, as were many of the follow-up questions from attendees during Q&A. There were no open seats that I could see (and I was sitting in the back row), in a room that probably held 400–500 people.
The session started with a simple statement: “we’re here to talk about working with human beings.” Early in the session, Fitzpatrick suggested that “the social stuff is really hard. It’s more squishy. It’s a lot less deterministic.” Collins-Sussman added that, essentially, if you want to be a sucessful software engineer, you need to focus on the social aspects of developing and shipping your applications.
One of the recurring themes from this session was the importance of writing work in supporting the everyday collaboration practices of developers. “You need to document it [your work],” one of the presenters argued. “If it’s not written down anywhere, you will still see people coming in and arguing with you. Keep a trail of documentation so people know where you’ve been and where you’re going.” Fitzpatrick and Collins-Sussman were likewise focused on organizational culture, and, not surprisingly, writing’s role in shaping and mediating that culture (even though they didn’t describe it in those terms).
For example, during the Q&A period following the presentation, a 23 year-old developer asked a question about disruptions caused by a new team member who is in his 40s, and who isn’t respecting the norms of the collaborative. Fitzpatrick and Collins-Sussman suggest that this is a case of “cultural invasion.” “Are there specific development practices that you all adhere to?” they asked. More importantly, “is it [the culture] documented?” they added.
Their answer to the young developer focused on cultural norms, the documentation of those norms, and the role of the developers themselves—not the management team—in helping to enculturate new team members.
“What are the tools you use on a regular basis to define your culture?” they asked, more generally, adding that in their own practice there’s a strong focus on the social and interactive aspects of group work—things like beers on Friday, nerf guns in the workspace, and eating lunch together (while not necessarily talking about work). Social media is important too, as interstitial writing work that helps mediate collaboration and enculturation.
Clearly in evidence at I/O is this realization: there’s a whole lot of people in overlapping disciplines like software engineering and development with whom we might form productive relationships as we broaden the scope and reach of our work. Indeed, in organizations like those described in the Social Skills for Geeks session, the knowledge work of software development, as Grabill and Hart-Davidson note, looks like writing (e.g., code commentary, Scrum), “or is substantively supported by writing” (e.g., cultural norms and practices). Writing, Grabill and Hart-Davidson argue, “is how knowledge work carries value in organizations.”
Fitzpatrick and Collins-Sussman argued something very similar.
Kopelson contends that composition studies, as a field, primarily consumes ideas from other disciplines, exerting “little to no interdisciplinary influence.”
Perhaps by spending more time with software developers, researchers in computers and writing can better effect the robust interdisciplinarity that we’ve been seeking, in a way that can truly enrich both disciplines.
I, for one, am going to keep hanging out at developer’s conferences…