Back to ariyanazami.com

ENG 2003 — Effective Engineering Communication

Communication Portfolio

Summer 2026 · Lassonde School of Engineering, York University

This portfolio was built for ENG 2003, a required communication course at York University's Lassonde School of Engineering. The course asks engineering students to treat writing, speaking, and visual design as engineering work rather than as decoration on top of it, and it assesses that work through cover letters, recorded interviews, audience-adapted handouts, a multi-phase technical report, and blind peer review. What follows is a record of four pieces I produced this year, a reflection on what changed in how I communicate, and a short section on the work I do outside coursework. I have written it for a reader who has never taken the course and does not know me, so each piece is introduced with the context needed to judge it on its own terms.

1 · Showcase — Four Pieces of Work

First page of Algorithmic Fairness in Automated Decision Systems (final technical report)
Technical report

Algorithmic Fairness in Automated Decision Systems (final technical report)

ENG 2003 · Term Project 1, Phase 4 · July 2026

Why I selected this piece

This is the most demanding document I have written. It argues that explainable AI methods, specifically SHAP and LIME, should be deployed as a mandatory audit layer in automated hiring and credit-scoring systems, and it has to hold that argument together across a letter of transmittal, an executive summary, two original figures, two tables, and eleven references in IEEE format. I selected it because it is the one piece where every part of the course had to work at once: research, structure, visual design, citation, and tone.

What this piece says about my development as a communicator

The draft and the final report make the same argument, but only the final one manages the reader. Early on I wrote as though a correct sentence was a clear sentence. By Phase 4 I was building a path: the executive summary states the conclusion before the evidence, each figure is introduced and then interpreted rather than left to speak for itself, and the Shapley-value foundation of SHAP is explained in plain language before the formal properties appear. That shift, from presenting information to sequencing it, is the clearest change in how I write.

Did this piece push me out of my comfort zone?

Yes, in a way I did not expect. The technical content was familiar territory. What was uncomfortable was Appendix A, where I had to document the peer feedback I received and account for what I did and did not change. I declined one reviewer's suggestion to add a dollar cost estimate, on the grounds that SHAP and LIME are open-source libraries rather than capital equipment and a figure would have been speculative. Writing down a disagreement with a reviewer, and having to justify it in the document itself, was harder than writing the technical sections.

Is this my best work?

It is my strongest work in this course, though not flawless. The argument is well evidenced and the document is complete and correctly formatted. Its weakness is length discipline: some paragraphs in the Discussion carry more qualification than a reader needs, and conciseness is the C I am still worst at. If I revised it again I would cut rather than add, which is the opposite of the instinct I started the term with.

First page of Annotated Bibliography — Explainable AI as a Bias-Mitigation Strategy
Annotated bibliography

Annotated Bibliography — Explainable AI as a Bias-Mitigation Strategy

ENG 2003 · Term Project 1, Phase 1 · July 2026

Why I selected this piece

I chose this piece because it is a different kind of writing from the report it eventually fed, and because it changed how I read. For each of four sources I had to summarise the work, evaluate it using the rhetorical triangle, and reflect on its relevance to my topic. It is the only piece in this showcase where the subject is other people's communication rather than my own.

What this piece says about my development as a communicator

Applying ethos, logos, and pathos to sources rather than to my own writing was the most useful analytical move I made this term. It let me say something more precise than whether a source was good. I could argue that the European Commission's AI Act page carries maximum ethos as a primary legal source but offers little logos, because it documents obligations without weighing them, while a systematic review of forty-three credit-scoring studies has strong logos through its appraisal protocol but cannot verify how consistently the underlying studies computed their fairness metrics. Learning to locate a source's weakness precisely is what later let me write a Discussion section that conceded limitations instead of hiding them.

Did this piece push me out of my comfort zone?

Yes. Criticising peer-reviewed work published by researchers with far more expertise than mine felt presumptuous at first, and my early drafts of the evaluation column hedged so heavily that they said very little. Committing to a specific, defensible criticism, and accepting that I might be wrong in print, was uncomfortable in a way that summarising never is.

Is this my best work?

Not my best work, and I would not claim otherwise. The reflect column is stronger than the evaluate column, and in two of the four entries my criticism lands on a generic weakness of review articles rather than on anything particular to that paper. It earns its place here because of what it made possible rather than because of its polish: without the source evaluation done at this stage, the final report would have had citations without judgement behind them.

First page of Cover Letter — Associate Developer, IBM Canada
Professional correspondence

Cover Letter — Associate Developer, IBM Canada

ENG 2003 · Assignment 1 · May 2026

Why I selected this piece

I selected this because it is the shortest piece here and the hardest to get right. A cover letter has one page to establish credibility, connect my experience to a specific role, and sound like a person rather than a template. It is also the piece most directly connected to the rest of this portfolio: the same problem of introducing myself to a stranger governs the LinkedIn profile linked below.

What this piece says about my development as a communicator

This was written early in the term, and reading it now I can see the exact habits the course had not yet corrected. It does the important things: it names the role, it ties my work at Appli AI to the posting's requirement that associates work across front-end and back-end, and it closes with a request rather than a hope. But it also tells IBM what IBM already knows about itself, and it asserts that I could contribute meaningfully from day one without giving the reader evidence for that claim. The letter argues by adjective in places where it should argue by example.

Did this piece push me out of my comfort zone?

Moderately. Writing persuasively about myself is less comfortable than writing about a technology, because the credibility at stake is my own rather than a citation's. The specific difficulty was calibration: strong enough to be worth reading, restrained enough to stay believable.

Is this my best work?

No, and it is the weakest of the four pieces. Kept in deliberately, because the difference between this letter and the Phase 4 report is the most concrete evidence of development I can offer, and because removing my earliest work to make the showcase look uniform would misrepresent what this portfolio is for. If I rewrote it today, I would cut the second half of the opening paragraph entirely and spend those lines on a specific feature I shipped.

Outside ENG 2003

Piece to be added

Appli AI · Software Developer

Artifact not available for download.

Appli AI

Why I selected this piece

To be added.

What this piece says about my development as a communicator

To be added.

Did this piece push me out of my comfort zone?

To be added.

Is this my best work?

To be added.

2 · Reflection

Part A — Reflecting on ENG 2003

Written against the nine Axioms of Communication from Lecture 04 and the 7 C's of Communication.

I came into ENG 2003 expecting a soft course attached to an engineering degree, and I left thinking of it as the closest thing in my second year to a design course. The reframing happened around the Axioms of Communication in Lecture 04. Axiom 8, that communication is audience-centred, is the one I keep returning to, because it converts a vague instruction to write well into a specific engineering question: who reads this, what do they already know, and what do they need to do afterwards. Once the audience is a constraint rather than a courtesy, drafting becomes something closer to specification work, and revision stops feeling arbitrary.

The course was not what I expected in a second way. I assumed the difficulty would be producing text, and it turned out to be structuring it. Term Project 1 ran across four phases, and each phase failed differently. My annotated bibliography hedged its criticism of sources. My Phase 2 draft made its argument but buried the conclusion. The final report only worked once I put the conclusion in the executive summary and made every figure earn its place in the surrounding paragraphs. None of those were sentence-level problems, which is what I had assumed writing problems were.

The most useful content was Lecture 06 on technical writing, specifically the instruction to explain things before presenting them. I had been doing the reverse: introducing Figure 1, then explaining it. Inverting that changed my report more than any other single edit, because a reader who understands why a figure exists reads it correctly the first time. The same lecture's guidance on avoiding first person and reducing ambiguous terms is what pushed my final report into a consistent formal register, addressing exactly the kind of tonal inconsistency a peer reviewer had flagged in my draft.

The most interesting topic was the rhetorical triangle, and specifically using it to evaluate other people's work rather than to plan my own. In Phase 1 I used ethos, logos, and pathos to judge four sources, and the framework made my criticism precise instead of merely polite. It also connected to Axiom 4, that communication is a principal way of establishing and maintaining credibility, in a way I had not anticipated: the reason a systematic review with a documented appraisal protocol reads as more trustworthy than an equally accurate blog post is that the protocol is itself a communicative act. Axiom 7, that communication is ambiguous, landed hardest in the recorded interview assignment, where a single take meant I could not read a room and adjust, and every ambiguity I introduced stayed in the recording.

Part B — Growth and Development as a Communicator

Structured using Gibbs' Reflective Cycle: description, feelings, evaluation, analysis, conclusion, action plan.

Description. The episode I want to reflect on is the revision of Term Project 1 between Phase 2 and Phase 4. I submitted a draft, received blind peer feedback from three reviewers through PeerScholar, and rebuilt the report. Two of the three reviewers had been assigned reports on entirely different topics, a concentrated-solar-power proposal and an autonomous-vehicle sensor-fusion proposal, so parts of their commentary did not describe my document at all. The third reviewer engaged with my report directly and told me to confirm every claim was cited, verify no section had been lost on export, and adopt a more consistently formal tone.

Feelings and evaluation. My first reaction to the mismatched reviews was that the feedback was wasted, and my first reaction to the formal-tone comment was defensive, because I thought my draft already read formally. Both reactions were wrong, and noticing that they were wrong is the part I would keep. On re-reading, the draft did contain contractions and informal phrasing, and the transferable advice in the off-topic reviews, add citation numbers next to specific claims, add a diagram and a comparison table, was straightforwardly good. The feedback I resisted most turned out to be the feedback that changed the document most.

Analysis. Two axioms explain why this was harder than it should have been. Axiom 6, that communication involves interpersonal risk, describes both directions of a blind peer review. Axiom 2, that all communication involves relation as well as content, explains my defensiveness: I read a comment about tone as a comment about competence. Separating those layers is what let me write Appendix A of the final report, where I mapped each piece of feedback to a change and declined one suggestion with a reason rather than ignoring it silently.

Conclusion. What improved most is structuring a document for a reader: executive summaries that state conclusions first, figures that are introduced and interpreted, and headings that let someone navigate without reading linearly. Correctness and completeness improved too, mostly through discipline about citations. What still needs work is conciseness, which is the C I most consistently fail, and delivery under time pressure. In the recorded interview assignment I had one take, and my answers were accurate but longer than they needed to be, with the qualifications I would edit out of a document left in out loud.

Action plan. Two concrete changes. First, I will treat every first draft as over-length and cut a fixed proportion before anyone else reads it, rather than adding qualification when I feel uncertain. Second, at Appli AI I write pull request descriptions that other developers act on, so I will apply Axiom 8 to them explicitly: what does the reviewer need to approve this, and nothing else. Lecture 04 noted that between fifty and ninety per cent of a technical job is spent on communication tasks. I took that as an argument for taking the course seriously; I now take it as an argument for treating writing as part of the engineering rather than as a reporting layer bolted on afterwards.

3 · LinkedIn

Computer Engineering Student at York University · AI/ML & Full-Stack Developer · 2× National Robotics Champion

linkedin.com/in/ariyan-azami

I am a Computer Engineering student at York University working where machine learning, full-stack development, and embedded systems meet. As a Software Developer at Appli AI I ship backend API endpoints and candidate-facing features on a production AI hiring platform. As a Machine Learning Research Assistant at York's Laboratory of Advanced Biotechnologies I train U-Net segmentation models in PyTorch to detect early disease markers in medical imaging. Before university I competed in national robotics, placing first in the ATF Robotics Cup and second in the FIRA RoboWorldCup as a lead software and systems engineer. That work taught me to build systems end to end, from C++ firmware and custom PCBs through to deployed web applications. I am looking for internship and co-op opportunities in machine learning engineering or full-stack development. My portfolio and project write-ups are at ariyanazami.com.

Visit linkedin.com/in/ariyan-azami

4 · Beyond Engineering

Passion project

Custom quadcopter design & flight

I designed and assembled a quadcopter from individual components rather than a kit: frame and landing gear, brushless motors, electronic speed controllers, a GPS module on a mast, and a flight controller running ArduPilot. Most of the work was not assembly but tuning. A quadcopter is only stable because a closed control loop corrects its attitude hundreds of times a second, and getting the PID gains right meant reading flight logs, forming a hypothesis about which axis was oscillating, changing one term, and flying again. The diagram below is my own drawing of that control loop, and I include it because explaining why the aircraft stays level is a harder communication problem than describing what parts it contains.

Transferable skills

Building this taught me to explain a system by its feedback path rather than its parts list, which is the same instinct that made my technical report clearer: a reader understands a design once they understand what corrects it. Iterative tuning is also disciplined debugging under real consequences, since an untested change costs an aircraft rather than a failed test run.

Custom quadcopter design & flight
Block diagram of a quadcopter flight-control loopPilot stick input enters the receiver and passes to the flight controller, which estimates attitude. The estimate is compared against the setpoint at a summing junction, and the resulting error drives a per-axis PID control loop. The PID output is sent to four electronic speed controllers, which drive the brushless motors. An inertial measurement unit senses the resulting motion and feeds it back into the summing junction, closing the loop.ReceiverRC link, 4+ channelsFlight Controllerattitude estimationΣPID Control LoopP · I · D per axisESCsfour, one per motorMotorsbrushless, 2 CW + 2 CCWIMUgyro + accelmeasured attitudestick inputerrorPWM / DShot3-phase drive
Figure 1 — Closed-loop attitude control on the quadcopter build. The IMU feedback path is what turns an open chain of components into a stabilising control system.

Competitive robotics

I competed nationally in robotics before university, placing first in the ATF Robotics Cup against a field of more than five thousand participants as lead software and systems engineer on a four-person team, and second in the FIRA RoboWorldCup as technical operations manager. My work was C++ firmware on Arduino, custom PCB design in Altium, and integrating real-time sensor feedback into an autonomous control stack. The part that stayed with me was not the engineering but the judging: at both competitions we had a few minutes to explain design decisions to judges who had not seen the robot before and would not see it again.

Transferable skills

Defending a design to a judge on a fixed clock is audience-centred communication with no room to hedge, and it is the closest thing I had to practice for the recorded interview assignment in this course. Competition also taught me to coordinate across mechanical, electrical, and software work, where the main failure mode is not technical but a handoff that nobody wrote down.