Author: mizuno.s

I do not think very differently about writing now than I did at the beginning of the semester. I definitely feel more comfortable writing in XML, but I do not think that my process of work habits have changed. At the beginning, my process was reading and understanding the prompt, doing the necessary research for the project, and then writing it in XML according to the devised schema. I did this same thing at the end of the course too. I do think that genre can be useful in and out of academic settings. In academic settings it is necessary to know how to structure certain pieces of writing, like a lab report, to effectively convey and experiment or project. Right now it useful for good grades, but in the future it will be useful in professional settings. Outside of academic settings, genre can be important for how a writer interacts with his or her audience. This is especially true within different social circles; a person will address friends, family, and coworkers in different ways in order to maintain successful relationships between the different groups. I think that the projects have helped me be more informed about my field. If I ever write part of a research paper, it would be useful to know how to write an annotated bibliography. In professional settings, I would not be surprised if I participated in writing a feasibility report or a cover letter.

For project 2, developing a schema was absolutely worthwhile. My group wrote a feasibility report, which contains many clearly defined sections and elements. Having a schema helped to organize the report structurally, and it ensure that all the necessary considerations and details of a feasibility report were included. Writing in XML made me more focused on the content that needed to be included in each writing assignment. However, it could be constraining at times, and I think that my writing style became more disjointed than it usually is when I write with a word processor. The mix of software and applications was not especially difficult to use. I just think that there was an initial challenge because I have only ever written using word processors. It was strange to see my writing so explicitly broken down into different pieces.

I think that my favorite project was the second one, where my team wrote a feasibility report. Although I think that this was one of the more difficult projects, I think that it will be the most useful for me in the future. One of my least favorite readings was Miller’s Genre as Social Action. It was fairly long, and as an engineer, most of it went over my head. One of my favorite activities was the discussion of uptake with the video and articles about Ted Cruz not explicitly endorsing Trump. This was interesting because we were using a concept taught in class and applying it to a current situation.

After this course, I will think more about the rhetorical situation when I am writing. Although my other courses and work environments are within engineering, writing will still be involved. Whether I am writing a lab report or an email to a coworker, I need to be aware of my audience and constraints so that I can effectively communicate my ideas.

Our cover letter group made changes to the original schema for writing project 3. In the introduction paragraph, we added multiple reasons, where before there was only an option for one. We added an optional URL that could direct the audience to some additional information like a LinkedIn profile, a portfolio website, or a code repository. We made a change that allowed for text in the background paragraphs outside of “experience” elements. We made the “proposition” element in the introduction paragraph optional. We added an “interest” element in the background paragraph. We made an optional space or image file at the end of the cover letter to allow for an electronic signature.

Overall, I think that these were good changes. Allowing the applicant to have multiple reasons for applying for a position helps the audience have a better understanding of the applicant’s motives and interests. The optional URL makes it easier for the audience to quickly access additional information about the applicant. This is especially helpful because many companies request portfolio submissions. It is also common within computer engineering and computer science for companies to request applicants’ repositories of previous project work. Allowing applicants to write outside of the strictly defined elements in the background paragraph section helps their writing flow better. Often writing can be disjointed when a person is trying to fit content into different confined elements. I personally am ambivalent about making the “proposition” element in the introduction paragraph optional. While I see how making that element mandatory could cause repetitive writing, the introduction of a cover letter is usually short, and I do not think that applicants would write so much that they would include redundant information. In my opinion, the introduction of a cover letter should be concise, while the background information should make up the bulk of the writing. I agree with the decision to add an “interest” element because this could help an applicant relate to the company on a more personal level. This could make an applicant stand out to the audience. I do not think that adding an electronic signature is necessary, but that element is optional so it will not negatively affect my writing.

For writing project 3, I wrote a cover letter. I used the schema to structure the cover letter, and the different element and attribute types guided me on what to include. The schema helped me write about my past work and school experiences, and it helped me convey why I thought I was a good fit for a company. The schema was appropriate for my rhetorical situation. The situation in which you would write a cover letter is when you are responding to a job posting, and you submit a cover letter with a resume. The cover letter helps highlight certain parts of a resume and convey some skills that may not necessarily be included on a resume. I do not think that the schema was too constraining.  For the sections that included experience, I was free to write what I wanted while including relevant information like programs I know and skills I have. The schema helped me write the introduction and closing paragraphs. This was helpful because it guided my response to how the company and work mattered to me. When I read my peer’s work, he used the schema very similarly to the way I used it, so this did not cause me to think differently about the schema. Receiving feedback from my peer on my work did not change the way I looked at the schema either.

Overall, I think that the schema developed for the cover letter was very effective for writing a complete cover letter. However, I think that I would add a “social” element in the experience section. After reading my peer reviewer’s comments, I realized that I did not emphasize soft skills enough. I think that adding a “social” element would remind writers to include information about their ability to work in teams, communicate well with others, etc. I think that this schema was more flexible than the schema I wrote with my group, which was a feasibility report.

For writing project 2, my group chose a feasibility report as our genre. The schema was very useful for my writing process. Our schema was very structured, and it contained all of the necessary elements of a feasibility report. I think that the schema helped me write the feasibility report because it reminded me what types of information I needed to include. Since a feasibility report is very factual and technical, I did not feel like the structured schema limited my writing (unlike the annotated bibliography in project 1). I do not think that writing in xml was difficult for this project since all of my writing clearly fit into the different elements of the schema. However, I think it can be difficult for less technical writing when I want my ideas and sentences to be less fragmented and simple. The most helpful reading for project 2 was Seth’s feasibility report that he had written in a previous class. It was useful because it was short enough to identify its different elements, but complex enough to get a general understanding of a feasibility report. The group work was helpful for understanding writing since we all had to research the genre and combine our ideas into a broader, more coherent schema. I think that our group developed a comprehensive schema, and I think that I was able to successfully use it to create a complete feasibility report. I think that some of the research for my individual project (the feasibility of one company’s solar roadway panels) was difficult because there were not too many articles about the technical features of the panels.

I think that the cover letter genre is interesting. In the future, this would be useful to me when applying for coops or jobs. This job application process would be a rhetorical situation where creating a cover letter would be an appropriate response. The situation would be responding to a job posting. The audience would be the company’s hiring manager and possibly other engineers. I would want the cover letter to effectively convey my desire and qualifications to work with a company so that they would be interested in giving me an interview.

The schema looks like it offers flexibility to highlight the writer’s qualifications. There is an introduction where the writer can explain why he or she is writing the cover letter. A background section lets the writer detail important experiences that a resume may not clearly show. Finally there is a closing paragraph where the writer can explain why he or she is a good fit for the company and detail what next steps can be taken. The style is unique to each student, but the tone is always professional. All of the examples devote most of the cover letter to relevant work experience. To compose my own version, I will need to look online for more cover letter examples.

I used the schema to create the basic structure of my feasibility report. I started by looking at my group’s documentation page and the elements in our schema to write the table of contents. This outlined the rest of my feasibility report. The schema was appropriate for our rhetorical situation. The elements we included clearly guided the reader through the background of our selected projects, included supporting evidence for how it would or would not be feasible, and allowed the writer to make a judgment of feasibility. Overall I did not feel that our schema was constraining. However, I think it would be helpful if writing could be included in page elements to help transitions between sub elements. Also it could be useful to include paragraph elements. My peer review partner’s composition looked somewhat similar to mine. However, it was missing elements like a report, risk analysis, and design. These elements, especially risk analysis are integral to a feasibility report, but I am sure they will be added once my partner’s draft is finalized. I found that using this schema that was developed as a small group was different from using the class-developed schema for annotated bibliographies. As a small group, we had more individual input, and we could generate a more specialized schema. Also, we had more time to individually research our genre.

My team’s genre for project 2 is a feasibility report. Typically a project proposal precedes this genre. A project proposal lays out an idea or project to be accomplished by giving a detailed and logical description of the steps to be taken to solve a specific problem. However, a proposal will not automatically be accepted. It needs to be well-researched and possible. This is where a feasibility report interacts with the proposal. A feasibility report will assess how reasonable and possible it will be to execute what is in a proposed idea or project. Because of this, the two genres closely relate to each other. A feasibility report delves further into the claims made in a proposal. More research will be conducted to decide if the ideas in the proposal are feasible. Additionally factors like expenses, timelines, and risks are considered.

After a feasibility study is produced and read, the group or organization that commissioned it decides on its next steps. If the feasibility study declares an idea or project to be too risky, the group would have to reconsider its original ideas. This could lead to creating a new project proposal. On the other hand, a feasibility study could approve of the ideas generated in a project proposal, and the commissioning group could go ahead with their project. This would lead to countless other genres being used in order to begin work on the project. In either case, the desired uptake of a feasibility report is the production of a logical and unbiased evaluation of a group’s idea, which can then guide the group’s next actions. My team’s genre model reflects this with the elements that we included; we have an element for an executive summary, preliminary requirements analysis, feasibility, success criteria, design, cost, risk analysis, financial planning, and a conclusion.

Our team chose a feasibility report as a genre to study, model, and produce for writing project 2. Our initial access to a sample was through our group member Seth who had written a feasibility report for a previous class. After reading and analyzing his report, we looked for other example reports on the internet. We found about five other examples of feasibility reports produced by various universities and companies that appeared to be fitting examples off of which to base our studies. Documents published by a university or reputable company will generally be credible and of good value. Some of these sources gave guidelines and templates for writing feasibility reports. These aided our understanding of the actual samples we found.

In order to study the situation that a feasibility report addresses, we mostly referred to Seth, who had created a report before, along with the previously collected samples. Through studying samples, we found that feasibility reports are generally published or produced by a company or university attempting to validate or invalidate the need for the proposed product or action. These documents can be produced and read internally within an organization to decide whether a project is feasible, or they can be read by an outside party who will decide for themselves whether or not the idea or product will work. It was possible for us to access the scene of actually writing one of these reports by interviewing our group member Seth. We also were able to contact one of Seth’s professors about his experience reading these reports. In this way, we came to understand how different viewpoints interact with the same genre.

From our studies, we were able to identify the structural, rhetorical, and lexical features of a feasibility report. Structurally, most reports were written in a similar format. They contained an overall abstract or summary of what topic the paper was examining. The paper then moved into the requirements of the paper’s topic followed by the actual examination of the feasibility of different areas of the topic. Some of these areas included economic, environmental, and technical feasibility. These feasibility sections were then followed by a conclusion which provided the author’s opinion on whether or not the project would be viable given the examined factors. Rhetorically, the reports strongly appealed to logos as well as a more mild appeal to ethos. The reports contained many facts, data, and charts which provided logical arguments to the reader as to why the project may or may not be feasible. The appeal to ethos was provided by the company or university’s reputation. A highly regarded university producing a paper allows the reader to believe that the information is credible. The lexical features of the reports generally contained a lot of discipline specific language with declarative sentences that provided the facts found through the research done for the report.

We found that feasibility reports reveal quite a bit about the rhetorical situation that they address. The reports are always logic based. They do not deal with emotional responses to a situation, but rather provide factual information by which a logical decision can be made. It shows that in general, most decisions being made in engineering fields are made because of factual evidence pointing to the correct solution. Engineer’s emotions or personal preferences will usually not overpower facts laid out showing a better path to the solution.

The elements and attributes that we generated were all produced directly from the analysis that we did. The overall structure of the report provided a large number of elements for us. For example, each major section of the report was designated as its own element, such as the table of contents, executive summary, and feasibility sections. There were also attributes that we added based on topics discussed in each section. In the feasibility elements, there were attributes available to accurately describe the topic of feasibility such as technical, economic, and environmental feasibility. Some of the decisions that we had to make regarding our analysis were whether certain elements or attributes could be optional or required. Overall we included the same elements that were in our samples. However, we omitted a detailed project schedule since our time is limited.

Our group noticed that there was a larger variance in included sections. We believed that this is dictated by many factors, including the sources of funding, the actual medium of the project (physical or digital), and the potential impacts. We designed our genre model to allow for a flexibility with what to include and what to leave out, enabling our genre model to cover studies about building a dam, and building a web app equally well. For the sake of our projects and condensing the format slightly, we included less in depth versions of timelines and financial reports.

Update: After the first draft of P2, our group came to a few realizations. Firstly, while our schema allowed for carefully outlined and segmented ideas, we were missing the ability to create titles in certain places. This occurred primarily under success criteria and the preliminary requirements analysis. We also felt constrained without having the ability to include multiple requirements sections under the success criteria page. These two changes will allow us to better express our different ideas and bolden the section headings, increasing the readability of our document. We had to create an image account for our group to upload design images. This way we could refrain from cluttering the class repository with the documentation images. Lastly we added a global <ref> element that can be included on any page. This element allows us to include outside sources and cite them. This is not something we brainstormed during the development phase, but it proved necessary once we started our personal projects.

For the second project, my group chose feasibility reports for our genre. This genre can interact with other texts such as technical reports, data sets, published studies, and journal articles. A feasibility report uses these types of texts in order to have factual support for a proposed solution. These texts are not confined to one space; they can be produced and used internally in an organization or field, and they can also be available publicly. For example, a technical report could be produced for a product in a smartphone company. This could be passed around to engineers who work in the company to help their development of the product. Later some of the technical specifications in this report could be released to the general public to advertise the product. Another example could be a psychology study that a university runs. At first this would be internal to the university. However, this could later become more widespread after it is published in a journal for a larger community to read.

The genre of a feasibility report usually is not meant for the wide consumption that the assemblages it interacts with can have. The people who compose this genre can be in a variety of disciplines. Despite this, they share the same goal – to convince another group or organization of the feasibility of a proposed solution to some problem. The group or organization that commissioned the feasibility report would be the one who reads it. They would then use the report to decide their next actions going forward. For example, a feasibility report could be commissioned by a computer company that wants to update their operating system. After reading the study that was researched and produced by another group of engineers, the company would consider what was in the report. If the study found the updates possible and beneficial, the company would go ahead with those updates. However if the study found problems with the updates, the company could take this information and try to find another solution.

I worked at Corindus Vascular Robotics for my co-op. It is a small to medium sized company with about 80 people. There is a huge variety of disciplines. The engineering department includes manufacturing engineers, software engineers, electrical engineers, and mechanical engineers. Outside of this, there are people who work in shipping, finance, IT, and marketing. The company has built a robot that aids surgeons in percutaneous coronary intervention (PCI) procedures. As part of the software team, I dealt with coding the robot. Working with the code involved programming new capabilities, fixing bugs, and creating supplemental testing applications. Work within the software team was mostly mono-disciplinary. However, we sometime worked with the electrical team when there were issues between our code and the hardware. For example, we had a bug where the system would throw an error when certain motors crossed voltage regions. My team also worked with manufacturing when we developed tools for them to test the robotic system. These were some inter-disciplinary experiences that I had.

For the most part, I focused on projects within the software team with little interaction with the other disciplines. Obviously this was very mono-disciplinary. However as mentioned in the previous paragraph, there were times when my work was inter-disciplinary. Outside of the research and development lab where I worked, a lot of the company was multi-disciplinary; manufacturing engineers, electrical engineers, software engineers, and mechanical engineers all worked on building the same robot, but they mostly did not integrate. Each team mainly focused on problems within their disciplines, and used those collectively to design and improve the robotic system.

After graduation, I could see myself doing this type of work. I liked the research and development environment I was in. There was always work to do, and there were a variety of problems to solve. I had the freedom to come up with my own solutions, and my work and my code directly contributed to the company’s robotic system.

I read Chris Murphy’s annotated bibliography that dealt with fossil fuels and sustainability. Specifically, he looks at fuel efficient vehicles that would reduce the amount of fossil fuels being used. In Chris’ problem statement, he gives a brief background of the issue of sustainability in Boston, and he follows that by saying that his discipline of mechanical engineering can help solve that problem. This structure is similar to my bibliography. However, he uses his discipline to look a very specific topic of combustion engines and electric motors, while I focus more on general skill sets used in my discipline.

Overall the markups look similar. Both of us use APA style for our citations. Both markups also contain a similar structure since everyone in our class wrote these using the same general schema. In Chris’ annotated bibliography, he uses the same structure of background type source, summary type general, and relevance type application except for one annotation (where he uses background type author). In my annotations, the types I use are more varied, and I have different combinations of them. Sometimes I have two types for an element, like a value statement and application for relevance. After comparing these bibliographies, I do not view my own differently. Neither piece is better than the other, they just have different content and styles.

Writing in XML markup definitely changed my writing process. Whenever I write, I follow the prompt and make sure to respond to all parts of it. However, my writing seems more natural when I am not using XML. I think that this is because the markup schema has a rigid structure. All of the elements are explicitly blocked out. On one hand this is good because it reminds you exactly what you need to include in the writing project. On the other hand, it makes my writing feel more disjointed.

For my sources, the schema that we created in class seemed somewhat awkward. In all of the examples that we saw, each source was an academic book or article dedicated only to the research topic. Some of my sources were different because I was researching ways that electrical engineering skills could be applied realistically to solve different food crises. Some articles gave brief overviews of different companies’ products that solved these issues. Since the articles were not research papers, there were obviously no experiments performed whose “approach” I could describe. Also, I could not point to these articles and say that they represented some kind of foundational text like I could with a published paper in a journal.

From Genre as Social Action, genre represents action with a situation and motive. In this project’s annotated bibliographies, the situation is finding relevant sources to a problem our discipline could solve. The motive is to show these sources and explain why they are valuable to us. We accomplished this by writing the annotated bibliography according the schema. In this, we included a problem statement that explained how our discipline could solve a unique problem. In the annotations of sources, we gave some background on the source we used to establish credibility of the author or source. We also gave some summary of the source’s content, and we later explained its relevance.

With the wide range of uses for electricity and electromagnetism, there comes an enormous range of problems that electrical engineers can engage with. Electrical engineering is a broad field that can cover anything from artificial intelligence, to cutting edge healthcare solutions, to personal electronics, and the field’s influence can be seen everywhere. It is difficult to imagine life without telecommunications, Alexander Graham Bell, and his telephone. Another important field is computers, with major advances made by electrical engineers William Hewlett and David Packard. On a more local level, electrical engineers here at Northeastern are working on developing a humanoid robot with NASA.

There are a variety of ways for electrical engineers to communicate and share new ideas and knowledge. With the internet, many engineers have their personal blogs where they detail the projects they have worked on. There are also websites that have databases filled with project ideas and step by step tutorials. In a more academic setting, IEEE (Institute of Electrical and Electronics Engineers), publishes hundreds of journals and magazines covering topics in electrical engineering. Additionally, IEEE offers societies, communities, conferences, and events for members. The organization’s tagline is “advancing technology for humanity,” which seems to be a common goal for all people in this discipline.

Issues with the production and distribution of agriculture can be solved by this discipline. Different startups right here in Boston and Cambridge are using electrical and computer engineering to solve problems with the physical growing of produce. One company Grove Labs developed a product that combines a fish tank and a garden to create an ecosystem that can grow food indoors. LEDs are used to simulate the sun, and Wi-Fi and sensors monitor the system. Another company Freight Farms has their own product Leafy Green Machines. These machines are actually shipping containers turned into miniature controlled farms. Similar to the Grove Labs product, LEDs have been programmed to provide plants with light. The shipping containers also contain an extensive climate control system that uses sensors and feedback to adjust the temperature, humidity, and carbon dioxide levels. There is also a watering system where the user can adjust nutrient levels.