Skip to content
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.

Section 01

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?

Yes. This is my best work in the course, and it is best because of how it is built rather than what it covers. The argument is fully evidenced, the document is complete and correctly formatted to IEEE, and the structure does the job I designed it to do: a reader can take the conclusion from the executive summary, test it against the two figures, and find the citation behind any claim without reading the report linearly. The reviewer who flagged an inconsistent register in my draft would not flag the final version, because the fix was structural rather than cosmetic. Its remaining 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. That is now a problem I can name and locate in my own draft, which is the part that transfers: if I revised it again I would cut rather than add, 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, and learning to take a source apart is what later let me build an argument that could survive someone doing the same to me.

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?

It is not my most polished piece, but it is the one that did the most work, and judged on what an annotated bibliography is actually for it succeeds. Each entry summarises, evaluates, and connects a source in a form I could still use three phases later, and the evaluation of the AI Act page is precise enough that I could cite it for authority while arguing in the same sentence that it does not settle the question. If I revised it, I would sharpen two of the four evaluate columns where my criticism lands on a generic weakness of review articles rather than on that specific paper. It earns its place in this showcase because of what it made possible: 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, and unlike a report it gets no second chance with its reader. 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, and solving it here is what made that profile writable.

What this piece says about my development as a communicator

This was written early in the term, and it is the clearest single measurement of distance I can offer. The letter does the hard things a cover letter has to do: it names the role, it maps my work at Appli AI onto the posting's requirement that associates move between front-end and back-end, and it closes by asking for an interview rather than hoping for one. Reading it now with the course finished, I can also see the habit it had not yet shed, which is arguing by adjective where it could argue by example. Being able to diagnose that in my own writing, rather than being told it by a marker, is the development this piece records.

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?

It is the most efficient piece here, and on its own terms it works: one page, one audience, one request, no wasted paragraph, and every claim tied to something I have actually built. It is not my most technically sophisticated writing, and keeping it here rather than replacing it with something newer was a deliberate editorial choice. The distance between this letter and the Phase 4 report is the most concrete evidence of development I can put in front of a reader, and a showcase edited to look uniform would misrepresent what this portfolio is for. The one revision I would make today is to cut the second half of the opening paragraph, which describes IBM to IBM, and spend those lines on a specific feature I shipped.

Sample annotated frame from the ROD-Dataset: a sidewalk scene with labelled bounding boxes around a person, bench, trash can, electrical pole, fire hydrant, manhole, and car.
Technical documentationOutside ENG 2003

ROD-Dataset: public documentation for a 24,326-image obstacle detection dataset

Real-Time Obstacle Detection project · Amirkabir University of Technology · 2026

Why I selected this piece

The dataset card is the communication artifact submitted for this showcase, published on both Kaggle and Hugging Face. I selected it because it is the only piece here whose readers are strangers I will never meet. It documents a dataset of 24,326 annotated images across 25 obstacle classes, built for a system that helps visually impaired and distracted pedestrians detect hazards on a sidewalk using an ordinary Android phone. I am a named co-author on the accompanying paper, and the documentation has to let a researcher who has never spoken to us load the data, understand how it was assembled, and decide whether to trust it. Everything else here was written for a marker who was obliged to read it. This was written for people who were not.

What this piece says about my development as a communicator

It shows me writing for use rather than for assessment. The card leads with what the dataset is and who it is for, then gives structure, splits, class tables, and runnable commands in the order a reader needs them, which is the principle Lecture 06 calls explaining things before presenting them, applied to a technical audience with no obligation to be patient. It also documents the project's limitations honestly, including the long-tailed class distribution we kept deliberately so that compact detectors could still learn rare but safety-relevant classes such as fire hydrants and bicycle racks. Writing down a known weakness so that other researchers can judge it is the same move I had to learn for the Discussion section of my ENG 2003 report.

Did this piece push me out of my comfort zone?

Yes, in a way coursework does not. This is permanent and public: it carries a DOI, an MIT licence, and a citation block, and it has been downloaded several hundred times in the last month by people I will never speak to. A vague sentence in an assignment costs a mark. A vague sentence here means someone loads the data wrong and blames the dataset. Writing while knowing I could not clarify afterwards was uncomfortable in a way no assignment has been.

Is this my best work?

It is the most consequential writing in this showcase, and as documentation it does its job completely: a reader can go from the first paragraph to a training run without asking us anything, which is the only test a dataset card has to pass. The Phase 4 report is the more complete piece of sustained argument; this is the more complete piece of instruction, and the download count is the closest thing to evidence I have that it reads clearly to people I cannot ask. Its limitation is that it is heavily reference-oriented, built from tables, schemas, and file trees, so the reasoning behind our design decisions, such as why we reconciled twenty-six source taxonomies into one 25-class schema instead of keeping them separate, sits in the paper rather than in the card where a practitioner would look for it. That is the revision I would make: one short design-rationale section between the overview and the tables.

Section 02

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 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. What makes the axioms useful is that they describe how communication behaves rather than prescribe how to write, so they explain a failure instead of only forbidding it. Axiom 8, that communication is audience-centred, is the one I keep returning to, because it turns a vague instruction to write well into an engineering question: who reads this, what do they already know, and what must they do afterwards. Once the audience is a constraint rather than a courtesy, revision stops feeling arbitrary.

The course surprised me in a second way. I assumed the difficulty would be producing text; it turned out to be structuring it. Term Project 1 ran across four phases and each failed differently: my annotated bibliography hedged its criticism, my draft buried its conclusion, and the final report only worked once the conclusion moved into the executive summary and every figure earned its place in the surrounding text. None of those are 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. Judged against the 7 C's, that revision bought clarity and conciseness first, and completeness, correctness, and concreteness followed from them: once the structure held, the missing citations, the unsupported generalisations, and the drift in register were obvious rather than buried.

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 connected to Axiom 4, that communication is a principal way of establishing credibility: a systematic review with a documented appraisal protocol reads as more trustworthy than an equally accurate blog post because the protocol is itself a communicative act. Axiom 7, that communication is inherently ambiguous, I met from both directions. It is the subject of my report, since regulators and the public demand that algorithmic systems be fair without a shared operational definition of the word. It is also what happened to me: a peer reviewer read my draft's register as informal where I had read it as plain, and neither of us was misreading the sentences, only weighting them differently. The axiom stopped being a slogan once I had been on the receiving end of it.

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 feedback from three peer reviewers through PeerScholar, and rebuilt the report. Two of the three had been assigned reports on entirely different topics, so parts of their commentary did not describe my document at all. The third engaged with my report directly and told me to confirm every claim was cited 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 reaction to the formal-tone comment was defensive, because I thought the draft already read formally. Both reactions were wrong, and noticing that is the part worth keeping. The draft did contain contractions and informal phrasing, and the advice in the off-topic reviews transferred perfectly well. The feedback I resisted most is 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: the reviewer risks being wrong in writing, and the author risks being seen. Axiom 2, that all communication involves relation as well as content, explains my defensiveness, because I read a comment about tone as a comment about competence. Separating those layers is what let me write Appendix A, 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. Two things still need work. The first is conciseness, the C I most consistently fail: my instinct under uncertainty is to add qualification rather than cut it, and both the Phase 2 draft and the final report's Discussion hedge more than a reader needs. The second is my first reaction to criticism. I acted on the tone feedback, but only after dismissing it, and a reviewer who is right does not become right because I eventually came around.

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 this reviewer need to approve this change, and nothing else. In 7 C's terms that is conciseness in service of clarity, since a description that makes a reviewer hunt for the change has failed even when every sentence in it is correct. Lecture 04 noted that between fifty and ninety per cent of a technical job is spent on communication tasks. I now read that as an argument for treating writing as part of the engineering, not as a reporting layer bolted on afterwards.

Section 03

LinkedIn

Computer Engineering Student at York University · Former Machine Learning Research Assistant at the Laboratory of Advanced Biotechnologies · Applied AI and full-stack development

linkedin.com/in/ariyan-azami

I am a Computer Engineering student at York University, most interested in the point where machine learning stops being a model and becomes something a person has to use. That interest is why I went looking for research rather than waiting for it to be assigned. At York's Laboratory of Advanced Biotechnologies for Health Assessment I worked as a Machine Learning Research Assistant, training U-Net segmentation models in PyTorch to detect early disease markers in medical imaging. At Appli AI I am a Software Developer, building backend API endpoints and candidate-facing features on a production AI hiring platform, where the constraint is not accuracy in a notebook but whether a real user can act on what the system tells them. Earlier I competed in national robotics as a lead software and systems engineer, working in C++ firmware, custom PCB design in Altium, and real-time sensor integration. What I took from it was the habit of building a system end to end and then having to explain it to people who had never seen it before. I am looking for internship and co-op opportunities in machine learning engineering or full-stack development. My portfolio, project write-ups, and communication portfolio are at ariyanazami.com.

Visit linkedin.com/in/ariyan-azami

Section 04

Beyond Engineering

Passion project

Custom quadcopter design and flight

I designed and assembled a quadcopter from individual components rather than a kit: frame and landing gear, brushless motors, electronic speed controllers, and a flight controller. I ran it with two different control stacks, ArduPilot and a DJI controller paired with a GPS module used for positional accuracy rather than autonomous flight, which meant learning the same aircraft twice through two different sets of assumptions. 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 and 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.

Building AI systems at hackathons

Most of my spare time goes into building AI systems that other people can actually use. The clearest example is Prosecuto, built with a team at NVIDIA Spark Hack Toronto: an assistant that helps someone contest an Ontario red light camera ticket. It interviews the user about their ticket, explains the dispute paths open to them, grounds its answers in a local corpus of Ontario legal and procedural documents through a retrieval pipeline, generates a preparation package, and then lets them rehearse against a mock Justice of the Peace before the real hearing.

Transferable skills

The hard problem in Prosecuto was not the model, it was the writing. Our users are people who have never read a disclosure request and are frightened of a courtroom, so every explanation had to be plain enough to act on while staying accurate about what the tool does not do: it prepares you, it is not legal advice, and it cannot promise an outcome. Writing that boundary clearly, in a product rather than an essay, is Axiom 8 with real consequences attached and no marking rubric to enforce it.

Prosecuto on GitHub

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 professional communication this course assesses. 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.

Away from a screen

When I am not building something, I walk and I play basketball. Long walks are where I work out what a piece of writing is actually supposed to say, usually well before I open a document. Basketball is the opposite kind of thinking, fast and shared, and it is a standing reminder that most of a team's decisions are made without anyone stopping to explain them.

Transferable skills

Both are practice in the same thing from different ends. Walking gives me the unhurried time to decide what a reader needs before I start drafting, and a pick-up game is five people coordinating on very little information, where a call that arrives half a second late is the same failure as a document that buries its conclusion.