Author: khatra.g

Overall, I feel like this class not only made me a better writer, but it also improved my analytical skills. It has been making me think differently about everything I’ve been reading since we studied more about genre. Just a few days ago, I was reading a mystery book and I stopped in the middle to think about overlapping themes and structures that might be present in mystery books, and I caught myself trying to vaguely sketch out an XML schema in my head for that genre. Thinking back, I feel like finding structure in the assignments I’ve been writing in class has always been a subconscious thing I’ve done, but taking this  class will make me think more consciously about extracting structure from examples I’m given. I believe that doing this will improve the quality of any sort of documents I have to write in the future.

Overall, I feel the structure of the class, where we would do the assignments in XML, submit using Github, and write design entries using WordPress all worked well. Having our work out in the open for the entire class to see was a little nerve wracking at first, but in the long run I learned how useful having my work peer reviewed could be. On top of that using a markup language such as XML also seemed like an extremely useful tool in teaching us about extracting structure from a genre.

Looking back at assignment 2, my initial thoughts when starting it were about how easy coming up with a schema for whatever genre we picked would be. In my mind, the structure of all genres was pretty straightforward, and apparently all of my group members thought so too, except their structure was different that mine. Going through and discussing how to format out schema, and coming to a single conclusion was an extremely interesting experience. Before starting the assignment, I thought it would be a piece of cake, but as we went through, I realized how much work it would be. After we wrote up a schema we could all agree on, I thought it was perfect and we would be done with it forever. However for assignment 3, a few of our classmates actually disagreed with some aspects of it, which I thought was interesting. Even though our individual compositions looked really similar, there were some differences between our schema, which I found very interesting. It seemed like we all subconsciously knew about the genre, but all defined it differently.

I feel like after going through this class, I won’t be able to pick up on different genres in workplaces or daily life without consciously looking at the structure. Although it might be a little more work on my part, overall I think it will help me better pick up on how to using those genres properly and effectively. 

For writing project 3, I decided to write a letter to a company I found on the Northeastern coop listing website. Overall I never felt too constrained by the schema, since it did a good job of differentiating sections that were more static versus sections that might vary from person to person. For example, the header of a cover letter is going to be extremely similar from person to person, but the body of the letter is going to vary much more. The group that created the schema ended up using attributes to differentiate between different types of experiences (ex. school, work, etc) for some added flexibility, which I thought was useful since it also gave me ideas for what I should be putting in my cover letter. I definitely think the schema helped me stay focused while writing my cover letter, and comparing it to cover letters I’ve written previously, I do feel like I see some improvement.

While comparing my work to the cover letter my peer wrote, I did see some things they did well that I should integrate into my cover letter. They did do a much better job of going into the important details of their experiences and how they relate to the job they are currently applying to. They pointed out that in my cover letter, I mention that I worked at an finance oriented place and the job I was applying to was at a finance oriented company, but I never took advantage of that connection to show why I’d be a good candidate for the position.

As for the schema, I think it does an appropriate job of outlining what a cover letter needs to be. I’m sure there is room for small improvements with some added tags in contact information and the signature, but I think the body struck a good balance between flexibility and structure.

Overall, the schema figure we create helped guide me in my writing process. In the case of our genre of Edutainment blogging, we made sure to make the schema flexible, so it could fit the format of different types of blogs we looked at. I feel like the schema did help give me a guide on where I should put different thoughts I had and wanted to explain. I feel like if I didn’t have the schema, my explanation would have been more scattered and less intuitive, but with the schema I feel like it flows and seems more of a natural progression.

From a technical perspective, XML is a new type of markup language to me, and so there was a small learning curve. The most difficult part was using Oxygen to write the content of my blog post. It has really useful autocomplete features and auto formatting, but I ended up making the decision to write the blog post in a word processor I was comfortable with, with the schema in mind, and then adding the tags in Oxygen.

For building the schema, I definitely thought the group work was critical. It was useful to individually research blogs, and then see other group members opinions on blogs they looked at. Discussing which aspects of the blogs to add to the schema and where to put different tags was useful in creating a flexible, but accurate structure we could use for the project. In the end, I think we did a good job in building a final schema. Looking at our groups blog posts, you can clearly make out vague structural components, but you can also recognize our individual styles in the individual composition. This is something we observed while researching different blogs, and we tried to preserve this feature while building our schema.

While listening to the other teams present their genre, the one I’m leaning toward using for project 3 is the cover letter. Out of the three genres, I feel like cover letters are the most relatable to me at this stage in my life. I’m at a point where I’m going to be applying to jobs or internships, so I’d imagine I’m going to have to write a few cover letters. I’m hoping that I can improve the structure of my cover letters to help convince employers to hire me. Previously when writing cover letters, I really had no idea what to write. I just wrote the first things that came to mind, and the result seemed unstructured and unorganized. I’m hoping that having the XML schema as a structure will help guide me, and I’ll be able to reproduce new cover letters when it comes time to apply to jobs.

Looking at the individual compositions created by the cover letter team, the overall structure of cover letters seems pretty rigid. There is a portion for contact information, greeting, body and closing remark, and the body is further broken down into sections. The overall tone of the letter is formal, which is expected since this is supposed to be a professional letter. From a content perspective, I noticed a majority of the letter talks about the qualifications of the applicant. It talks about the applicants previous experience in the field, and how it can be applied to the position they are applying to. Personally, I feel like this is an area I could improve on in my personal cover letters. I did include information about myself, but I was hesitant to repeat information that was already on my resume. My cover letters ended up having a decent chunk where I talked about the company itself, and why it was interested in it, but I feel like I could reduce that a little bit and include more about why I would be a good fit in the company.

While writing the draft for the second writing project, I used the schema we created to guide me and keep the draft focused on being a scientific blog post rather than just an essay explaining my topic. As a team, we made sure to do our research by looking at a variety of science blogs before drafting up a schema, and I think the resulting template was solid. We made sure to give it some structure by splitting the blog post up into two main parts (background and answer) with each section having a few required parts, but we also retained a lot flexibility by having tags that could be used anywhere. Personally, I preferred using the schema we created as a small team for this project over the schema we created as a class for our last project. This might be a product of learning from any mistakes we made when creating the first schema, and making sure not repeating them for this project.

While peer reviewing my teammates composition, I noticed that the general structure was similar to mine (which was expected since we used the same schema), but we still had a few differences. The most obvious difference I saw was the structure in which we cited sources at the end of our post. While researching the structure of science blogs, we noticed that they would cite sources by either just embedding links to them when they were mentioned, or they would be formally cited at the end of the post. I chose to cite my sources more formally by using MLA format at the end, while Ben was more informal by having a paragraph at the end of the post where he discusses resources he used, and gives a brief description of what they contain and why they are relevant. This would be extremely useful to the reader if they want to learn more about a specific part of topic that was explained. Personally, I preferred his method since it seemed to fit the casual nature of a scientific blog post.

Our group decided to explore the genre of scientific blogging, in which an author attempts to break down complex scientific topics into layman’s terms so a broader audience can digest it easily. A “science blogger” would typically be an individual with a background in a scientific field but also has experience in explaining ideas unique to a field to individuals not involved in it. When trying to choose a topic to describe, they will typically wait for a breakthrough to happen that generates a buzz and sense of excitement within a field, which might spread and peak the curiosity of individuals in other disciplines. Their skill set allows them to parse through the jargon of any journal article or academic paper, and be able to extract key ideas to let the others know what happened and what sort of future impact it might have. It is common for them to use easily comprehendible mediums of explanation, such as comics, diagrams, or analogies in order to convey their idea as quickly and succinctly as possible.

While reading through the genre frameworks outlined by Spinuzzi, I immediately thought about scientific blogging while reading the description of Genre Systems. Spinuzzi describes the framework as “made up of sequences of genres that hand the baton of communication onward”, which is exactly what happens in the field of scientific blogging. A team of academics will put out some sort of publication that describes their findings to their peers in that field, and these bloggers will grab the “baton of communication” to create a blog post that spreads these findings and ideas to a wider audience. In this case, the “source genre” would be a journal article or scientific paper and a chain of communication branching from it might go to a scientific blog, and it can continue further to other genres such as comics related to the scientific blog post to aid in an explanation, or scientific video blogs where complex topics are broken down in video form. In order for our group to understand the genre we are studying, it is important to look at this chain of communication, to see how the explanation of ideas mutate at each link.

At my last coop, I worked at a large financial institution in New York called Goldman Sachs. It might seem like an odd choice as a computer science major, but they are becoming reliant on technology to keep the company up and running and as a result, almost a third of the company now has some sort of technology background. However, being a finance company, I had to regularly interact with people coming from finance backgrounds, and all of my projects ended up being related to finance. When first getting started there, it was interesting to see how my coworkers in technology would interact with their finance oriented peers versus the technology oriented peers. With their technology peers, they seemed to talk more openly about projects, and use plenty of jargon that was relevant to the technology industry. When talking to their peers in finance, they would choose words carefully so someone without a technology background could understand the idea they were trying to convey. It was the same the other way around too: I noticed that my finance peers would use a lot of analogies to when trying to explain financial topics to us. When communicating, both sides had to cut down on the disciplinary jargon in order to convey their ideas to each other.

After talking some of my coworkers, what surprised me was the diversity in college background of various people working in finance. Sure there were a decent amount of people who majored in finance, but there was also a significant amount of employees who majored in disciplines such as psychology, history, engineering and english. A question I would commonly ask is how they applied what they learned in college to their current position, and I got a variety of interesting answers. For example, a psychology major explained to me that his discipline gave him the ability to better understand how the human brain works, and he could use that to be better at managing his team. The English major told me that his discipline helped him convey his thoughts and ideas clearly, which helped in emails, meetings and when giving presentations. Overall, this coop had more transdisciplinary interaction than most computer science coops, and let me improve my ability to communicate with coworkers who come from various backgrounds and disciplines.

Looking through Ben Gincley’s annotated bibliography was an interesting peak into another discipline, and what kind of work they do. Ben discussed the field of neural engineering, which is a relatively new field in which they are trying to find ways restore lost neural functions. The initial difference I saw when comparing y annotated bibliographies is that Ben’s covers a slightly broader topic. My annotated bibliography was focused on the specific problem of detecting lead paint in Boston houses, and Ben focused more on discussing breakthroughs in ways neural engineers are helping paralyzed individuals get back to having normal lifestyles, whether that be through improving their means of communication or giving them mobility again. As a byproduct of this, my sources ended up being selected from a wider range of genres to build up to a solution to the initial problem I brought up, and Ben was able to pull mostly from scientific journals and papers to discuss his discipline.

Looking at the XML markup, Ben and I seemed to agree on in which of the “buckets” we should put different ideas we were trying to convey. We both followed the order of giving a background, summary, and then explaining the relevance to the topic we were discussing. One of the differences I see is that Ben’s XML looks much neater than mine. A clear difference is that his lines wrap around to the next line when they are too long, and end up fitting in the margins while you have to scroll to the left, past the margins, to finish reading each of my lines. It’s definitely something I’ll look into improving in future writing projects.

The processes of creating an annotated bibliography in XML was definitely different than any other english assignment I’ve gotten. It provided an interesting experience of trying to convey the information I wanted in a way that would flow in an intuitive manner, and also fit the schema we put together. I had to give significantly more thought into how to phrase what I wanted to say, so I could also match the definition of the type attribute I was trying to write for. I do feel like the XML structure obstructed my writing process, but it did so in the same way a gutter guard would obstruct a bowling ball from going in the gutter. Having to use the structure kept me more focused on what I should be conveying in an annotated bibliography, rather than rambling and getting off topic. It also made me give more thought into what sources I chose for my bibliography. There were a few sources that I ended up not using because after I read through them and fitting them into the schema, I realized that the information wasn’t as useful as I initially thought it would be. From a technical perspective, it wasn’t too difficult it get used to. Really the only technical obstacle to overcome was learning how to navigate my way though Oxygen, and then figuring out how to test my final XML document in a normal format. Being a Computer Science student, the portions of the assignment where we had to use Github were’t new to me, and didn’t cause any problems.

Continuing to use XML is going to be a process that will take some getting used to, in both adapting my writing process for it and learning more about the technical aspects of it, but overall I feel I will come out in the end being able to more concisely and clearly express my ideas and thoughts.

Over the past few decades, the field of computer science has experienced exponential growth and its applications have branched out into nearly every other discipline. With this broad adoption and advancement in new technology came access to an expansive amount of data, as well as the ability and computing power to easily explore these datasets and draw useful conclusions out of them. As a computer science student, I find it fascinating that we are now able to comb through a vast amounts of information, and extract patterns and structures that would have been  previously invisible to the humans eye, and I feel as though it has an almost limitless amount of applications. An example of just one of the applications could be pulled from the field of medicine. In recent years, medical researchers have been working to gather and explore data from cancer patients, and have been using it to build a mathematical models that can quickly and accurately detect cancer at an earlier stage in other patients. This would allow for the patient to start treatment before the cancer could spread further, and  would significantly increase chances of a successful treatment. Previously, identifying the symptoms for early detection would have been an extremely involved and intensive process, and the end result might have been imprecise. Now with the computing power and data that researchers have access to today, a few computers can do all the heavy lifting, allowing the field to advance at a rapid pace.

As a relatively young field, data science research is being published on an almost daily basis. Cutting edge research is not only coming out of colleges and universities, but technology companies that have recognized its many applications and have been investing in their own research facilities. These researchers investigate generic ways to use large amount of data to draw qualitative conclusions or develop mathematical models, and they spread their findings in journals for other researchers who try to find applications in their respective fields. The continued research into properly and efficiently using the enormous amount of information we have access to is going to continue to allow us to see technology advance at a rate faster than we have ever seen before.