Agile Zone is brought to you in partnership with:

Jim Highsmith is an executive consultant at ThoughtWorks, Inc. He has 30-plus years experience as an IT manager, product manager, project manager, consultant, and software developer. Jim is the author of Agile Project Management: Creating Innovative Products, Addis Wesley 2004; Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, Dorset House 2000 and winner of the prestigious Jolt Award, and Agile Software Development Ecosystems, Addison Wesley 2002. Jim is also the recipient of the 2005 international Stevens Award. Jim is a DZone MVB and is not an employee of DZone and has posted 30 posts at DZone. You can read more from them at their website. View Full User Profile

Writing to Learn

07.10.2013
| 2911 views |
  • submit to reddit
Writing_Letter

Image Source: Jonathan Gazeley

“Writing is a form of thinking, whatever the subject,” says William Zinsser in his book, Writing to Learn. Agile methods are driven by feedback and learning practices and so it’s important to understand how learning to write well is critical to learning well.

The entire results of software projects are writings. Whether the output is code, test scripts, stories, documents, training plans, or project status reports, they are all, in some fashion, writing. Writing is both a form of thinking and the results from that thinking—and unfortunately, technical education programs rarely focus on writing skills. In the preface to his book, Zinsser writes, “My hope was to demystify writing for the science types and to demystify science for the humanities types.” His working hypothesis is that “writing and thinking and learning were the same process.” He believes that learning to write well is just as important for the geology and mathematics student as it is for the language or creative writing student.

Zinsser makes a couple of key points about writing. First, he believes that good writing can make any subject interesting and available to the general audience. Take for example John McPhee’s book Assembling California which delves into the California’s earthquakes and other complex geology in a way that fascinates the readers—this reader at least. Second, Zinsser points out that good writing and good learning go together, “Writing organizes and clarifies our thoughts. Writing is how we think our way into a subject and make it our own.” One history professor colleague of Zinsser’s commented, “An idea can have value in itself, but its usefulness diminishes to the extent that you can’t articulate it to someone else. What the writing program made me realize is that I have to take much more time in class to talk about writing.”

Writing is hard work. Sometimes we write about what we know. Sometimes we write about what we are thinking—to attempt to clarify that thinking. Both are hard. “I found it consoling after all these years to learn that writers are up against nothing less than the fundamental anarchy of the universe; entropy, prince of disorder, is sprinkling noise on everything we write,” says Zinsser. “Ambiguity is noise. Redundancy is noise. Misuse of words is noise. Vagueness is noise. Jargon is noise. Pomposity is noise. Clutter is noise: all those unnecessary adjectives (“ongoing progress”), all those unnecessary prepositions draped onto verbs (“order up”), all those unnecessary phrases (“in a very real sense”). Information is your sacred product, and noise is its pollutant. Guard the message with your life.”

Some people write from a detailed outline. I like starting with an idea and then let the words unfold as I go along. I’m often surprised at where a piece I’m writing ends up! Code often follows the same path—we start out with the outline of a story and the story unfolds as we code. The learning and feedback cycle in these instances is very fast. It’s also why I like the term story so much better than requirement. A story gives us the opportunity to learn and adapt—a requirement doesn’t.

So if writing improves learning, how do we learn to write better?

“Artists, writers, poets, software developers, software designers, software architects, pattern writers, … have something essential in common: They make things under risk,” writes Dick Gabriel in Writers’ Workshops & the Work of Making Things. Writers’ Workshops have long been used by the creative writing community to help writers improve their work. Dick has an interesting background—Distinguished Engineer at Sun Microsystems, Ph. D. in Computer Science from Stanford University, Master of Fine Arts in Poetry from Warren Wilson College, and lead guitarist in a rock ’n’ roll band. He aspires to bring innovative ideas and practices from the artistic community to our technical one.

Making things—whether it is a software product, a poem, or a technical presentation—requires some measure of creativity, and creativity involves overcoming fear. A poet fears that peers will hate the poem. Book authors fear that no one will like or buy their book. Software developers fear that colleagues will think their code amateurish, or fear that customers won’t buy their products. Writers grow capability by overcoming, or at least redirecting their fears. They use fear as a catalyst for learning and growth. “Fear is at the center of the concerns of risky makers, and the writers’ workshop is a mechanism—an institution, a ritual, and a technique—for addressing fear, for finding a way to make the piece work for the maker,” says Gabriel.

Process and methodology are often ill used in an attempt to eliminate fear rather than channel it, and in so doing, they kill creativity.

There is no creativity without facing the fear of failure.

Traditional methodologies, at least in how they are often implemented, attempt to eliminate fear by creating the illusion that if we follow the process, everything will work out just fine. Since, by nature we would rather not confront fear if we don’t have to, methodologies are appealing. However, creating outstanding products requires building personal capability which in turn requires three things: channeling fear, extensive practice, and receiving feedback. Writers’ Workshops help with all three.

A Writers’ Workshop is a facilitated session with an author and several peer reviewers in which the participants provide the author with a critical analysis of a work product. However, the critique focuses on style first and content second. So, for example, a typical requirements document review would focus on the completeness and correctness of the requirements themselves. A Writers’ Workshop would focus on the clarity of the writing, on understanding the thought process of the author, on offering alternative wordings or organization, on presenting ideas about gathering requirements in a different way, on sharing the participants’ knowledge of how to present requirements in an understandable fashion. In short, a typical review focuses on content with the side benefit being skill building. A Writers’ Workshop focuses on skill building with the side benefit of improving content.

“Great art is a process of making lots of things, knowing how to select the good ones, and knowing how to perfect them—making stuff, choosing critically, making some mistakes, being able to recognize them, and then being able to correct them,” says Gabriel. His insight is simple and profound: To get good at something we have to make lots of them. To be a good poet, one has to write a lot of poems. To be a good writer, one has to write a lot of articles, books, emails, and tweets. To be a good programmer, one has to write a lot of code.

But practicing isn’t enough. We need the ability to select the good from the bad, the exceptional from the mediocre. We need the ability to perfect our writing—to edit, revise, reorganize, eliminate, reword, and rework. Practice is personal. Selecting and perfecting is social. In a vacuum, I can practice, practice, and practice. But how do I determine which of the practice pieces is good, bad, or indifferent? How do I learn how to make a selected piece better? How? By sharing them with others. In the end, writing is a social encounter that exposes one’s work to others so we can learn what products are good and which aren’t and why, and to help us learn how to turn good products into great ones.

Published at DZone with permission of Jim Highsmith, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)