Writing about writing about writing

I require some reflective writing in my CS222 class. Currently, I'm using two essays during the first three weeks to help students reflect about Pair Programming and Object-Oriented Programming, and I use reflective essays at the end of each of the three final project iterations. Many of the course achievements also involve writing essays. For several years, I found myself frustrated with the range of responses to my request for an "essay," with a few nice compositions buried under the weight of banality and formlessness. Because I subscribe to mastery learning, my students can almost always resubmit their work, but there's nothing more frustrating than responding to a poor composition and then receive another poor one in return.

I realized long ago that part of the problem was this word, "essay," which is used by different people for vastly different purposes. I found myself writing the same response to each student, and so I put together the following stock instructions. These have appeared on many course descriptions under the heading, "An etymological note."

Some assignments and achievements require the writing of an “essay.” I use this term in the classical sense, to describe a composition that represents an attempt to understand a complex idea. An essay is neither a summary nor a staid five-paragraph construction. As the course prerequisite implies, these essays should represent collegiate-level writing. You are encouraged to leverage our digital writing environment to compose multimodal pieces.

For the record, I believe I have had zero multimodal compositions submitted in response to essay prompts—not so much as a photograph or illustration. I like to keep this door open, though, since students are required to take a college composition course before CS222, a course which explores more than just traditional prose.

After putting this note into the course descriptions, it has made it a bit easier for me give feedback: instead of writing out belabored instructions about what I mean when I say "essay," I can just point back to the course description. Even in this case, however, revisions don't always show that students have read and understood these instructions. The instances that come to mind tend to be structural problems, where the first submission lacks paragraph structure, and the second submission does too. It's enough to make me wonder if the real problem is ignorance about fundamental structuring tools, but usually, eventually, we get to a point where a revision is acceptable, though never elegant. I always recommend the use of BSU's Writing Center, but I have no idea if my students are using it or not. (Turns out, writing this blog post pushed me to reach out to them, and they do collect some self-reported data from visitors; they're going to try to let me know what kind of visits they've had from CS222 over the past few years. Neat!)

This semester, after frustration and reflection about last semester's writing, I decided to change my instructions on the course description. It was during the winter break that I took some time to compose a piece about what it means to compose an essay. I suppose I went full-meta. Here's what appears on this semester's CS222 course description, under the new and simpler heading, "Essays":

Some assignments and achievements require the writing of an “essay.” I use this term in the classical sense, to describe a composition that represents an attempt to understand a complex idea. An essay needs to have a point—a theme, a thesis, a central question. This should be supported by evidence, with assumptions identified and claims justified or cited. As implied by this course's prerequisites, our essays should represent college-level writing. 

An essay, properly written, should hurt a bit. If you are truly writing to understand, then you have to be challenging yourself. If you are only summarizing something you have read or previously believed, it is not an “essay” by our definition. 

Writing in this way has implications for structure and form. One long rambling paragraph cannot be an essay: each paragraph should have a clear and coherent theme that supports the central argument, and you need more than one of these to support an argument worth forwarding. The fact that we are writing in a digital environment should not be overlooked: you can include images, video, sound, and hyperlinks, following the same judgement you would use to include any formal element. Even typefaces, colors, and margins are part of a digital composition. These have meaning, and because of that, you should not change them unless you are proficient in digital document design: the defaults are provided because of their generality, and they are likely appropriate for your compositions. 

The Elements of Style provides an excellent refresher on how to produce good, clear writing. It is a short, affordable book in its latest release, and the earliest printings are in the public domain (see archive.org, for example).

I'll point out a few pain points that were on my mind when I wrote this. First, a great many of the submissions don't have a point: no thesis, no theme, no conclusion. I wanted to get at that right from the beginning, because if they do nothing else, I would like them to at least have a point.

The second paragraph is about pain. I see a lot of students write in generalities, avoiding specifics, avoiding culpability, avoiding conclusions. I believe that learning should hurt a little, because it's forcing you to confront something you misunderstand. This may be a lofty goal for a 200-level course, but I wanted to see what happened if I put it out there. Looking at it now, maybe I should revise that paragraph to be more about discussing concrete details rather than throwing around abstractions and generalities.

The third paragraph reflects my continual bafflement at how bad students are at using modern writing technology. We're using Google Docs, so we're not just digital, we're connected. Yet, students practically never include the URLs to their sources, much less actual hyperlinks. What many students do, that I react to in the paragraph, is fart around with fonts and sizes, almost always in ways that distract from the readability of the document. I know that the prerequisite writing course covers a bit of visual design, but clearly, students are not coming through with the self-awareness that they are bad at it. That's understandable coming out of a freshman-level course (isn't that what being a "sophomore" is all about, after all?), but what bothers me is that it's not clear that they understood that these choices have meaning. That is, the choices I see appear arbitrary, not treated like the design decisions that they are.

The last paragraph is my way of sharing my excitement at finding out The Elements of Style first edition was in the public domain. I was required to buy a copy of this book (not the first edition, naturally) in my first semester of grad school, as part of a research seminar course in which faculty presented their research and new grad students wrote essay responses. I remember enjoying the book, not so much because of the structural concepts—I've always been a decent writer, after all—but because it helped me collect my reasons for good writing practice. Maybe it's too much to expect that a sophomore CS major would go fall in love with style, but a guy can dream.

That's the story behind my revised essay-on-essays. I see some parts that I will likely clean up between semesters. So far, it's not clear that it's made any difference at all, except again for the time it saves me: I have referred a handful of students to it after they turn in something completely unstructured or inappropriate.

Follow-up on Story Mapping: Sprint 2 Planning

My team had our Sprint 2 Planning meeting yesterday, and I started with the story map on the wall that I wrote about over the weekend. Most of the questions the team members had were covered in the conditions of satisfaction that I had written on the note card version of the stories. The team decided to migrate two stories below the cut point, pushing them to Sprint 3 instead. The first of these was the external authentic testing of the software system: since the team was committing to making a high-fidelity paper prototype, they were rightly wary of also trying to budget the time for authentic testing. Since we would focus on a paper prototype, we also pushed down the task of making a design guide to specify fonts, colors, and so on. This was also a prudent move, since if the paper prototype evaluation went poorly, we would need the time to clean that up before investing time in a design guide that would likely have to be done again.

Much of this conversation went as I predicted, but the task planning ended up with some interesting results. Several new stories were added to our map, most of them planned for the next iteration.

These new stories dealt primarily with user interactions that we could foresee only after talking through the extant map and considering the bounds of the stories we had committed to. The new stories include:

• Continue uninterrupted if the page is reloaded
• Install the game as an app (manifest.json)
• Continue after pressing the browser's back button
• Browse previously unlocked content
• Clear previously unlocked content
• Finish the story for Prairie Creek

That last one is not a user interaction, but simply our team noticing that we had neglected to include a story for the creative work of finishing our narratives! By the end of this sprint, we should have significantly reduced risk around our core game mechanics and theme, but there still will be necessary work in fleshing out the narrative.

Another attempt at story mapping in the academic studio

About a year ago, I wrote about how my first attempt with story mapping did not go as well as I had hoped and that my team eventually abandoned them. Last semester, I decided to invest some time in building a better understanding of the technique, so I did what any reasonable contemporary developer would do: I bought and read Jeff Patton's book. One of the key insights I got from this book—perhaps something that's obvious to regular practitioners, but I didn't see at the time—is that story maps can replace one-dimensional backlogs but not Scrum-style task boards. That is, while the story map provides the big picture of the project plan, teams still need other modes for tracking smaller-grain tasks. Among other factors, this made me want to revisit story maps in Spring, and so I have.

This semester, I am once again leading a multidisciplinary undergraduate team in an immersive learning project. I wrote a bit about the project when I wrote about sustainability game design and the conclusion of my game design colloquium. This semester, my team is building a Web-based, geolocative, educational game to complement the educational themes of Camp Prairie Creek. We just wrapped up our first sprint, which resulted in the team building a proof-of-concept experience using Polymer while exploring various narrative themes. Before the sprint, I had laid out a story map based on my vision for the project, and the team had some input into the overall shape of it.

Sprint 1 Story Map

During sprint planning, the team decided where to slice it. We took the stories for this first experimental sprint and transcribed them onto new cards for the task board.

Task Board at the start of Sprint 1

The sprint ended this past Friday, and although not every task was complete, we deemed it a success: the team was able to learn the fundamentals of Polymer, including building fluency with command-line git; we have a technical artifact that shows how various pieces fit together; and we have a more coherent vision for a narrative structure and theme. However, throughout the sprint, I didn't see any students actually using the story map. They would congregate around the task board around the time of the stand-up meeting, using it to direct their communication and activities. The story map, which is physically far from the task board, did not seem to get any attention.

One of my responsibilities yesterday was to recreate the story map based on what we learned. The first pass looked reasonable.

First pass at revised story map

During Friday's Retrospective meeting, the team decided that their work would be improved by the inclusion of conditions of satisfaction for each story. Usually, when using Scrum, I write the names of stories (in Mike Cohn's format) on the front and the conditions of satisaction on the reverse. It was not clear to me if these fit with the story map format, so I had left them out in the name of simplicity. I have one returning team member who was in last Spring's studio, and this student was one who strongly recommended including the conditions of satisfaction. So, after creating that first pass at a story map, I sat down with my large-format index cards and starting re-writing the stories to them.

This process led me to consolidate several stories. This wasn't quite what I expected, but the new articulations were much cleaner, in my opinion: they were more encapsulated rather than spreading one action across multiple notes. For example, "See a map with location markers" and "See my own location on a map" became consolidated into "See annotated map," with conditions of satisfaction indicating that we want to see both our own position and marker positions. These could remain separate, but I was thinking about how they would migrate to the task board: the two small stories looked like they would take up more room than they were worth, whereas one story would just have a few extra rather small tasks. It may be worth noting that the team already has this mostly done in the tech demo, so much of the story will be revising how this feature is implemented within the revised visual design.

Revised story map

I've included below a photo of the task board cards that I expect the team to take in Monday's planning meeting. Of course they will be able to negotiate on what goes above and below the slice, but I suspect that we won't see much change here.

Stories with conditions of satisfaction, for the Task Board

[See follow-up post for more]