In engineering, there is a great deal of communication involved. You might find yourself helping a coworker with a tough engineering problem, but your solution just doesn’t come across to them. You could also find yourself pitching an ambitious project to a board of higher-ups who don’t even know how to use their own home computers. It’s easy to underestimate the amount of communication that we have to do as engineers, especially when we are deep in our own worlds of studying. The fact of the matter is, we are always going to be interacting with and working with people, and what good is your vast engineering knowledge if you can’t express it to people in a way they understand? I was one of those people who didn’t consider the communication aspect of an engineering career. Writing for Engineering taught me this importance. In this course, I learned that there are different ways to write for different audiences and how to take those audiences into account. This course also taught me how to adhere to the writing conventions of commonly used report formats, such as lab reports and technical descriptions. I’d say one of the biggest skills it taught me, though, was how to collaborate with multiple people on a unified project. 

The target audience is a very crucial part of writing for engineering. The main idea I learned on how to account for a target audience is to acknowledge the common knowledge from both parties on a given subject. I personally didn’t have much experience with this. I usually avoided situations where I had to explain a complex topic to someone in another specialty. I’d say this course helped me a lot with this idea. One of the assignments that was very enlightening for me was our second discussion board post. The task of the first part of this post was to explain some specialized knowledge you have with as much technical jargon as possible, and then try to guess what other classmates were talking about. It was an intentionally fun and confusing exercise, but writing that first half was very helpful for the second half. The next part of the assignment was to rewrite your original explanation, but try to make it understandable to an audience that isn’t familiar with your topic. For this part, it really helped to have the first part of this exercise typed out. I was able to look back at the main message I wanted to convey and make edits to it for clarity. I had to really think about what I was trying to say and what parts were important. This meant removing a lot of unnecessary details. It also meant that the details I did include were explained well. Overall, it was a really fun exercise, and even though I talked about something trivial, in my case solving a Rubik’s Cube, there are lots of other examples where I might need to explain something more important. I learned a very valuable way to handle these situations.

Before this course, I wasn’t aware of the writing conventions of professional lab reports and papers. This is very apparent in my first draft of the lab report I had to write for this class. I took a very personal and friendly tone with my writing. I used eccentric punctuation and wrote from my natural voice. I learned in the revisionary annotations that my writing was understandable and easy to read, but it completely violated the writing conventions of a lab report. One of the biggest issues was that I hadn’t stuck to a consistent passive voice when writing my report. The way I understand passive voice is that you refer to only the objects, and don’t refer to people. Instead of saying “I poured water,” you would say “The water was poured.” With this knowledge (and the other revision notes), it wasn’t hard at all to fix my report and write my final draft. I had already written all the information out, all I needed to change was the way this information was being conveyed. I was very surprised how simple it was to take this laid-back and friendly report and make it sound concise and professional. If I wasn’t sure how to convey an idea, our professor had us annotate an already existing lab report to try and deconstruct the writing conventions from there. That exercise really helped, since I was also able to find out other information about these lab reports, like the target audience and the overall structure.

I feel that I learned the most from the Engineering Proposal project. The collaboration aspect of this project was something I hadn’t done before to this degree. If I were to do this project with no guidance and just a team of people, I think it would’ve ended up with one of us doing all the work, or figuring out who does what at the last minute. The way this project was structured, we had to create documents that outlined how we would get our project done. We created a group contract that outlined how we would be communicating and submitting projects. It got really specific and accounted for ideas I hadn’t even thought of, like how long we’d have to wait for a response from one another. We also had to create a Gantt chart, which is a way of dividing up and organizing the tasks that needed to be completed for our project. It made the rest of the project very straightforward, since we knew exactly what we needed to do every step of the way. Another thing I learned from the proposal was how to give a convincing pitch to an audience. We had to be extremely specific in our final proposal. We included a substantial amount of research and got extremely detailed. It made a lot of sense why we needed more than one person to make this report. In the beginning, I might’ve been under the impression that I could go about this alone. We each agreed to take on one part of the project, which allowed each of us to focus on one single aspect of our proposal. One thing I didn’t consider was how all of this information would read, since we did our parts disjointedly. This required one of us to do a final check of all of our submissions to make sure it was all readable. I’m definitely going to use this method when I have to do any sort of collaborative project in the future, since it made the entire process really simple.

CCNY’s engineering program tries to equip you with as much knowledge as it can. They require you to understand the deep underlying physics of everything you’re doing, giving you a sturdy background in your field. Their Writing for Engineering course is part of this program. They try to teach you the overlooked parts of being a good engineer. These parts could be explaining your idea to a target audience. It could also be writing a lab report that adheres to conventional formatting. The most important thing I learned from this course, though, was how to collaborate with others on projects. You could say that all communication is a collaboration between two people, the conscious effort to try to understand and be understood. I believe that through my efforts, my communication skills as an engineer have strengthened.