Author: murphy.christo

For Project 3, I first used the schema as an introduction to the public work proposal genre. Once I had a general feel for content, I used the schema as a list for all the components I needed to address in my proposal. I found the schema to be appropriate for my proposal in that it contained all the pertinent topics that would be addressed when petitioning for a road improvement- any further details would be semantics or pertain to a specific proposal.

One aspect of the schema that was very useful was the level of detail in each section- it made it very clear what was required. Breaking down elements such as feasibility into economic and environmental components removed guesswork as to what the content should be focused on. However, there were other sections where I felt there was a lot of overlap and had a hard time differentiating between them. For example, when addressing the who and how aspects, I felt as though I was repeating that the MassDOT were the ones in need of funding and that the project would happen if the MassDOT received funding.

Overall the biggest problem I ran into was the variance in structure between the proposals put forward by the original Group 3; there were large differences between the length and number of attributes included in each member’s proposal. This made it difficult for me to gage the importance of each section relative to others or the general length it should be.

The peer review process helped me gain a slightly better idea as to how each section should be differentiated from one another. Not having been part of the original design team for the schema made is noticeably harder to use it and understand the sections. It was mostly through examples and peer feedback that I was able to gain a more in-depth understanding of it. I would like to improve the schema through better clarifying which parties involved (who) should be mentioned in each section (receiving vs. giving party).

For Project 2, the schema my group generated was a useful framework for how to structure my cover letter. It was very helpful in terms of defining the material that should be included in each section. It effectively served as a checklist for each step of the writing process. While it was very helpful for content, it was not quite as helpful for relation between content; it was very easy to satisfy the conditions of each element but by zooming in on each section individually, but creating a flow between sections was sometimes lost by using the XML processor. For example, I could list examples of experience from work, school, and my personal life in the correct order, but by focusing on each as an individual element, I would overlook the relation between each one and adding smooth transitions between them.

Overall, I think the group work was the most useful in terms of developing skills; it was in the groups that all the major writing analysis took place. The individual work was mostly based on following the schema and creating a product based on all of the experience we gained while in groups. I believe that creating the schema went very well for my group, while the individual composition was more challenging in that it had a very broad application and our schema allowed for many elements to or not be included. If I could change one thing about the assignment it would be an increase in peer review for both the schema and our individual compositions.

For the third and final project, I will have the option of doing a feasibility report, proposal, or edutainment article/blog. Being in engineering, all 3 options are viable papers that I may write at some point in my career. However, I believe the proposal would be the most useful schema for me to work on since a lot of the work I will be doing will be in mechanical contracting.

It is very possible that I will have to market my ideas or market my brand’s work over that of other companies. For example, if a contractor sends out a request asking for an HVAC system, it could my job to talk about all the direct and indirect benefits of a system my company could provide. The audience would be the building contractors and engineers who decide which company presents the best product at the most competitive price. My proposal would be written with the intent of being selected for the job and earning my company new revenue.

The schema could teach me the elemental breakdown of a proposal and how to best distribute information. An interesting point I learned in class was that many proposals talk about all the indirect benefits of their project rather than the actual project itself. (i.e. all the town benefits from redoing the roads in the center of town.) To write the proposal, I would need to research both my project of interest and any benefits/impacts it can have on seemingly unrelated topics.

When writing, I used the schema as a checklist for all the essential parts of my cover letter. I felt the schema was appropriate in that it included all of the necessary components of a cover letter in the order they should appear. I am still in debate with my group about the exact structure of the ending, but I feel as though the schema is mostly where it needs to be. Being a culmination of examples and other cover letter models, there was not much room for variance to slip into our model. I believe that the documentation definitions are all accurate to their intended purposes and any changes would be a matter of ordering.

During the peer review, my partner’s model was very bare, which led me to further specify the amounts of information he needed in his letter. Creating a schema in a small group made the process quicker because there were fewer opinions and less controversy over how elements should be included. By having a relatively large influence on the schema compared to when in class, it made the writing process quicker because I was more familiar with the what and why aspects of each element.

Some minor points I believe could use some work are the header and ending paragraph; the header could include multiple lines for an address and an option to add a second address (home and school address). The last paragraph could use differentiation between the end of the paragraph and the invitation to further the hiring process. Otherwise, I believe our schema is mostly complete.

The genre for my group is cover letters. Our genre is typically preceded by job openings and listings, which often contain specific details of the job in question. Cover letters are an uptake of job listings in that they are a direct response to them- they are an attempt to obtain the job by demonstrating why the applicant is a good fit for the job. Cover letters are usually curtailed to a specific job opening and its particular responsibilities so they can be seen as the perfect uptake for all the duties entailed.

Other genres that precede the writing can often also be incorporated into the letter. Such genres can include conversations with the employer at a job fair, connections to the company through previous work, and references to advertisements. A genre that typically accompanies a cover letter regardless of any other factors is a resume. After resumes, typical genres that follow a cover letter would be a follow up email, phone call, or letter. The desired uptake from these situations would be a furthering in the hiring process, such as obtaining an interview, or even straight out being accepted for the job.

The desired uptake can be seen in our genre model as it culminates an array of experiences with cover letters. We viewed various professional cover letters and reached out to co-op advisors to determine what factors led to the highest success rate with cover letters. We then incorporated these traits into our model to make it as precise, readable, and balanced as possible when discussing why the applicant would be well suited to the job. Some other uptakes that had moderate influence on our model were grammar, sentence structure, and syntax. While our model could create a solid foundation for cover letters, it itself cannot determine if the language used is in line with what the reader wants- we cannot predict the personality or exact type of the reader (friendly HR staff or terse engineering supervisor) and what they value in a cover letter, example being personable vs. professional traits. Overall though, I believe our model does an acceptable job of up taking previous information and putting out a product that will create desired uptakes.

For Project 2, my group decided to work on cover letters for our genre. Cover letters typically interact with resumes, portfolios, and professional profiles such as LinkedIn; they are meant to either supplement or bolster the aforementioned genres by expressing the owner’s skills and desire to work somewhere. Cover letters are meant for relatively specific consumption but can be narrowed down to fit the particular needs of an individual application. For example, an engineering student applying for coop at a list of biotech companies could create a cover letter framework that contains 90% of the information about him and why he would be a good fit for the job. The remaining 10% would then be tailored to the specific needs of each company and position he was applying for.

Cover letters can be found in the hiring process of almost all major professional jobs. Those writing cover letters typically posses certain skill sets and drives that they want to make evident to those reading them, such as company supervisors and HR staff. Their goal is to promote and differentiate themselves when compared to other applicants in a more personable way than the straight facts of a resume.

The content of cover letters is usually formatted around the specific needs of the job in question; applicants will view the position and company background before tailoring their cover letter to fit the particular job. They will take into consideration what the hiring party values and then do their best to explain how they meet or exceed those exact criteria. They are effectively summing together all of their major traits and explaining how they could be put towards bettering the company.

The Spinuzzi reading helped me to think about how independent vs. overlapping cover letters are with other documents of similar genres. It will guide our research in deciphering which end of the spectrum, employer vs. employee, has more influence in shaping the format of cover letters.

The company I worked for dealt with HVAC controls. It was a medium-size consulting firm (roughly two dozen people). We undertook problems regarding the HVAC systems for commercial buildings. The company was split into several sections, the most prominent being engineering and sales. The sales section dealt with online sales and specific orders, while engineering (my section) dealt with creating the control systems for projects where they did not know what they needed. There would often be overlap between the engineering and sales departments when it came to pricing of parts needed or backtracking to find what parts where already in place or had been sold in the past. While there notable differences in the knowledge and approach to HVAC controls that both departments took, there was very clear communication between the two of them. All the acronyms and industry language was shared and there were no language barriers in that sense.

Coop was a very enlightening experience for me in terms of how important industry experience is in a field and how technical skills are only a small part of your ability to succeed in the workplace. I can very well see myself doing the same work after I graduate due to both my personal experiences and the state of the HVAC control industry. My boss was a role model for me in terms of how well rounded he was in managing the workplace and a key part of my decision to pursue a Masters in Engineering Management. The HVAC industry is also sorely in need of younger workers due to other upcoming areas of engineering attracting a large percentage of the new workforce generations. The combination of the industry state and the flexibility my masters will give me will most likely leave a lot of room for me to grow and hopefully rise through the ranks of the HVAC control industry.

I read through Dan Doherty’s annotated bibliography, which similar to mine, dealt with the problem of fossil fuel use and an increasing need for renewable energy sources. While my articles focused on transportation, Dan’s focused on infrastructure. A notable difference in our problem statements though was that he focused mostly on the solutions to creating greener solutions for cities, while I focused more on targeting the problems that needed to be addressed.

Looking at the XML markup for our annotations, we both used the same general structure of background, summary, and relevance for our 3 tags dividing up information. A notable difference between one tag-use though is summary; I used it once per annotation to encompass a major point of the article, whereas Dan used it several times to further break up key points in his articles. With this added degree of specificity, he also further categorized his summaries as general, interpretation, and approach, while mine were mostly general statements.

After viewing Dan’s article, I view my article as more concise but maybe too brief in areas. It brings back the question of balancing conciseness with adequate support for an argument. I do not believe one way is more correct than the other, but that instead it comes down to purpose and target audience of the annotations. One thing I would potentially change about my annotation though would be lengthening some summaries beyond a general statement to give the reader a more well-rounded idea about the articles.

This writing project was my first time using an XML markup instead of a normal word processor and the results were quite different. Overall I felt as though I spent more time focusing on the format of the processor than on the actual content of what I was doing. One of my biggest weaknesses is programming and it was hard for me to adjust to the format of the command window with a language I was unfamiliar with. Part of my problem was that I didn’t know what I didn’t know; once I had the general gist of how to structure my annotations, I was unsure whether or not I had correctly divided and marked them up in the processor.

In the end, I reverted back to laying out my annotations in a traditional style in Microsoft word and then cookie-cutting them to fit into the XML file with correct formatting.

Once I got past the struggle of learning XML, I noticed that it had prompted a new way of thinking and organizing thoughts. I typically think of literature and science as two different, if not polar opposite, fields. However, XML forced them together by taking a scientific and structured approach to literature. It broke the literature down into its most basic elements, which created both clarity and confusion. On one hand it identified every unique aspect of the annotations and created a framework/guideline for future ones. On the other hand though, it drew from our recent readings regarding genre and brought up questions regarding “what is this genre?”, “who says this is definitely how this genre is classified,?”, and “is this the only correct way to classify this element?”.

I feel as though science is a field of definites and literature is a field of subjectivity, and therefore there will be problems regarding crossing both of them over. I think that focusing more on the actual writing and practice of it would be more beneficial than using Oxygen and analyzing how to break the writing down.

In the current field of mechanical engineering, many endeavors are focused on taking existing technologies and making them more advanced and more efficient. Most of the modern equipment we use has been around for decades, if not centuries. What separates the current equipment from its older iterations is how well it can do its job and how little energy it can use. Examples of this include cars, whose mpg has increased drastically in the last half century; planes, which can now go much farther and faster, all while using less fuel; and trains, which can now transport more cargo using less energy. Major examples aside, even simple products such as bikes have changed as a whole to expand the different terrains they can handle and create a smoother ride. The case in point being that almost all the technology we need exists, but it is up to us to continually improve upon and enhance it.

The discipline I am currently studying is mechanical engineering and a common crossover between my studies and outside life can be found in transportation; it is one of the largest consumers of fossil fuels and is full of inefficiencies that are often distressing. After living in a city (Boston) for the last 2 years, one of the largest inefficiencies I have noticed is with the city buses. They all run on diesel and make frequent stops. Often times they are driven by impatient drivers who accelerate and break rapidly in order to catch breaks in traffic just to stay on schedule. This combination of factors leads to a tremendous amount of wasted energy.

One of the largest ways my discipline could help solve this problem would be to create large expansions in the hybrid and electric motor sectors for buses. The use of electric motors in buses alone could have a tremendous impact on the amount of gas the city uses in addition to the decrease in emissions and lingering exhaust fumes around stations. By their nature, electric motors generate almost no heat/wasted energy and are very efficient at accelerating. Equally important is the fact that they can also regenerate energy through braking, compared to typical brakes that just turn useful energy into heat. If such technology were to be implemented in the city’s major fuel consumers, including buses, garbage trucks, and EMS/Police, it could have a profound impact on the city’s reliance on fossil fuels and in turn make the city much greener.