Chapter 9

Resumes are an essential part of any typical hiring process. It is the summary of ones achievements, accomplishments, and experiences that explain why one would be a fit candidate for hiring. The chapter focused on the parts of a resume, such as contact info, objectives, experience, education, and references. My experience has shown me that this is only the tip of the iceberg when it comes to resumes and not only could on write entire books on the subject, but they have. I think in many ways its not what you have done but how you present it. This is something the chapter skimps on in my opinion. Showing quantitative data is the easiest way to convey quick information and quantifying qualitative information is a useful skill to use on resumes. Also it is important to not waste space and control the readers eye, because typical managers do not give a resume more than a minute for the first glance to judge whether or not to continue reading or pursuing a candidate.

Chapter 21

In the section for preparing for oral presentation its first section is about research and connect the topic to your audience. In my opinion I think this is the most important part of not only an oral presentation but to any presentation. Even a very well thought out presentation, proposal, or memo means very little to nothing if it is not researched correctly and fully or made relevant to the audience. Without a connection to an audience, you don't give them a reason to care or listen. Without perfectly researching ones topic, a person can lose an audience if they identify a flaw in the argument.

Chapter 17

The chapter on proposals I found to be most useful in its examples of what a proper proposal should be and the types of such. The thing I found most interesting was the brief discussion on the difference between a formal and informal proposal. Formal proposals are often very specific, long winded, technical document prepared for a specific target audience. I have some experience writing proposals and they usually follow military type standards that are extremely detailed. What I found that was interesting was that informal proposals are relegated to memos. Memos get a point across in a brief form, but the fact that memos are all encompassing shows how important they are.

Packet Review

I reviewed the suggestions/implications portion of the packet for the web study. I did not like that it was broken into two separate sections, and after they were broken up into those sections I felt that the suggestions should have come before any implications of those suggestions. I also felt that they should have stuck to fewer key points in the suggestions instead of a "laundry" list of things. This is because one would be able to better focus on what is important and how to fix it instead of many points with less explanation or justification.

I learned from reviewing another's packet that people write with very different styles when prompted with the same thing. I also learned that paragraphing and chunking are very important to cohesive writing, and if not done correctly it can be bothersome for the reader or even possibly confusing all together. If I could do anything different, in terms of this portion of the packet, would be perhaps outlining what i wanted to achieve before I wrote it out. It also makes me want to review it again in order to make sure it is written coherently and paragraphed properly.

Chapter 10 & 14

Chapter 10:

I find it interesting that the book says that memos are more formal and professional than emails, but that emails are often used in substitute for a memo. I find this interesting because I worked in a workplace that never used memos and relied completely on emails, and these emails were all typically treated formally as long as it was between departments. When it was used within a single department the tone was much more relaxed and therefor less "memo-like". I thought it was interesting how specific of layouts and formats they had for the types of memos, and appreciated the different examples as I definitely pick up things better that way. I also, liked the difference from direct and indirect tones and the context to use them in. Though I think that it is not always as cut and dry and indirect for bad news, direct for good news or things that need to be done. Often I prefer the direct tone but this may be a personal preference thing.

Chapter 14:

I first thought it was interesting that they have an entire chapter devoted to summaries, for the general fact that it is pretty obvious its function and how to effectively create one. The part that I liked was when they expanded on the normal idea of a summary and added that one should include a part to help inform the reader if they should read the entire document and the context of said document being summarized. These two things are I think often more applicable to professional journals and articles as they can often be long winded and technical in nature. I like the step by step approach to writing a summary, I think it is a bit many steps for something so simple, but also the steps allow it to be as effective as possible.

Chapter 7 Note

I personally love using graphs and flow charts for as much as I can professionally. When I worked as an intern I used graphs and charts extensively to show them the impact of my various types of work that I was doing. And Not only with my major do I use flow charts quite extensively in order to explain complex concepts and systems but in many training documents I have made I use them. One point in the chapter on pg. 122 says not to use too much information in a single table but often with my major there is again no real choice. I have seen database charts extremely complex and spanning multiple pages when printed out. But to the trained eye you can pick apart what is really going on. I think that as long as all the information is closely related and contingent on one another it is good to include a good amount of information, this way it can serve multiple purposes and not just make a single point. Using graphs that I constructed that were very complex I found out things that I had not even thought about prior to their creation in terms of impacts of certain actions on the system.

Chapter 4 & 5 Notes

Chapter 4:

I have never thought about levels of an audience, but it seems to make logical sense. For documents that are used for important purposes, many different types of people will be using it and therefor will have to be geared towards each of them in a certain way. I also find cultural analysis very interesting, so the part that focused on an audiences cultural background was fairly intriguing. Of this the most interesting part was how Eastern and Western societies styles seem to directly oppose each other. With Japanese societies preferring a collaborative and open message, while Western societies prefer a direct and focused message.

Chapter 5:

I liked the strategies for outlining portion because it is something I do often before I write anything extensive. I always list general topics and subject that will be outlined before attempting to organize them just like they had stated. One odd point I found was the "avoid excessive subtopics" section. It makes obvious sense to require more than one subtopic in order to make a new sub-level. I have found that when I do complex outlines though, excessive is very relative and I found the need to make far many sub-levels than I could nearly understand. In that situation, I would love to know what they would propose.

Ethnography

Ethnographies are an important way to try and understand people that come from very different cultures and histories. Due to these very different environments that some people are raised in, with different belief systems and languages, understanding and communicating with others can be very difficult. Therefore, ethnographers typically have to immerse themselves into a new culture to understand them best. Once this is done a culture can be better understood and therefore communicated with.

Chapter 13 Note

Though I find instructions a quite mundane topic, one thing that I always find fascinating is how legally a fault in the instructions/warnings/procedures are treated the same as a fault in the product. It is up to the manufacturer of a product to properly warn a user of all possible dangers to the product, the environment, to themselves or others. Leaving these things out will not only put the user at risk, but bring to life the possibility of being sued over any such incidents. Bad publicity, lawsuits, and money are probably the biggest motivators in technical writing being so important for companies. Besides that it was nice to see some typical formats for instruction sets, templates seem to be more effective for me than just descriptions of how to write.

People [Cubed]

It makes the claim that knowing and understanding your audience is one of the most important ways to effectively communicate. I definitely agree because without understanding your audience you don't know how to speak with them or how to get across your points. You may give them all the information that they need but if they don't understand what you are saying or if you do it in a way that is not pleasing to them, it will not get through. Values, emotions, expertise, ethics, and personalities all influence the way a message is interpreted, and that is the most important thing in communication. In systems analysis, I actually have done personas work before and I think they can be at times quite helpful in understanding how a system is being used.

Download Music(Purchasing) Instructional

There is no way to download music legally online unless you purchase it or subscribe to a service. Once you purchase a particular album, set-list, or song from a service such as iTunes it is tagged with a piece of code signifying such. Therefore legally downloading music is as simple as finding a service you want to use and purchasing it. From there it will be downloaded onto your PC, if the service is not a subscription based one. If it is a subscription based service you never own the music and therefor cannot download it, only listen to it. Below is a basic instruction on purchasing a song from iTunes.

http://support.apple.com/kb/HT1879

Weekly Reflection 9/5

I have always known that my field was very related to technical writing. Much of my major is dedicated to documentation of systems, plans, and proposals. One aspect of technical writing that challenged my understanding overall was how wide of a net technical writing tends to cast. Technical writings consist of far more than I initially perceived, and there are still certain things I have a hard time putting under its umbrella. Blogs in general I have often found to personally not be technical, because while it it sometimes in the technical realm, it often boils down to more personal thought rather than to a specific audience. This blog though, is clearly more technical because there is a clear audience that we are writing to as well as specific topics we are covering. Even it being considered more technical, this blog is still hard for me to consider fully technical writing. In time I am sure the concept will be more clear to me.

Chapter 2 note

One thing I noticed in this chapter was the ethical abuses section, specifically pertaining to the stealing or divulging of proprietary information. This has been a hot topic issue lately with the organization Wikileaks fully dedicated to such divulging. While some things should remain private, certain things that should be cause for alarm are protected by secrecy by governments, organizations, and corporations. With the connectivity of all of our information being migrated to the internet, it will become easier and easier for information to find itself in public regardless of its content.

What is Technical Writing?

A piece of writing is technical if it is clear, concise, and typically complex while addressing the subject matter in a way that suits a specific audience.

Writing Homework 1

Then, find two example of what you would consider technical writing and two example of what you would consider non-technical writing and explain why you categorize them the way you did.

Technical:

http://allrecipes.com/Recipe/pizza-on-the-grill-i/detail.aspx

This is technical because it is a clear, concise set of instructions on how to grill a pizza.

http://spectrum.ieee.org/computing/it/quantum-cryptography-cracked

This is technical because it is a clear and concise article about quantum cryptography being possibly cracked.

Non-Technical:

http://classicpoetryaloud.podomatic.com/entry/2007-07-26T01_14_34-07_00

I choose this as non technical because the poetry is often vague and open for interpretation.

http://www.reddit.com

I choose this as non technical because while the messages are sometimes clear and concise, they are extremely informal especially when taken in the full context of the responses.

Project 1

I had originally made this blog a long time ago for myself to write random thoughts, and rediscovered it when I logged in to make one for this class(ENG 249). All the design elements are from my original design, and tend to be toward the more simplistic design. It has a minimalist technical feeling to it because that it the kind of thing I find personally interesting with blue font accents. It is also over a white background, which I like for designs because it is easy and natural to read. As for fonts, I used the defaults that came with the setup because overly fancy fonts become harder and harder to read and tend to just annoy me. I, in general, wanted the focus to be on what I wrote and not what I wrote it on.