Having completed the first unit of ENGL 301 Technical Writing, I would like to offer a few thoughts on my experience in the course so far. This past week, my writing team and I worked on an assignment for which we wrote three different definitions of a technical word specific to each of our chosen professions. If you are interested in reading our definitions, you can find my writing team’s page here: https://blogs.ubc.ca/engl301-98a-2020sa/category/team-forum/the-ramblers/.
For my assignment, I chose to define the word agile, because I had difficulty understanding exactly what it meant when I first began studying computer science. If you are unfamiliar with the term, you can find my revised definition of agile here: https://blogs.ubc.ca/engl301-98a-2020sa/2020/06/12/revised-definition-of-agile/ or here. Agile is an often-used word in software development, but it is implemented in a wide variety of ways, so it can seem to mean different things to different people. What’s more, terms such as Scrum are sometimes used interchangeably with agile in casual conversation, which can make the true meaning of agile even trickier to grasp. Unhappy with the word’s seeming ambiguity, I thought I would seize this opportunity to pinpoint its meaning for myself, and possibly help students new to the field of computer science in the process.
Geneviève Bolduc’s review (https://blogs.ubc.ca/engl301-98a-2020sa/2020/06/09/peer-review-for-cody-gagnon/) of my assignment was very helpful, because she suggested that I might improve my definition by explaining that agile was developed as a response to the limitations of the waterfall approach to project management. Initially, I chose to exclude historical information about the development of the agile methodology, because practicing agile does not require knowledge of its history. However, Geneviève’s suggestion made me realize that I could include a little history without going into great detail. In addition, I now recall a lecture that focused on the agile methodology in CPSC 310 Introduction to Software Engineering; the lecture included historical information about agile and waterfall, which I found helpful at the time. I think that my intended audience (first- and second-year computer science students) will likely find it helpful, too.
I hope that my review of Geneviève’s assignment was helpful to her. I found it challenging to provide constructive criticism in writing and I hope that I have avoided causing offense by being indelicate. As a former Writing Consultant at UBC’s Centre for Writing and Scholarly Communication (CWSC), I would have much preferred to discuss the written draft with its writer. At the CWSC, I would meet one-on-one with students to discuss their writing in half-hour time slots, which provided the opportunity to consider together the possible approaches to the subject at hand. Unfortunately, discussion and conversation are, of course, not possible in a written peer review. However, I tried throughout my review of Geneviève’s draft to emphasize that I was offering suggestions and opinions and nothing more.
All in all, I found the exercise useful, because it has exposed a weakness in my writing of which I was formerly unaware. I hope to improve my ability to provide constructive criticism in writing before the course ends.