On the course, and on myself

My overall experience in ENG 2003 was well rounded. It wasn't only a writing course. Assignments moved between written communication (the technical report, two handouts, a cover letter) and spoken communication (the mock video interview for Assignment 2), which showed me these are the same underlying judgment about a reader or listener, applied in two different registers, not two separate skills. Coming in, I expected a course about writing "correctly": grammar, formatting, the usual. What I got instead was closer to a course about decisions: who is reading this, what do they already believe, and what is the one thing I need them to walk away with.

That reframing showed up concretely across the semester. In Assignment 3, producing two handouts on the same grand challenge for high school students versus field experts forced me to treat "audience" as a design constraint, not an afterthought. The same fact needed a completely different framing depending on who was reading it. In Term Project 1, writing a technical report meant learning to integrate five peer-reviewed sources into an argument without letting the evidence bury the point I was trying to make, a direct exercise in the 7 C's principle of completeness without losing conciseness. In the cover letter assignment, I applied the Axioms of Communication almost literally: Axiom 9, "you cannot not communicate," meant that staying silent about the graduation year mismatch in my application would itself have sent a message, probably one of evasiveness, so I addressed it directly instead of hoping it would go unnoticed.

The course content I found most useful was the rhetorical triangle and audience analysis from Assignment 3, because once I'd used it to build two genuinely different handouts for two genuinely different readers, I found myself rerunning the same analysis: who is this for, what do they already know, what's the one thing they need, before starting the cover letter and the technical report too. The topic I found most interesting was the Axioms of Communication, particularly axiom 9, "you cannot not communicate": it reframes even staying silent as a communication choice, which turned out to be a more useful way to think about a decision like the graduation year mismatch than simply "should I mention this or not."

Before ENG 2003, I would have described my communication skills as solid but unfocused on the reader; I documented my code and my independent projects because that's the habit you build as a self-taught developer, not because I'd thought hard about who was actually going to read it. Now, after producing a technical report, two tailored handouts, a cover letter, and documentation for a hardware project, I approach a writing task by first asking who the reader is and what they need, before drafting a single sentence.

The skill I improved the most was using peer feedback to actually revise, not just acknowledge it. After two classmates blind-reviewed my technical report's draft through PeerScholar, I went back and reworked the introduction's framing and split dense paragraphs based specifically on what they flagged, rather than filing their comments away as a formality. What changed my mind about peer review was Axiom 7, communication is ambiguous: the introduction was perfectly clear to me, because I already knew what I meant, and that is exactly why I was the worst possible judge of it. Both reviewers read the opening as a general warning about data breaches, which was not the argument. In 7 C's terms, fixing that was a clarity and concreteness problem: I replaced the abstract framing with named physical stakes, a tampered medical device and a vehicle acting on a forged command, so the reader could not slide past the point I needed them to hold.

The skill I still need to work on is presenting live rather than in writing. Assignment 2's mock video interview made it obvious that I can control a message much more precisely on paper than in real time, in front of someone, under a bit of pressure. Axiom 6, communication involves interpersonal risk, describes why: in writing I can absorb that risk privately by redrafting until the sentence is safe; live, I have to accept it in front of the other person and keep going. Naming the risk as the thing I'm avoiding, rather than a lack of preparation, is what makes it fixable. It matters because most software engineering interviews, and a good chunk of the job afterward, run through exactly that channel: a live conversation with no chance to redraft a sentence.

This shift changes how I'll approach other engineering courses and, eventually, engineering practice: technical correctness alone doesn't move a project forward if a report, a handout, or a pitch doesn't land with its actual reader. As Brand and Content Manager for Google Developer Group (GDG) York, I now think about who is actually going to see a given piece of content (a first-year developer deciding whether an event is worth their evening, or a partner organization deciding whether to sponsor it) before I design it, instead of making one asset and hoping it works for everyone. Those two readers need different C's carrying the weight: the student needs conciseness and courtesy, because I am asking for their evening and have seconds to do it; the sponsor needs completeness and credibility, because they are asking what they get back. I expect the same split in practice, between a technical team and the stakeholder who signs off. That habit of checking a message against the Axioms and the 7 C's before sending it is the single most transferable thing I'm taking out of this course.