Author: salas.m

Over the course of this semester, I don’t think that the way I write has changed much, but the way I approach an assignment definitely has. Using XML and defining a genre model before each project forced me to think about how I generally wanted to structure and organize whatever it is that I am writing. It was tedious to have to come up with conventions of each genre and define the purposes and uses of each “element” in the genre, but it made me approach every project as a problem with a very formulaic answer that I had to put together. I liked thinking of it that way because it broke down every piece of writing into a bunch of much smaller tasks and elements. This made writing a lot less opened ended, and thus a lot less of a chore.

I was pretty resistant to using XML while I was writing for the first part of the semester, and rather than writing in oxygen, I would write out a draft of my project in notepad and then copy and paste the relevant parts into the XML document. My genre analysis was still relevant while I was doing this, but it made it so that I wasn’t exactly addressing each element in the genre model. For project three I really tried to write to the genre model. It was nice because once the genre model was together, I could skip around and fill in elements with the information that I wanted to include. I didn’t have to write in order and it was much easier to step away from my writing and come back to it later because I didn’t have to remember my train of thought from before. It was kind of a pain to put together a genre model that would work for everyone during project 2, but having the genre model for project three was definitely worthwhile.

My only complaint was that writing in XML was a little clumsy. It was hard to keep things formatted and make sure my writing flowed. It would have probably made it easier if I could have made changes to the XML and then review my changes on a formatted version of it right away. Learning how to work with oxygen and GitHub was also kind of a necessary evil. I know most people don’t use GitHub that way, so it’s probably not super relevant knowledge for the future, but I was happy not to have to work through a terminal, because I didn’t want to worry about learning that this summer too. It wasn’t especially difficult to use GitHub or Oxygen, but it would have made it a lot easier to know how to use them well I think.

Seeing the connection between projects two and three was actually kind of cool. It was tedious but still informative to have to put together a genre model in project two, but it was interesting to have to write to a different genre model (that I didn’t make up) in project 3. I felt like project two was done with a real purpose because we used the genre models in project three. I also got to understand how helpful having a genre model to write to could be while writing project 3. While I really like the flexibility in choosing our own genres, I wish I had written a genre for project three that a schema would have been more valuable to have. Proposals are a really wide genre and the schema was helpful, but still had to be very open ended within each of the elements. So while I still saw the value in having the genre model, a proposal probably wouldn’t have been that much harder to write without the genre model.

I’ve learned about rhetorical analysis and genre in a bunch of different english classes before, but having to define it so strictly for each project in this class made me realize the benefit of analyzing a rhetorical situation as part of the writing process. I think it would benefit me a lot to consider the conventions of any genre that I communicate through a little more thoroughly than I did before. With luck, I won’t be writing that much in my future, most of anything I write will be to communicate directly with someone. So it’s going to be really important for me to consider what the uptake is for anyone reading what I write and that is worth putting some extra effort into thinking about.

The changes made to our genre model during project 3 were mostly changes that we thought about when putting together our original genre model. Some of them I agree with and some we left out for particular reasons. Some people definitely ran into issues where the schema was constricting, and while I’m sure there are cases where the schema was wrongly constricting, we made it very strict to keep the letters focused and well organized. Especially among the examples of “good” engineering cover letters, there was almost no variation in the order things were included and there was very little filler text to make transitions easier. We probably could have helped this make more sense if we improved our documentation of each of the elements.

We found that it was excessive to put more than a line or two as a “reason” for applying in your introductory paragraph. Realistically, most employers are going to care more about what you can bring to the company so emphasis should be on the background paragraphs. The proposition element was also really important to keep because it’s like a summary of the whole cover letter in one sentence. It should be a very clear statement of what your intentions are with the letter. I know that during the presentations of project three, someone had almost the same definition as their take of the “compatibility” element in the conclusion, and I agree with them, but our intention was for the conclusion to be a reiteration of the letter and not the first time you clearly state your purpose for the letter.

I really like the idea they had to have an optional URL element. We didn’t really consider the unique circumstances that go with electronic copies of cover letters. As long as a URL isn’t bulky and clumsy in the middle of a cover letter, it would probably be really cool (as a hiring manager) to be able to be reading through someones cover letter and application and have a handy hyperlink I can click that will show me their portfolio.

We also talked about adding a space for a hand written signature. I completely agree that a cover letter should have a real signature on it, but we decided against adding a mandatory space because it would just achieve the same thing as adding 3-4 line break elements.

Overall, this schema was fairly easy to follow and work with. As expected, there were a few details that we encountered along the way that made the schema somewhat difficult to use. Many issues that we had rooted from lack of documentation or redundancies in the element definitions. Under the approach section, we found that the definitions for “execution” and “action” were so similar that we thought it might streamline the mark up to just eliminate these two attributes and leave the text under the “approach” heading. There were also a few places where it was difficult to identify what sub-elements or attributes were mandatory or optional. We noticed this when we were trying to write in our “scope” under the “purpose” section. We felt that “who” “what” and “when” should have been mandatory attributes (and the rest optional) in order to give an informative scope of the proposal. It also would help clearly define what a scope is and what information it should include.  

A minor bug we encountered was that the template model required a type=”___” attribute following approach and feasibility. However, when we defined these sections accordingly, it returned an invalid statement. As we discovered through the examples from the original group, approach and feasibility do not have a type=”__” attributes, but are instead defined within the paragraph itself as subelement. The change to the schema should reflect this difference in how the sections are defined.

One element that could potentially be added to the schema would be a global reference element. There is already a bibliography, so it would be useful to denote where each reference is used within the proposal. The <ref> would have an “author” attribute which would contain the author of the source in the bibliography it is that you are referencing. Another addition to the schema could be a “legal” and “other” subelement in the feasibility section in addition to the economic, social, and environmental elements. Therefore, the user of the schema would not just be limited to the three feasibility subelements already defined.

When writing my first draft of this project, I used the major titles in the schema mainly as a checklist of things that I needed to include in my public initiative proposal. I gathered all the information that I potentially wanted to use and made a big bullet list of things that I could use to support my argument. From there it was easy to peg where all my points would best fit into the schema. It was interesting building a writing assignment around the existing schema rather than developing both a piece of writing and a schema simultaneously. I kind of kept bullet points under each of the headers and filled in more with details and sentences until I felt like I had a sufficient argument/content to satisfy the requirements of each section. However, there were definitely drawbacks to this method. I really think I put way too much information and lost focus; my plan is to go back and trim everything that is extraneous and nail down a focus for the proposal. I got distracted using the schema in my brainstorming basically. However, having the schema in front of me helped me to figure out what kind of information I needed.

The schema definitely fit the proposed rhetorical situation, however it was next to impossible to come up with a rhetorical situation that made sense for me to explore. I guess anyone could be involved in proposing ideas for a city development project, but I can’t think of any real situations in which a mechanical engineer would be involved. I have no education or background in city/land development, construction, or addressing social issues. So this was a little bit of stretch from the project prompt.

From peer reviewing with my group, I noticed that there were a few sub elements and attributes that I didn’t use correctly or didn’t realize were in the markup. Not that this would change too much about my proposal, but it would have been helpful in constraining my writing enough to have kept me more on track.

Aside from these few confusions, the schema was very well set up and easy to use. I think my whole group could have benefitted from additional documentation of all the elements and organization of the markup, but this was only an issue in a few places (like the purpose section). I couldn’t find any definitions for attributes to elements; this could have been helpful in the scope and introduction sections as well.

Overall, it felt a little more constricting using someone else’s schema because I was assuming the whole time that the schema had to be completely correct, so I had to work my writing around the schema. In project two this wasn’t the case because while I was writing my first draft for my cover letter, we were still making changes to the mark up, so if I noticed something that made writing our cover letters difficult, we could just adjust the schema instead of adjusting what we were writing.

Primarily, I appreciated having the schema for my individual writing for project 2 because it kept me focused and kept my whatever I was writing more relevant to my topic. I didn’t have a place to include tangential information, so I had less of it. That is something that I always struggle with when I write letters or assignments. I relied heavily on the schema and it kept me from having to think too hard about what I wanted to include in my letter and how I wanted it to flow; that work was already done for me. So all I had to focus on was what content I wanted to include and how my language was going to flow.

My only gripe with writing in XML is the lack of formatting. I understand why it is the way that it is, but its difficult to write in Oxygen and then all your text goes off the page because every line is so long. So I’m constantly hitting Ctrl+Shift+P and that got kind of annoying. I ended up making all my edits in my second draft in a word doc and then copying and pasting it into my XML. This is what I would have done for the first draft too, except I wanted to have the schema laid out in front of me to make sure that I was utilizing it.

Our genre was difficult to nail down to a specific format. It was evident through our research that a lot of people felt very strongly about how cover letters should and shouldn’t be. There were a lot of cases where reputable resources disagreed with something about how a cover letter should be. We tried to rely most heavily on feedback from our co-op advisors because we trust their experience the most. All the readings that they trusted and used in their classes and all the feedback they gave us from asking them questions was particularly helpful in nailing down what we wanted our schema to be.

I think that discussing things in our group made me realize just how different people can understand a certain piece of writing. I thought I knew most of the conventions of a cover letter before this. I thought most of our research was going to be focused on smaller details of it that make the difference between a good and a bad cover letter. There was one day when we split up our resources and each did our own research and talked about it the next day. I realized that what I understood from our research was completely different than what my team understood from our research. All our examples were relatively similar, but we took completely different things from them. It forced me think in a way that I wouldn’t normally in order to understand where my group mates were coming from.

I think our schema came out quite well. I think that we left it vague enough that it is not restrictive, but specific enough that it isn’t confusing. It was difficult, again, agreeing between our group because when we put together our schema the first time, I thought we were all on the same page. Then when we all made our first drafts, we didn’t really implement the schema in the same way as each other, so obviously we weren’t on the same page. It was difficult hashing out these differences, but I think it made our schema more understandable to a third party. If I could, I would have tried to find a way to add like a ‘preparation’ section to our schema. This wouldn’t be anything for the cover letter, but more of a way for the writer to organize their thoughts and goals for the cover letter. I think it is important for any writer to specify key requirements or values called out in a job listing that they are writing a cover letter in response to. I don’t know what XML’s limitations are, but it would be cool if we could have the reader call out skills from the job listing and then require at least half those skills to be repeated in the “experience” paragraphs in the cover letter.

Truthfully, I think that an Edutainment blog would be the most fun and interesting piece of writing to develop for project 3. That being said, I haven’t been able to think of a topic over the last few days that I think I know well enough to write a really cool edutainment blog about. If I get inspired in the next day or two though, I might try to explore that idea a little more.

This being said, a lot of what drove me to go to school for engineering was the thought that I’d be able to make a solid impact in my community. My hope was that somehow my community would be able to benefit from my education since I have so many people from my community to thank for helping me to receive my education. Right now, Worcester is overhauling all the ugly parts of town and putting a lot of money and effort into community development. There are a lot of requests for proposals (RFPs) on the city website that have to do with neighborhood development, repairs of old broken structures, renovations to schools, etc. It’s really cool to see the progress that is being made, and think about how much the city has changed in my memory. I looked through a bunch of RFPs,but there were a lot of them that were engineering related that were just way over my head still, but there was one called the “Community Development Block Grant Program” (CDBG Program) which asks for any proposals for how to spend a $3.8 million annual federal grant the city receives. They have some very vague guidelines for what they want to accomplish (minimize slums, meet an urgent city need, serve low- moderate income persons, etc.) and the rest is fairly open.

It has always bothered my how much space in Worcester is just taken up by old factory buildings and ugly junk yards. It’s mostly just a waste of space and makes the city look a lot more run down and poor than it actually is. I cross referenced this with some of the (very) many RFPs for city development in Boston to see what kind of stuff might fit into this CDBG RFP and got a lot of ideas for things people might want to do with empty lots in developing neighborhoods. Boston has really tight guidelines for what they are willing to build and what proposals they won’t even look at. I hope to use these Boston proposals to help me develop a public initiative proposal in response to the Worcester CDBG request.

I also think that this kind of proposal will fit in well with the schema that group 3 put together during project 2. They focused their proposal format on city development, since those were the best examples they found. I also think that their schema is very straight forward considering that proposals need to flow well and the format is fairly predictable. My only confusion, now that I’ve looked at examples of how they have used their schema, is what parts of the schema are required and whats optional? It seems like some of the examples leave empty elements in the schema, and I’m not sure that is just because it’s not totally finished or if the empty elements just aren’t required.

To develop this for project 3, I’d need to decide on what kind of actual development I’d like to see in these ‘wasted spaces’ in Worcester, be it a park, community center, commercial building, etc. It also might help to pick a particular space that could be redeveloped. This whole time I’ve been brainstorming I’ve been picturing some old abandoned factories that are in the residential areas near Union Station and WPI (downtown Worcester) but I’m sure there are other neighborhoods that I’m sure could use similar development that might work better for this project.

I’m concerned about not being able to either (a) do the proposal justice and actually put a good amount of content in it, or (b) spending way too much time and making a project that is way longer than it should be for project 3.

It was surprisingly helpful to have our schema to write my first draft cover letter. I didn’t have to think too much about where I wanted to include certain information and I didn’t feel the need to go back and reference a bunch of other examples while I was writing my cover letter. There was already a place to put everything that I wanted to say in it. It also was helpful to make sure that I didn’t miss any important points in my cover letter because i knew that certain elements were necessary; and on top of that it was necessary to put them in a certain place in the cover letter.

I did find that the schema was appropriate for my rhetorical situation. I realized that it was actually using optional elements that I didn’t think that I would need. That being said, I think that we left our scheme general enough to be able to be applied to many different situations.

I never felt like the schema was constraining. I actually felt the opposite, the schema reminded me that I needed certain elements that I may have otherwise skipped or been to lazy to think of something good to say in that place. I especially felt that the schema was helpful in putting together my introductory paragraph. I still think my introduction could use a lot of work in order to feel more natural and focused/informative, but having the schema helped me to generate what I wanted to communicate in that paragraph at least.

When reviewing my partners composition, I realized that we both understood the “experience” elements to mean different things. In each of my “experience” elements I basically filled in a paragraph’s worth of information recounting one relevant experience. So I only needed 2 or 3 different “experience” tags. He used “experience” in order to denote every sentence where he mentioned a skill or something he was exposed to. It made it so that I filled in a lot more content into my middle paragraphs than he did. As in, I listed fewer “experiences” with more detailed descriptions and he listed more “experiences” with less details about each one. This is probably something that we should discuss and nail down how we intend for it to be.

I think so far our scheme is quite effective, and aside from a couple of revisions we have already made to our definitions, that what we have is working pretty well. I think that we need to add sub elements to our “experience” elements in order to better define what needs to be included in one of these paragraphs. It might be helpful to break experiences down in “skills,” “certifications”, “languages”, etc. and then leave an open list that the writer can fill in with whatever they want, but at least having suggested sub elements would prompt the type of information that you want to include in the paragraph.

I can’t imagine trying to make up this schema with any more people. It was difficult enough to be able to hash out what we wanted to do in our schema with just 4 people. It makes me concerned that our schema might be less easy and understandable to anyone else that is less familiar with the schema. I think it would be worth re-formatting our documentation to represent what is a sub element or attribute of what so that our glossary is a little bit better visual representation of what we want our schema to be. I think it would make it easier to look up what a particular tag is if it weren’t just in a list of definitions.

Our group accessed samples mainly via online hiring sites and NUCareers. For variety, we analyzed 12 different samples from varying disciplines in order to create an overarching or “average” template. The samples we selected were relevant to us in that they either dealt with job listings within our disciplines or they were in response to openings for a co-op position. To broaden our scope, we also obtained general cover letter advice from co-op advisors in the form of verbal or written tips, as well as formal documentation describing cover letter production.

We began studying the situation by discussing our previous co-ops and interview experiences. One of us also met in person with a co-op advisor to discuss their experiences with the dos and don’ts of cover letters. We decided this would be the best course of action to take because personal experiences are much more valuable than online samples and models. Furthermore, we also wanted perspective from readers of cover letters rather than just writers. We entered the scene by broadly reviewing cover letters from an array of jobs and disciplines. We then compared the similarities and differences between the cover letters from those positions. While we saw many variations in content, we found that most cover letters have many similarities in structure regardless of the job they are in response to.

As a whole, our genre followed a very predictable and repetitive pattern. The basic outline of cover letters was a greeting followed by three major sections addressing purpose for applying, applicant’s background, and why applicant would be a good fit (in that order), followed by a cordial closing. This is similar to a business letter format. Also similar to a business letter, cover letters tend to have reasonably simple and professional sentences that are word efficient. This format along with the fact that cover letters were less than a page made for a concise and well flowing document. The main purposes of a cover letter is to take the sterile facts and numbers found on a resume and convert them into a flowing and easy to read form that ties everything together.

Focusing on the more technical disciplines, such as engineering and computer science, we noticed that cover letters are more concise and filled with quantifiable information; though that does not mean that they were necessarily shorter.  For example, a cover letter for a social work position included information about the writer’s passions as opposed to simply talking about their qualifications for the position.  However, our engineering co-op advisors emphasized that a cover letter is used for a hiring manager to get to know the applicant and how his goals align with the job along with his qualifications. This provides some insight into the engineering discipline, and shows that it is not simply concerned with factual, quantifiable information when making hiring decisions. This also means that the cover letter is an uptake of both the job description and also the attached resume.

In our research of various cover letters we found that the rhetorical situation strongly affected the composition and elements of the cover letter. Cover letters would be structured differently depending on which discipline it was associated with, or simply if it was in the form of an email rather than an independent document. This discipline-specific format was reinforced by the information we received from our co-op advisors.  Due to these large differences, we decided to base our genre model to a rhetorical situation most useful to us; our genre model is based on a cover letter written for a job in the engineering discipline, by an applicant with previous work experience, and with the intent to be sent as an individual document preceding the resume. We left the elements and attributes generally stated, and added some optional attributes that would allow for anyone of any discipline to fill their cover letter with content important for their field.

We used the example resumes we analyzed to decide what attributes were absolutely necessary in all cover letters, and which ones would only sometimes be relevant. We had to acknowledge that there is still a good amount of variance in rhetorical situations within even our own discipline. This simply meant that we included some optional elements that would be nice to have in some situations, such as a sentence about how the applicant learned of the opening, or what connection he or she may have.

One aspect we did not include in our model was some sort of indicator of whether or not the cover letter has information that too closely resembles the resume it precedes. We learned from our analysis that the cover letter should not be a reiteration of the resume, though that is challenging to indicate in an xml file, especially if we do not have a defined model for a resume.  

Update: After going through the peer review process, we decided on several changes regarding the format of our schema. One of these changes included general writing formatting, such as spacing and line breaks. We added room for 2 lines in the address section so it would be displayed like a normal address (street on the first line and city/state/zip on the next). We also created an option for a line break within the last paragraph between the compatibility and next step elements. This option could be used at the writer’s discretion depending on the flow of their letter. Furthermore, we added acknowledgement as an optional sub-element under closing statement element since we noticed a thank you statement was fairly common in many of the cover letters we read.
From our peer review, we also found that the background paragraphs were usually the part of the cover letter that needed the most edits. However, we concluded this was not due to how we modeled the schema, but simply due to the fact that this is the hardest part to produce. Any additional clarifications or restrictions to this section might seem constraining since this is the section that more directly responds to job descriptions which can vary significantly. As a compromise, we decided to add sub elements that could be used to call out highlights under experience paragraphs. We added languages, skills, certifications, and programs as optional sub elements to work as a list of possibles to include inside this section. The hope is that this would help the writer to generate ideas for what to include in this section and keep the letter focused.

The genre we are analyzing is a cover letter. Cover letters are typically preceded by job postings, as they are a method of expressing interest and representing your strengths as related to a job you are applying for. Cover letters tend to be tailored to the values and description used in the job posting since the author/applicant wants to represent themselves as a good fit for a particular job. Genre’s preceding a cover letter can include conversations or posters at job fairs, online ads posted on hiring websites, ads on university resources such as NUCareers, etc. A cover letter may be ignored if it is not well received; however the hope is that the uptake would be interest in you as an addition to a manager’s company. The hope is that you get a response in the form of an interview request following your cover letter.

When putting together our genre model, we considered how easily the reader will be able to find the important information in the cover letter, how much time and energy the reader would have to commit to reading the letter, and how to encourage professionalism and courtesy in the assembly of the letter. For these reasons, we included a fairly rigid structure for how to organize and assemble the content in the letter. We made introductory and closing paragraphs mandatory, and we built in a greeting and signature. That way it would be easy for the reader to pick up the letter, get a good sense of the purpose of the letter and the goals of the applicant from the first couple sentences and then find all the applicant’s qualifications immediately afterwards. We also made sure that the closing paragraph would include an invitation for further communication (an interview) and the header would include sufficient contact information for the reader. The assumption being that if its an easy and pleasant experience for the reader to read through your cover letter and reach out to you, then you’ll be more likely to get an interview.

Unfortunately there are a lot of things that can influence the uptake of a cover letter that could not be controlled by a genre model. Strategically, an applicant should include action verbs in their cover letter, use easy to read and professional language, describe accomplishments they have made in their professional experience, express goals that align with the company’s values, or anything else that makes them sound like the best fit for the position they are applying.

At my most recent co-op I worked on a team of scientists and engineers to fabricate primary metal via clean electrochemical processes. The company, Infinium, was a fairly young start up composed of about 18 people.  We had quarterly progress/production goals that we had to meet to keep our investors giving us money and therefore had a lot of strict timelines. That meant that on a daily basis, aside from trying to work on our big picture problem (how do we make this metal production system work?) we had all kinds of more focused problems (how do we quantify the progress we have made on this particular aspect of our project? How can we do this experiment on a budget and time restraint?). Solving all these projects took the involvement of engineers, finance people, chemists, and a machine shop among others. On top of that, often times one person would fill the roll of two positions; for example one of my coworkers played the part of both engineer and lab manager, there was also a two month span when we had no finance people working for the company.

All this considered, my last co-op was the most transdisciplinary environment I have ever worked in. I realized that the most important part of making this all work was communicating effectively. Everything was accomplished quickly because of the fact that most of the time the whole company was under one very small roof. This also made it easy to figure out when we needed to reach outside for help. If no one at the company was well versed in a certain topic, we’d reach out to  other servicing companies to get answers.

Personally, I struggled communicating with my supervisor. I spent most of my time on a subproject focused on aluminum. My team was made up of only three people. My supervisor was not an engineer; he had a background in physics and chemistry and was extremely smart, but lacked practicality and some communication skills. Many hours were spent by my supervisor spit balling a bunch of ideas, and myself and the other engineer  figuring out which of his ideas we could actually apply. Communication improved as I got more comfortable with my supervisor and the chemistry we were doing; I started to understand what he was saying from the perspective of a scientists versus an engineer and I could give input as someone with a mechanical background. We made an unbelievable amount of progress in the six months I worked at Infinium.

It was a unique and rewarding experience to work at such an interdisciplinary company. It made me understand all the different kinds of work that make a business successful, and forced me to push out of my comfort zone and approach problems with a more open mind. Untimately, it forced me to collaborate with people who had all kinds of different strengths and expertise which I think is a fundamentally important skill to have as an engineer.

Our first writing project was my first real experience using a mark up language. I had worked with HTML really briefly before, so at least I wasn’t terribly intimidated by working without a text editor, but aside from that, I went into it completely inexperienced. As a whole I appreciated doing this project. I feel it’s a useful skill to have learned a markup language, and the learning-through-doing aspect of it was very helpful. The fact that I had a project to complete forced me to really get a workable baseline understanding of XML, Oxygen, and GitHub. The markup schema we came up with in class served as a very good checklist of sorts. It was helpful to basically have boxes I had to fill in to complete each annotation. It also helped me make sure that what I was writing actually qualified as an annotation and not some kind of weird tangent. XML on it’s own was also fairly easy to understand, the hardest part was probably understanding how all these programs worked together to make my published project on the WordPress page. I still don’t think I know how GitHub works, but thats a work in progress.

My only gripe with having done project 1 in XML is that I feel like I got distracted from the ultimate goal of making an annotated bibliography. I was focused on learning XML and building and understanding the schema that I feel like I didn’t allot enough time to finding appropriate sources and thinking about what I really wanted to make my bibliography about. With design entry 1, I genuinely just came up with something that I think is the biggest problem in Boston (transportation/traffic). When it came down to it, it was really difficult to find sources that I felt were applicable and well focused on this topic. I tried not to stray too much from my original idea, but my problem statement in Project 1 is about lighting in Boston which is related, but different. There also isn’t much that would be a city/campus related problem that would call for expertise from a mechanical engineer before some other kind of engineer too, so I wish I had taken more time understanding genre analysis and finding ways of applying it to something I can relate to. Basically, I think that had I not been working through the XML learning curve, I would have accomplished better annotations and compiled much better sources. That being said, now I know, and shouldn’t run into the same problem with Project 2.

The beauty of being a mechanical engineer is that they are involved in all aspects of engineering and problem solving; engineering and problem solving are integral parts of most public service industries. That being said, mechanical engineers can be found holding all kinds of job titles and working in a huge variety of industries.

Boston boasts being a youthful city full of innovation because of all the colleges and universities that it hosts. However, Boston is also one of the oldest cities in the country and has an extremely dated and inefficient transportation system to go along with it. Services like uber and hubway are extremely popular because of how difficult it is to travel via train within the city. Even Uber and biking pose their own challenges because traffic can be debilitating and biking among Boston drivers can be dangerous. Despite Boston being relatively small, it can take unreasonably long for people to commute to work and school because of the outdated MBTA system and the mess of roads and traffic inside the city limits. Aside from being an inconvenience, poor transportation systems also contribute to safety concerns (especially in the winter) and the huge influx of people who try to live inside the city because it’s too difficult to commute from somewhere else.    

Although transportation and infrastructure are issues typically handled by civil engineering/consulting companies, it is an issue that needs more hands on deck. Tackling this problem will take lots of financial and practical planning that would involve several types of engineers. Reorganization of the transportation system and updates made to the MBTA could massively improve the state of things, but as a mechanical engineer, I wonder if the implementation of an entirely new transportation system would be a more effective fix? What alternatives could exist to make traveling in Boston less of a problem?