I can't agree more with how important it is to structure a document well so that others can easily understand it. As a software engineer, I can relate this to programming. Programming is somewhat similar to writing English except in the case of programming, the documents written are meant to be read by the computer and other programmers. However, a lot of programmers forget that their code must be readable by other programmers and write it in a way such that only the author and the computer can understand them. There is a very large branch in software engineering dealing with how to write well designed and structured code.
Just as chapter 8 presents several patterns for organizing different types of documents, there are software design patterns ( http://www.dofactory.com/Patterns/Patterns.aspx ) available to programmers. Software design patterns provide standardized solutions to commonly occurring themes in code. Some software design patterns even describe how the entire program should be structured overall. When I read the “Patterns of Arrangement” section from chapter 8, I could not help but notice the resemblance to software design patterns.
One thing to note is that patterns are not always appropriate. Sometimes, what you want to express (weather it is English or code) does not fit well within a known pattern. In that case, the writer must not fear to step outside of the comfort zone set by these patterns to best convey what they mean. If done successfully, this could lead to the invention of a new pattern, and if it’s creative in a pleasant way some people may even consider it to be art.
In conclusion, stick to patterns when they apply so that others can easily navigate and understand you work, but don’t be afraid to explore other alternatives when existing patterns don’t seem to apply well.
Structure
Good structuring of a document really does make it easy for a reader to understand. For instance a restaurant menu is set up like the flow of how a meal typically goes so the customer will know where to look for what they want. A document that is discussing a topic works the same way by organizing the material in a way that the reader will know where to look for the information that they need. This way of organizing a paper has been taught this way to me from elementary school on. It has worked for many years and I do not foresee it changing anytime soon.
Software Design Patterns
Being a programmer myself (C#.NET, Java, PHP), I can relate to your comparison of document (genre) patterns given in the reading and coding patterns. A lot of these code patterns get used and applied to methods in the object-oriented languages I know, and are included as libraries to the language itself. I also agreed with how you related coding for a computer and structuring your code properly for another programmer to read, to the content about audience analysis in the first reading. When writing solid code you want to keep both the primary audience of a computer, and the secondary audience of another programmer in mind.
When don't patterns work?
I found your point about patterns to be interesting. Initially, I agree with you that a writer can't be afraid to break a pattern when what he or she conveys doesn't fit within a typical pattern. However, I'm having trouble coming up with a concrete example of something that doesn't fit within a pattern. Perhaps it's not chronological, for example, but certainly anything that you express should be logical, and then it seems like it would have to fit within one of the many patterns given. If it's not an If/then, or a problem/solution, or a chronological pattern or cause/effect, etc. etc. what else can it be? I feel like the reading listed so many genres and patterns that it would be difficult to find something you were writing that didn't follow some sort of pattern, because some of them (e.g. problem, solution) are so unstructured that it would be hard to find something that didn't adhere to at least one of the categories.
Kristin
For how could they not?
After reading through Estefano’s chapter 8 post, there was little I could disagree with as well. Primarily, it was easy to relate his examples to my experience and both back to the source text as I am an application developer as well. For example, in his response he outlines some of the software design patterns that are available to programmers and proceeds to identify how they relate to those presented in chapter 8. Where I disagree with this response is in line with your reply. Estefano suggests that “patterns are not always appropriate” and that “sometimes what you want to express does not fit well within a known pattern.” As you’ve asked here, when is that the case? I feel, as well, that a genre exists for any situation as those genres are the aggregate result of previous professionals intending to account for any style of document to be written in the future. Basically, the genre relates primarily to organization and is independent of the literal content. For this reason, I agree with your reply, that any writing should adhere to one of the genres/patterns outlined in chapter 8.
Different Patterns
I actually agree with estefano about stepping outside the box and using your own pattern or genre if one doesn’t seem to fit. Although I cannot think of a specific example for writing, if you are writing something and it doesn’t have the right feeling to it, change it. An example that comes to mind quickly is with music. You can play the same song on different instruments and get a completely different feel. Even though they may have the same notes, lyrics, etc, the dynamic has completely changed. I have to disagree with the statements to always use one of the accepted genres or patterns. If you do there will never be change, change that could be better or worse.
Patterns always work
Kristin brings up an intriguing point-shouldn't everything fit into some pattern? I think the answer diverges from a strictly 'tech writing' thought of mind and is much more general. I probably won't do this explanation justice, but: it is like trying to imagine a new primary color-it can't really be done since the current primary colors are all encompassing. In much the same way, there is no new way to write using different patterns-simply combinations of previously determined patterns or patterns that are not traditionally associated with (in this case) technical writing. This is turning into a discussion on linguistics; I digress.
Coding patterns
Being a programmer as well, I really liked the comparisons you made between writing well structured code and the material presented in this chapter. When I first started programming I never liked following the set standards and it always seemed like more work then it was worth. However that changed once I got my first IT related job and was tasked with updating someone else's program. If the original author hadn't followed any kind of pattern or structure it would have been much more difficult to read and understand his code.
I also think Kristin makes a good point. With all the different structures and patterns that the chapter describes, it is very difficult to think of some form of writing that wouldn't fit into least one of those patterns.
Patrick Griffin
pgriffin@purdue.edu
Coding and writing go hand in hand
I can also relate to your coding example as I worked with various coding languages. Structure is very important and definitely relates to chapter 8. Introduction is defining your variables and setting up a basic shell for the code. The body is code that makes your program run. Finally the conclusion would be ending the program or creating an output. Others have to understand your code as you are writing it for them so commenting is very important. The only difference I can think of it that I always start at the introduction when coding instead of writing where I usually start at the body of the paper. It has something to do with having a definite beginning with coding, but that could just be me.
Jeff
I enjoy your comments on
I enjoy your comments on programming in this response and your ideals on new patterns. I can certainly relate to what you are saying about how programming also needs to be readable to other programmers, and how this is often forgotten by the initial programmer. Maybe we can convince some of those programmers to take this class and learn something about documenting their actions accordingly. I like how you talk about the fact that patterns don’t always apply and that if a certain document doesn’t fit a certain pattern, there is always the possibility of creating a new pattern of sorts.
Thanks!
JFlitt
www.JFlitt.com
Patterns
You express a good point when you talk about forming patterns. Like many classmates have said, the most important part in technical writing is to convey your point to the reader as clearly as possible. Patterns,like you said, are an easy way to do this. In order to create a pattern there should be repetition, because writers use similar structures more than once, patterns are formed. Readers then become familiar with the pattern and thus can interpret the writing easier.
It was interesting what you said about going outside patterns. "Some people may even consider it to be art,"is and idea that I never thought about. However after you brought it up I thought about all the poetry that is written so abstractly. I like your thoughts on writing inside and out.
Evan