Skip to main content

Feeback, Writers Workshop Style

I was fortunate enough to participate in the first few Pattern Languages of Programs conferences, where I learned quite a bit about technology, writing, problem solving, and giving and receiving feedback. What made the biggest impression on me was the process the patterns workshops used.

Before I started to write patterns, I was used to getting feedback in a way that focused on what was wrong or missing in my presentation. The patterns community approach is to evaluate papers through a shepherding process that ends in a writers workshop.

A patterns writers workshop has the following parts:
  • The author of a paper reads a selection. This gives the other participants a chance to understand something about how what the author thinks is most important about the paper. After this reading the author becomes a passive participant in the session, only speaking if someone makes comment that isn't clear. The author does not defend his writing.
  • Someone in the workshop summarizes the paper. This allows the author to understand if the main points of the paper made it through.
  • The group discusses what they liked about the paper.
  • The group discusses things that could improve about the paper. Notice that this phase is not "things that are wrong about the paper," as the goal is to help the author.
  • Finally, the author can speak again, asking clarifying questions.
The important things about this process are that the feedback starts with positives, and focuses on improvement. Reinforcement of what's working helps the author be more receptive to suggestions for improvement later on and provides guidance for what not to change. Since the "negatives" are cast in terms of actionable items, the author has direction.

I've found the following approach, which is a variant of the workshop format, useful in other circumstances outside of reviewing writing:
  • Starting with things what went well
  • Discuss things to improve, not simply things that are broken.
These guidelines are part of retrospective formats and this is a component of some management techniques. Sad to say, many day-to-day many seem to focus on negatives, because the argument goes, there isn't a need to discuss what you're doing well. This isn't a great argument. Without feedback on the good things, someone won't have the confidence to make improvements or guidance on what strengths to leverage as they make changes to their work.

Sure, the first tendency is to focus on what's broken, since it probably has your attention, and thinking of things to do to improve takes more work than simply registering observations, but if you are being trusted to provide feedback, shouldn't you put in the effort?

Next time someone asks you to give feeback on a work item:
  • Start off by finding at least one thing you liked, and mention it.
  • When you discuss things that need fixing, try to use a sentence that has the form: "this would be better if ..."
See if this approach helps your feedback be more well received and more effective.

For more on the writers workshop process and applying it in technical contexts, have a look at the book Writers' Workshops & the Work of Making Things: Patterns, Poetry.... To learn more about patterns visit the Hillside Group. Esther Derby wrote a great article to guide managers in giving and receiving feedback.

Comments

Popular posts from this blog

Continuous Integration of Python Code with Unit Tests and Maven

My main development language is Java, but I also some work in Python for deployment and related tools. Being a big fan of unit testing I write unit tests in Python using PyUnit. Being a big fan of Maven and Continuous Integration, I really want the  Python unit tests to run as part of the build. I wanted to have a solution that met the following criteria:
Used commonly available pluginsKeep the maven structure of test and src files in the appropriate directories.Have the tests run in the test phase and fail the build when the tests fail.
The simplest approach I came up with to do this was to use the Exec Maven Plugin by adding the following configuration to your (python) project's POM.

<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <executions> <execution> <configuration> <executable>python</executable> <workingDirectory>src/test/python</workingDirect…

Displaying Build Numbers in Grails Apps

Being a fan of Continuous Delivery, identifiable builds, and Continuous Integration: I like to deploy web apps with a visible build number, or some other way of identifying the version. For example, having the build number on the login screen for example. In the Maven/Java world, this is straightforward. Or at least I know the idioms. I struggled with this a bit while working on a Grails app,  and wanted to share my solution. There may be other, better, solutions, but the ones I found approaches that didn't quite work they way that I'd hoped.

My requirements were:
To display a build number from my CI tool, where the number was passed in on the command line. In Bamboo, for example you might configure a grails build as
-Dbuild.number=${bamboo.buildNumber} warTo only change build artifacts and not any source files.To not misuse the app version, or change the names of any artifacts.To be simple and idiomatic.I realized that that Grails itself changes the application metadata (appl…

Motivation Visibility, and Unit Testing

I've always been interested in organizational patterns (such as those in Organizational Patterns of Agile Software Development). I've recently found myself thinking a lot about motivation. I'm now reading Drive: The Surprising Truth About What Motivates Us and just finished Rob Austin's book on performance measurement. Being the parent of a three year old, I'm finding more and more that "because I said so, and I'm right" isn't too effective at home. My interests in motivation are closely related to my interest in writing software effectively. Writing software is partially a technical problem about frameworks, coding, and the like, but the harder (and perhaps more interesting) problem is how to get a group of people working together towards a common goal. Agile practices, both technical and organizational, build a framework which makes having the right amount of collaboration and feedback possible. But there's a bootstrapping process: How do yo…