Four pieces, four communication problems
Each item includes why I picked it, what it shows about my growth as a communicator, whether it stretched me, and an honest call on whether it's my best work.
Why I chose it
This report is the most technically demanding piece I produced this year. It required translating a security-research grand challenge (Bruce Schneier's argument that IoT vulnerabilities can now cause physical, not just data, harm) into a structured technical proposal, backed by five peer-reviewed sources, two figures, and two tables. It's the clearest evidence I have of writing for a skeptical technical audience, a peer review committee.
What it says about my development as a communicator
Producing this report meant balancing depth (five scholarly sources, real evidence) with readability for a non-specialist evaluator. That is the 7 C's in practice, with completeness and conciseness pulling in opposite directions. After two classmates blind-reviewed my draft through PeerScholar, I went back into the introduction and named the human stakes instead of leaving the danger abstract: a tampered medical device, a vehicle trusting a forged command. I also split the paragraphs in Sections 2.2 and 3 that were carrying two distinct claims into narrower ones, but deliberately left the paragraph around Figure 1 alone. It already walked through the verification chain, the attestation loop, and the update path in the same order a reader would trace them on the diagram, so restructuring it would have padded the report rather than clarified it.
Did it push me out of my comfort zone
Yes, on both counts. I'd never synthesized primary peer-reviewed literature into an original argument before; reading five academic sources and building my own claim on top of them, rather than looking up an answer, was new to me. The IEEE-style register was also a shift from how I normally write: my usual documentation is a README or a project update aimed at someone who already shares my context, not a formal report addressed to a skeptical review committee with no reason to take my word for anything.
Is this my best work
Honestly, no. It's the most technically rigorous piece I produced this year, but it's also the most template driven. The structure is dictated by the grand-challenge report format, so it shows less of my own voice than the cover letter does. I'm showcasing it anyway because it's my clearest evidence of handling dense technical evidence for a skeptical audience, which none of my other three pieces test.
Why I chose it
This is my clearest evidence of audience-centered communication, and the only piece in this showcase that works as a controlled experiment. Both handouts argue the same grand challenge from the same four sources, right down to reusing the identical Bruce Schneier quotation ("the particular ways in which computers fail will become the way everything fails"), so every difference between them is a deliberate audience decision rather than a difference in what I knew. It demonstrates Axiom 8 from our Lecture 4 slides directly: "Communication is audience-centred." I chose it because holding the evidence constant is what makes the audience work visible; with any other piece I could claim I adapted to a reader, but here the two versions sit side by side and prove it.
What it says about my development as a communicator
It shows I now adapt at more levels than just simplifying wording. The vocabulary shifts: the section titled "Cyber Shield Knights" for high-school readers is "Defensive Paradigms" for experts. The evidence shifts too, from a kitchen refrigerator, a baby monitor, and a front door unlocking for a stranger in the teen version to buffer overflows in C/C++, failed OTA patching, race conditions in asynchronous actuation, and TLS man-in-the-middle attacks in the expert one. Even the call to action is different: the high-school handout closes by inviting the reader to consider a career in STEM, while the expert handout closes on a research agenda of lightweight cryptography, automated formal verification, and edge-based anomaly detection. That last difference is the one I'm most pleased with, because it means I'd stopped thinking of audience as a reading level and started thinking about what the reader is supposed to be able to do after putting the page down.
Did it push me out of my comfort zone
Yes. I hadn't really done layout work like this before. Structuring information visually (what becomes a callout box, what becomes a caption, how much white space a teenager's attention span needs versus an expert's) was a different skill than writing paragraphs, and I leaned on trial and error more than I expected to.
Is this my best work
Half of it is. The high-school version came more naturally: I'm used to explaining technical ideas to people without a specialized background (friends, family, the students I taught in robotics workshops), so writing for a reader who needed the concept built up from scratch felt closer to a habit than a stretch. The expert-audience handout is where I actually had to work, since I couldn't lean on that same simplification, and it's the half with the most room left to improve.
Why I chose it
A cover letter is the highest-stakes short-form persuasive writing I've done this year: one page, a reader who owes me nothing and will skim, and every sentence having to build credibility fast with zero wasted words. I chose it over a longer piece precisely because the constraint is unforgiving. The technical report could absorb a weak paragraph, whereas here a single unearned claim costs the reader's trust for everything after it. It's also the only showcase item where I am the subject, so the ethos has to come from evidence rather than assertion: the ZUIX INC. paragraph works because it names what I actually shipped (the company's first website, React and Next.js, business requirements translated into a working product), not because it calls me experienced. And it's the one piece where I had to argue against a fact the reader could hold against me, which is the hardest persuasive problem in the set.
What it says about my development as a communicator
It shows I can shape real experience (leading web development at ZUIX INC., independent projects in React, Next.js, and FastAPI) into a concise, employer-relevant narrative rather than a list of facts. Earlier in the year I would have tried to fit everything in; writing this letter taught me that choosing what to leave out is most of the work, and that one specific, verifiable claim builds more credibility than three vague ones. The graduation-year decision shows the same growth. By that point I'd learned enough about how a skeptical reader thinks to know that addressing the mismatch myself would read as confidence, while silence would read as evasion.
Did it push me out of my comfort zone
Not exactly uncomfortable, but genuinely difficult in a different way: the hard part wasn't self-promotion, it was selection. Between leading ZUIX's web development, tutoring, and several independent projects, I had more material than a one-page letter could hold, and figuring out which experiences actually mattered to an IBM hiring manager and cutting the rest took more editing than any paragraph in the technical report.
Is this my best work
Yes. This is the piece where every sentence had to earn its place, and naming the graduation year mismatch directly, rather than hoping no one would do the math, is the choice I'm proudest of. It would have been safer to leave it out. Addressing it head on took more nerve than anything I wrote in the technical report.
The documentation itself
The communication artifact for this project isn't the device. It's the README, which has to make the device rebuildable by someone who wasn't in the room:
"The project was planned multiple times. Each iteration refined our requirements, logic flows, and hardware specifications. We transitioned from simple state diagrams to a complex state machine that handles phone detection, user presence, and task management seamlessly."
"Each prototype was tested for light-leakage (phone detection) and sensor accuracy, leading to the final robust version."
Why I chose it
It's the one item this year where I had to communicate a design process rather than present a finished artifact: diverging and converging thinking, iterative prototyping, and hardware/software integration, explained first to a team and then to evaluators. It's also the only piece where the writing had to survive being handed off, in a report and README written so that the sensor logic, the state machine, and the enclosure revisions make sense to someone who never touched the build. Every other item in this showcase argues a point to a reader; this one has to make a physical thing reproducible, which is a different and harder standard.
What it says about my development as a communicator
Documenting a multi-iteration hardware project (state machines, sensor logic, enclosure revisions) in a README and report format shows I can write technical documentation clearly enough that someone could rebuild the project from scratch. It also shows I'd started thinking about figures as arguments rather than decoration: the annotated prototype photo above exists because a paragraph describing where the light sensor sits relative to the phone slot would have been slower and less certain than a labelled image.
Did it push me out of my comfort zone
Communicating within the team was actually the easier part. We brainstormed well together, diverging on ideas and converging on one design. What was harder was translating that agreed upon design into a working prototype: drawn ideas didn't always survive contact with real sensors and enclosures, so I went through several trial and error rounds on the hardware and software myself to close that gap.
Is this my best work
It's a harder call than the others because the credit is shared. Most of the final hardware and software design, and the trial and error that got it working, was carried by me, since the rest of the team wasn't as consistently hands-on as I'd have liked. I ended up doing a fair amount of leading just to keep the project on schedule, which is its own kind of communication work, even if it doesn't show up on the page.