COMMST 192: Communication in the Engineering Profession

Sources and References

Primary textbook — Mike Markel, Technical Communication (Bedford/St. Martin’s). Supplementary texts — Lannon & Gurak Technical Communication; Joseph Williams Style; Crowley & Hawhee Ancient Rhetorics for Contemporary Students; Edward Tufte The Visual Display of Quantitative Information. Online resources — Purdue OWL; MIT OCW 21W.732 Science Writing; ACM/IEEE author guidelines.

Chapter 1 — Communicating Science and Engineering to Diverse Audiences

Engineering is often advertised as a field of calculations, CAD files, and code commits, but the real deliverable is rarely the artifact itself. It is the story told about the artifact: the design review deck, the failure-analysis memo, the pull-request description, the letter to a regulator, the patent disclosure, the conference paper, the Slack thread at 2 a.m. when a production cluster is smoking. An electrical engineer who cannot explain why a power rail oscillates, a computer engineer who cannot justify a new cache-coherence protocol, a management engineer who cannot persuade a steering committee that an ERP migration will pay for itself — all of them are unable to do their jobs. Mike Markel opens his Technical Communication by pointing out that technical professionals spend between a quarter and half of their day writing or speaking, and the higher they rise the more that fraction grows. Lannon and Gurak put it more bluntly: a design that cannot be explained does not exist.

“Communicating science” is not one act but a family of acts aimed at very different audiences. The field engineer installing a board-level fix, the marketing director sizing a new product line, the municipal council voting on a smart-grid contract, and the reviewer assessing your IEEE paper all need radically different documents from the same underlying technology. A textbook-style analysis of audience, purpose, and genre is therefore not an optional soft-skill sprinkle on top of your engineering education; it is the operating system every other deliverable runs on.

Technical communication also has a civic dimension. When an autonomous vehicle kills a pedestrian, a power grid collapses in a heat wave, or an AI hiring tool quietly discriminates, the public investigation that follows is conducted largely through documents. Engineers who wrote clearly, with honest uncertainty, come out of those investigations very differently from engineers who buried risks in jargon. Justin McBrayer’s Beyond Fake News argues that in a saturated information environment, credibility is earned not by the loudest claims but by the ones that survive scrutiny. Engineers are, among other things, professional scrutiny-survivors.

This course will push you to see writing as a form of engineering: it has requirements, constraints, failure modes, test plans, and revision cycles. When Joseph Williams writes that clarity is the result of sustained effort and not innate talent, he is describing something any software engineer already believes about good code. The goal is not to become a novelist but to become the kind of engineer whose documents do not need to be rewritten by someone else.

Chapter 2 — Rhetoric: Ethos, Pathos, Logos, and the Logic of Argument

Rhetoric is the oldest systematic study of persuasion, and Crowley and Hawhee’s Ancient Rhetorics for Contemporary Students pulls its vocabulary straight from Aristotle: ethos (character and credibility), pathos (emotion and stake), and logos (evidence and reasoning). Every technical document that fails to convince its reader is failing one of those three appeals, and naming the failure is the first step to fixing it.

Ethos rests on who is speaking. Engineers earn ethos by demonstrating competence, showing their work, admitting uncertainty honestly, and crediting collaborators. They lose it by overstating results, hiding failures, or borrowing someone else’s data without attribution. In open-source communities ethos is tracked explicitly through commit history, code-review comments, and README clarity. In peer review, ethos is whether reviewers recognize your methods and trust your error bars. For an engineer, ethos is not charisma; it is a reputation for being careful.

Pathos is the appeal to emotion, and engineers are often nervous around it because it seems manipulative. Crowley and Hawhee argue pathos is not manipulation but the act of making the audience feel the stake of a problem. A report that dryly states “the existing PDU will be overloaded by 2027” moves nobody. The same report that opens with “if we do nothing, the hospital’s emergency imaging suite will lose power during the next heat wave” gets funded. Pathos becomes unethical only when it substitutes for evidence or exaggerates risk.

Logos is the appeal to reason, where load calculations, simulation traces, benchmarks, and citation graphs live. But logos is not just “having data” — it is the structure of reasoning that connects data to a claim. Stephen Toulmin’s model breaks an argument into claim (the thing you want accepted), grounds (the evidence you offer), and warrant (the rule of inference that connects them). Engineers get tripped up when the warrant is implicit — when they assume the reader shares a mental model that the reader does not. Making the warrant explicit is the single biggest readability win in a technical argument.

A strong technical document braids all three appeals. Consider a post-mortem memo: ethos establishes that the on-call engineer knows what she saw, pathos reminds the reader that customers could not check out for eleven minutes, logos walks through the packet captures. Drop any one and the memo loses its grip. Rhetoric is the structural engineering of prose.

Chapter 3 — Facts, Evidence, Opinion, and the Ethics of Claims

McBrayer’s Beyond Fake News asks what separates a justified belief from an unjustified one, and is direct about the answer: evidence that is public, replicable, proportionate to the claim, and free of easy counterexamples. Engineers implicitly accept this standard — we do not trust a benchmark that cannot be reproduced or a measurement whose error bars are missing. The problem is that engineers do not always extend the same standard to their own prose.

Distinguish three categories that technical writers often blur. A fact is a proposition whose truth value can be independently checked (the peak current on VDD12 was 4.7 A; the regression suite passed with 99.8 percent coverage). An inference is a claim derived from facts by a chain of reasoning (because the peak current exceeded the 4.5 A rating, the MOSFET entered thermal runaway). An opinion is a judgment from a standpoint, usually shorthand for claims about values or priorities (the risk of thermal runaway is unacceptable for a medical device). Trouble arises when opinions are dressed as facts, inferences are asserted without their chain, or facts are given confidence their source cannot support.

Evidence quality matters more than quantity. A single measurement from a calibrated instrument beats twenty anecdotes; a pre-registered study beats a data-mined one; a peer-reviewed paper beats a vendor whitepaper; a reproducible script beats a screenshot. Being honest about where your evidence sits on this hierarchy is a matter of professional ethics. ACM and IEEE author guidelines require authors to disclose conflicts of interest, flag speculation, and avoid selective reporting. That is applied McBrayer.

The workplace has its own hazards. Hype inflation (“breakthrough,” “revolutionary”) has become so common that ordinary descriptive language now sounds understated. Cherry-picking benchmarks — reporting only the workloads your chip wins — is a well-known failure mode that has prompted conferences like ISCA and MICRO to demand standardized suites. Treat every unqualified superlative as a bug. If a claim cannot be written as an empirical prediction that could in principle be falsified, it does not belong in a technical document.

Chapter 4 — Audience, Purpose, and Genre

Markel organizes Technical Communication around a three-legged stool: audience, purpose, and genre. Figure out who you are writing for, what you want them to do, and which conventional form will carry that intent, and the rest is execution. Get any of the three wrong and the document feels subtly off even when every sentence is grammatical.

Audience analysis begins with identifying who will actually read the document, which is almost never one person. A feasibility report to a municipal council is read first by staff engineers, then by councillors, then by journalists, then by opposing consultants searching for errors. Lannon and Gurak recommend profiling readers on four axes: technical background, role (decision-maker, implementer, operator, maintainer), stake in the outcome, and attitude. Primary, secondary, tertiary, and “shadow” audiences all matter. Designing one document that serves all those layers is why professional technical writing uses conventions like executive summaries, layered headings, and appendices — they are tools to serve multiple audiences from a single source.

Purpose is what you want the audience to know, do, or decide. If you cannot state the purpose in one sentence beginning with a verb (“approve the revised BOM,” “implement the retry logic below,” “understand why the test fleet was grounded”), the document is not ready to write. Purposes fall into informing, instructing, persuading, and recommending, and they overlap, but a document with no primary purpose sprawls.

Genre is the conventional form the audience expects. Genres are tacit contracts: a memo wants a heading block and a subject line; an IEEE paper wants an abstract, numbered sections, and bracketed references. Violating the contract wastes reader attention. Engineering is rich with specialized genres — the bug report, the RFC, the PRD, the ECN, design-review minutes, HAZOP studies, post-mortems — and learning them is part of entering the profession.

A useful exercise from MIT’s 21W.732 is to take one body of technical work — say, a week’s lab results on a new op-amp — and write it as a lab notebook entry, a status memo, a design-review slide, and a conference-paper results section. Content identical; rhetorical shape completely different.

Chapter 5 — Workplace Communication: Email, Memo, Slack, and Meetings

Most of the writing an engineer will do in their career is workplace communication — the steady background radiation of emails, memos, chat messages, and meeting notes that keeps a team moving. It is also the writing most likely to be underestimated by new engineers, who treat it as throwaway and therefore produce a lot of avoidable friction. Markel devotes an entire chapter to it and so should you.

Email remains load-bearing in most engineering organizations. The craft is respecting the reader’s inbox. Write a subject line that names the topic and whether action is needed (“Action needed by Fri: review BOM v3”). State your request in the first two sentences; assume nobody scrolls. Use bulleted lists for anything list-shaped. Name attachments and remind the reader what they contain. Close with a clear next step, deadline, and owner. Avoid passive-aggressive “per my last email” cousins. If a thread passes five or six messages, a meeting or shared document is faster than another reply-all.

Memos establish a record. They use a standard header (To, From, Date, Subject), an opening that states the purpose, discussion sections with headings, and a closing recommendation. Treat every memo as something a future investigator or auditor might read — that is what “establishing a record” means. Trip reports, lab reports, and decision memos are all memos.

Slack and Teams feel casual but are still written communication in a public record. Put context up front — do not ping “hey, got a minute?” and make someone wait. Use threads to keep conversations scoped and searchable. Summarize decisions: when a thread resolves an issue, the last message should state what was decided and who will do what. Voice and video calls follow the same rule: a decision on a call did not really happen until someone wrote it down.

Meetings are a rhetorical act. Send an agenda in advance, start on time, identify a notetaker, reserve the last five minutes for decisions and action items, and send the notes within a day. Meetings that could have been documents should be documents; write a shared doc, comment asynchronously, and meet only for what the doc cannot resolve.

Chapter 6 — Leading and Misleading the Audience, and Reporting Technical Information

Good technical writing leads the audience through complex material without deceiving them. Bad technical writing does the opposite, sometimes deliberately, more often by accident. Daniel Kahneman’s Thinking, Fast and Slow is not a communication textbook, but it is indispensable here because it catalogues the cognitive shortcuts on which both the honest leading and the dishonest misleading of readers depend. Knowing those shortcuts is how an ethical engineer avoids stepping on them.

Kahneman distinguishes System 1 (fast, intuitive, pattern-matching) from System 2 (slow, deliberative, rule-based). Technical audiences, even expert ones, read first with System 1: they scan headings, look at figures, latch onto familiar numbers, and form an impression long before they have parsed the prose. Ethical writers design for this by making the System-1 impression match the System-2 conclusion. The headline finding on the first page should be the same finding a careful reader reaches on page thirty. Dishonest writers exploit the gap by putting favorable numbers in large type and caveats in footnotes, framing a 3-percent-better benchmark as a “step change,” or showing a y-axis that starts at 94 percent so a 1-point difference fills the chart.

“Framing effects” — the way a numerically identical fact feels different depending on presentation — are the workhorses of misleading prose. A 1-in-1,000 failure rate and a 99.9-percent success rate describe the same component, but they produce different gut responses. An engineer writing a reliability report for a regulator should pick the framing that is most faithful to the decision being made, not the one that flatters the product. Tufte, in The Visual Display of Quantitative Information, calls the same behaviour in graphics “lie factors” — the ratio between the visual impression a chart makes and the underlying numeric change. A lie factor above about 1.05 is a red flag; above 2, you are in the territory of graphical dishonesty.

With those cautions in mind, the mechanics of reporting technical information become clearer. Markel’s generic technical report structure — front matter (title, abstract, executive summary), introduction and background, methods or approach, results, discussion, conclusions and recommendations, references, appendices — is not an arbitrary layout; it is a staircase that leads a time-pressed reader from the System-1 impression down through the System-2 reasoning in roughly the order they need. The executive summary lets the decision-maker stop after a page. The introduction lets a peer technical reader understand the problem without opening prior art. The methods section lets a skeptic reproduce you. The results present data before you interpret them. The discussion is where you argue, within the limits the data allow. The appendices are where you stash the raw materials so that the honest reader who wants to check you can. Every section has an audience and a purpose, and skipping any of them leaves some audience unserved.

Good reports also handle uncertainty honestly. Distinguish measurement uncertainty (how precisely you know a quantity) from model uncertainty (how well your equations represent reality) from scenario uncertainty (what will actually happen). Use confidence intervals, not just point estimates. Name the assumptions that would overturn your conclusion if wrong. Engineering history is littered with disasters — Challenger, Fukushima, Boeing MCAS — where the technical report did contain the bad news but buried it under confident-sounding language. The writer’s job is to make the bad news as legible as the good news.

Chapter 7 — Researching Technical Subjects

Research in an engineering course is often reduced to “find ten sources and cite them,” but the real skill is quite different: it is the ability to locate the state of the art on a technical question, triangulate claims, and build a credible foundation for your own argument. In the computer and electrical engineering world this means knowing how to navigate a small ecosystem of specialized tools.

The baseline resources are IEEE Xplore (journals, conference proceedings, standards), the ACM Digital Library (computing conferences and SIGs), Google Scholar (cross-discipline coverage and citation tracking), and the preprint servers — arXiv for most CS and EE work, SSRN for management-engineering topics, and increasingly TechRxiv for engineering more broadly. For standards you will need IEC, ISO, IEEE, NIST, and your own domain’s authoritative bodies (3GPP for cellular, IETF RFCs for internet protocols, JEDEC for memory, and so on). For historical context and foundational textbooks, institutional library catalogues remain indispensable. Purdue OWL and most university libraries maintain excellent research guides that walk you through database-specific search operators.

A productive literature search is iterative. Start with a broad query to identify landmark papers, then follow citations in both directions: the papers the landmarks cite (which give you lineage) and the papers that cite them (which give you current frontier). Read abstracts and conclusions first, decide whether the full paper is worth your time, and only then dive in. Keep a running bibliography from day one — a tool like Zotero or BibTeX will save you hours at submission time. Take notes in your own words as you read; copying verbatim is the root cause of most accidental plagiarism.

Evaluate sources using a short mental checklist. Who is the author and what is their institution? Is the venue peer-reviewed, and if so by whom? Is the work reproducible — are code, data, or methods available? How recent is it, and has the field moved? Has anyone rebutted it, and if so how was the rebuttal received? A vendor whitepaper can be a perfectly fine source if you acknowledge its provenance and corroborate its claims; a top-venue paper can be a weak source if its results have failed to replicate. McBrayer’s standard applies: weigh evidence in proportion to its credibility, not its convenience.

Avoid the “Wikipedia problem” without misunderstanding it. Wikipedia itself should not be cited in a technical report, but its reference sections are excellent starting points, and its “Talk” pages sometimes reveal exactly the controversies a first-time researcher needs to know about. Treat it as a map, not a destination. Similarly, large-language-model chat tools can be useful for orienting yourself in an unfamiliar area but cannot substitute for reading primary sources, because they are neither accountable nor reliably up to date. If you use an LLM to summarize a paper, verify every factual claim against the original.

Finally, citation is a form of ethics and a form of ethos. Cite every idea, number, or phrase you borrow. Use a consistent style — IEEE numerical for EE and CE work, ACM reference format for CS conferences, APA or Chicago if your venue demands it. Quote sparingly and only when the original wording matters; paraphrase the rest. When you paraphrase, restate the idea in sentence structures genuinely different from the source. Self-plagiarism — recycling your own prose across submissions without disclosure — is a real professional offence in research and you should learn to avoid it early.

Chapter 8 — Visual Communication and Information Design

Edward Tufte’s The Visual Display of Quantitative Information is the closest thing to scripture that data-graphics design has. His central claim is that a good chart maximizes the ratio of data-ink to total ink: remove everything on the page that is not carrying information about the numbers, and what remains should be as dense, as precise, and as honest as possible. Engineers often produce the opposite — slide decks full of 3D pie charts, pastel gradient backgrounds, spurious drop shadows, and y-axes chopped to exaggerate differences. Tufte would call most of that “chartjunk” and ask you to remove it.

A few practical rules distilled from Tufte, Markel, and the conference-paper literature will get you most of the way. First, use line charts for trends over a continuous variable (latency vs. load, voltage vs. time), bar charts for comparisons between discrete categories, scatter plots for relationships between two variables, and tables for small numbers of precise values readers may need to quote. Pie charts are almost never the right choice — humans read angles badly. Second, label axes with both the quantity and its unit, and annotate directly on the graphic when you can instead of forcing readers to translate between a legend and the plot. Third, start y-axes at zero unless there is a good reason not to, and if you truncate the axis say so explicitly. Fourth, use color functionally — to distinguish categories, highlight a line of interest, or encode a scalar — not decoratively. Make sure the color scheme is legible to readers with color-vision deficiencies and in greyscale print.

Information design extends beyond data graphics. It includes the layout of your document, the hierarchy of your headings, the spacing of your tables, the figures in your technical descriptions, and the diagrams in your instructions. Markel’s rule of thumb is that every visual element in a technical document should do work: introduce it in the text, place it as close as possible to its first mention, caption it with a full sentence explaining what the reader should see, and refer back to it when you draw conclusions. A figure without a caption, or a caption that only says “Figure 3: Results,” is a missed opportunity; a good caption is often the first thing a scanning reader reads and may be the only thing they remember.

Schematics, block diagrams, state machines, sequence diagrams, and timing diagrams are the specialized visual genres of computer and electrical engineering. Each has its own conventions. UML sequence diagrams have a canonical vocabulary for lifelines, activations, and asynchronous messages. Timing diagrams have conventions for rising and falling edges, setup and hold times, and bus annotations. Schematics have conventions for component symbols, reference designators, net names, and pin numbering. Using these conventions well is part of demonstrating ethos: a reader who sees a correct and clean schematic understands immediately that the author knows what they are doing.

Slide design for oral presentations follows the same principles but with higher bandwidth constraints. A slide is seen for twenty to ninety seconds. If it contains a paragraph of text, the audience reads instead of listening. If it contains a chart, the chart needs to be big, annotated, and honest. MIT’s 21W.732 recommends the “assertion-evidence” style pioneered by Michael Alley: the slide headline is a full-sentence claim, and the body of the slide is the evidence for that claim — usually a single large figure. That style forces every slide to have a point, which is most of the battle.

Chapter 9 — Technical Descriptions and Instructions

Technical description and instruction are the genres where engineering prose is most directly tested against reality. A description explains what something is; an instruction explains how to do something with it. Both live or die by the reader’s ability to form an accurate mental model quickly.

Descriptions come in two flavors: of objects and of processes. An object description — say, of a new network interface card — typically proceeds from general to particular: the function and context of the object, a labeled exploded-view figure, a walkthrough of each major part with its purpose, key specifications in a table, and a note on variants. A process description — say, how packet classification works in a programmable switch — follows the chronology of the process with clear stage markers, block diagrams, and worked examples for edge cases. Good descriptions are often accompanied by a glossary of terms defined on first use, and they resist the temptation to editorialize: a description describes, it does not yet persuade. That said, the choice of what to describe and what to omit is itself rhetorical, and honest descriptions do not quietly drop inconvenient features.

Instructions have higher stakes because the reader is acting on them in real time, possibly with safety implications. Markel’s practical guidance, echoed by every usability study ever done, is to keep each step to a single action expressed in the imperative mood (“Connect the JTAG probe to header J4”), to number steps in the order they must be performed, and to front-load any warning that could prevent injury or damage (“Before powering the board, verify that jumper JP2 is set to 3.3 V”). Distinguish notes (supplementary information), cautions (damage to equipment), warnings (injury to people), and dangers (risk of death or serious harm) using consistent typography and icons. Test your instructions with someone who has not seen them before — watch silently as they work through the steps, and every hesitation is a rewrite flag. Software documentation follows the same principles in a different idiom: README files should walk a first-time user from clone to “hello world” in under ten minutes, with every command block copy-pastable and every prerequisite stated.

Write instructions for the actual physical or computational environment in which they will be used. A wall-mounted reference poster for a clean-room fab is different from a PDF read on a laptop, which is different from an interactive web tutorial. Consider whether your reader has both hands free. Consider whether they can zoom in on a diagram. Consider the lighting, the noise level, the stress. Lannon and Gurak stress that technical writing is always writing for embodied people doing real work, and instructions make that truth impossible to ignore.

Chapter 10 — Feasibility and Recommendation Reports

The feasibility or recommendation report is one of the most consequential genres in the engineering profession because it is the genre in which real money gets committed. It asks and answers the question: should we do X, and if so, how? The form is codified in most technical-communication textbooks into a recognizable shape.

A feasibility report opens with an introduction that names the problem or opportunity and the decision the report is meant to inform. It continues with background — the relevant history, existing systems, prior attempts, regulatory constraints. It then presents criteria — the yardsticks against which options will be measured, explicitly and before any option is evaluated. Typical criteria for an engineering decision include technical feasibility (can we build it?), economic feasibility (can we afford it and will it pay back?), schedule feasibility (can we deliver it in the available time?), regulatory and legal feasibility (are we allowed to build it?), and environmental or social feasibility (should we build it?). The order of criteria often signals your values, so choose carefully. After criteria, the report evaluates each option against each criterion, usually with a comparison matrix to help the reader scan. Then it draws conclusions about what the evidence shows, and finally makes recommendations — concrete, actionable, with an owner and a timeline.

The discipline of stating criteria before evaluating options is the single most important move in the genre. It prevents the motivated reasoning that happens when you decide the answer first and then hunt for supporting data. It also gives the reader a way to disagree productively: a reader who rejects your conclusion is forced to either contest a criterion or contest an evaluation, both of which are more tractable than an unstructured argument.

Common failure modes in student and junior-engineer feasibility reports include burying the recommendation (if the reader cannot find your bottom line in thirty seconds they will distrust the whole thing), presenting one option instead of comparing several (a comparison of one is not a comparison), using fuzzy criteria like “ease of use” without operationalizing them, and allowing cost to eat every other criterion (cost matters, but a report whose only criterion is cost is a purchase order, not a recommendation). Good feasibility reports also acknowledge when the answer is “we do not yet know” and recommend a scoped investigation — a pilot, a spike, a proof of concept — as a legitimate outcome.

A closely related genre is the recommendation report, which shares the same structure but is usually shorter, is framed around a specific proposed action, and assumes that the feasibility question has largely been answered already. The emphasis moves from “can we?” to “how do we best?” Both genres end with an executive summary and a clear call to action.

Chapter 11 — Oral Presentations: Planning, Delivery, and Aids

Most engineering students approach oral presentations as a special and more terrifying version of writing. They are in fact a different medium with different affordances, and the textbooks that treat them seriously — Markel, Lannon and Gurak, MIT’s 21W.732 materials — converge on a fairly consistent set of principles.

Plan first. Ask the usual audience-purpose-genre questions: who is in the room (or on the call), what do they already know, what do you want them to do or think when it is over, and what is the conventional form of talk expected — a conference paper presentation, a design review, a stand-up demo, a lightning talk, a job talk? Each has different norms for length, slide density, and formality. Build the talk from the purpose outward: state your thesis in one sentence, identify the three or four supporting points that an audience would need to believe to accept the thesis, and draft the talk around those points. Resist the engineer’s temptation to replicate the structure of your written paper; oral presentations follow a different arc because the audience cannot rewind.

Structure the talk as a story with a clear beginning, middle, and end. The opening should establish stakes and orient the audience quickly: what problem, why it matters, what you did, what you found, roughly. (Yes, you are “spoiling” the talk on purpose — in technical talks it is considered good practice, because an audience that knows where you are headed can follow the reasoning more easily.) The middle walks through the supporting evidence, each point announced, developed, and summarized. The end recapitulates the thesis, acknowledges limitations, and invites questions. Transitions between sections should be explicit (“that was the algorithm; now let me show you how it performed on real traffic”). In a twenty-minute talk, plan for roughly fifteen minutes of speaking and five of questions; in a conference-paper slot you will have less room.

Slides are aids, not teleprompters. Alley’s assertion-evidence format — full-sentence headlines and a single supporting graphic — works very well for technical content. Minimize text, maximize readable figures, label axes, and use high-contrast colors. Do not read your slides out loud; the audience can read faster than you can speak, and they will resent being trapped while you do it. If you need speaker notes, put them in the notes field, not on the slide.

Delivery is where students most often underestimate the work. Practice aloud, not silently, at least three times — the first run will be slower than you expect. Practice with a timer. Practice the transitions, which are the places most likely to fall apart. Think about your body: stand where the audience can see you, face them (not the screen), breathe, and speak loudly enough for the back of the room. Eye contact does not need to be uniform — pick three or four friendly faces and rotate among them. Handle questions by listening to the whole question before answering, repeating it if the room is large, and answering concisely. If you do not know the answer, say so and offer to follow up; audiences are far more forgiving of honest ignorance than of confident bluffing. Confidence in a technical talk is not the absence of nervousness; it is the visible impression that you have done your work and are ready to defend it.

Chapter 12 — Writing in Teams

Most engineering writing is done collaboratively, often under time pressure, often across time zones. Collaborative writing is its own craft, and doing it badly can destroy a document that any of the individual writers could have produced alone.

Markel and Lannon both recommend starting with an explicit document plan before anyone writes a word. The plan fixes the purpose, audience, genre, rough outline, length target, tone, and deadline. It assigns sections to owners and identifies who will review each section. It names a single editor whose job is to unify voice at the end. A half-hour spent on a document plan saves days of rework later. For a team unfamiliar with each other’s styles, the plan should also specify small conventions: serial comma or not, “e.g.” or “for example,” British or American spelling, figure numbering scheme, reference format. These micro-decisions are trivial individually but maddening to resolve in the final edit.

Version control is the single biggest workflow choice. Most engineering teams now write collaborative documents in Google Docs, Microsoft 365, Overleaf, Notion, or a git-managed Markdown or LaTeX repository. Each has trade-offs. Cloud document tools (Google Docs) give you real-time co-editing and excellent commenting but weaker branching. Repository-based tools (git + Markdown or LaTeX) give you real version history, diffs, and pull-request review, which are the gold standard for technical documents intended for publication or long archival life. Whichever you choose, pick one and stick to it for the document — mixing half the team on a shared doc with the other half on git is a recipe for lost work.

Division of labor generally takes one of three shapes. In sequential writing, one person drafts, then another, then another — suitable for short documents. In parallel writing, each person owns a section and writes in parallel — suitable for reports with naturally separable parts. In stratified writing, different people handle different aspects of the same text (one drafts, one edits, one does figures, one does references) — suitable for documents with high production value like conference papers. Most real projects blend all three. Whichever pattern you use, agree on it explicitly.

Peer review inside the team follows the same ethic as good code review: review the document, not the author; be specific and actionable; distinguish between preferences and requirements; praise what works before pointing out what does not; and return comments quickly so the draft does not stall. A team that can run a fast, kind, substantive review loop will outperform a team of stronger individual writers who cannot.

Team writing also surfaces authorship and attribution questions. Most professional venues (IEEE, ACM) have explicit authorship criteria — usually something like substantial contribution to design, execution, or analysis, plus substantial contribution to drafting or critical revision, plus agreement with the final version. “My name on a paper I did not read” is an ethics violation. Discuss authorship order and acknowledgments early, not at submission time, and record the conversation so nobody is surprised.

Chapter 13 — Résumés, Cover Letters, and the Engineering Job Search

The job application packet is the single document set that returns the highest cognitive-effort-per-word investment of any writing you will do in school. A résumé, a cover letter, and, increasingly, a short portfolio or LinkedIn profile are the artifacts a stranger will read in less than thirty seconds to decide whether to spend an hour interviewing you. Treat them as real technical documents: audience-aware, purpose-driven, honest, and clean.

A résumé for a computer, electrical, or management engineering student is typically one page, occasionally two for a student with substantial experience. It is not a biography; it is a filtered argument that you are a plausible fit for a specific job. A common and workable structure: header with your name and contact information and — for engineers — links to GitHub, a portfolio, or a LinkedIn profile; a short technical skills summary (languages, tools, hardware, frameworks); an education block with degree, institution, graduation year, and a short list of relevant coursework or a GPA if strong; a work experience section with each position giving title, employer, dates, and three to five bullets; a projects section for personal or course work that is substantial; and, optionally, a line for publications, awards, or leadership. Each bullet should open with an action verb in the past tense, describe a specific action, and name a measurable outcome when possible — “Reduced microservice tail latency from 420 ms to 85 ms by rewriting the retry logic with exponential backoff, serving 2 M daily requests” beats “Worked on backend performance.” Avoid vague self-evaluations (“team player,” “detail-oriented”); show, do not tell.

Tailor the résumé to the job. If the posting emphasizes embedded Linux, the bullets that demonstrate embedded Linux should migrate up and expand. If the posting emphasizes high-scale data systems, those projects move up. Most large employers use applicant-tracking systems that match your résumé against keywords from the posting — this is not a reason to stuff keywords artificially, but it is a reason to use the same vocabulary the posting uses when describing skills you actually have. Formatting should be clean and text-extractable: plain typography, standard section headings, no embedded graphics or tables, one column. PDF is the default. Spelling and grammar errors are disqualifying at this stage — read every word aloud before submitting.

The cover letter is where many engineering students miss an opportunity. A good cover letter is short, specific, and answers three questions the reader has: why do you want this job (not just any job), why are you plausible for it (the one or two strongest pieces of evidence, not a résumé recap), and what do you want to happen next. It is written in paragraphs, addressed to a real person when possible, and uses the tone of a respectful peer rather than a supplicant. Open with a specific hook — a detail about the company, a project of theirs you admire, a problem you want to help solve — not with “I am writing to apply for…”. Close with a confident, concrete next step. One page, three or four paragraphs, is plenty.

Portfolios matter more and more in computer and electrical engineering. A well-curated GitHub profile with a handful of real projects — each with a clear README, test suite, build instructions, and a short explanation of what you learned — is worth a dozen lines of résumé bullets. Do not pad with tutorial clones; one substantial, documented project beats twenty half-finished ones. If you have done hardware projects, photographs of the boards and waveforms matter; if you have done firmware, code and a video of it running matter; if you have done data analysis, notebooks and charts matter. Tell the reviewer what to look at first.

Interviews are an oral-communication genre that this course can only gesture at. The connection to everything earlier in the term is nevertheless tight. Rhetoric applies: establish ethos by telling true, specific stories about your work; appeal to pathos by letting your actual enthusiasm for the problem show; use logos by being able to walk through your reasoning and name your assumptions. Audience analysis applies: learn what the company does, who will interview you, and what they likely care about. Technical description and instruction apply: be able to explain a past project to someone who has never heard of it, adjusting depth to their background. After the interview, send a short thank-you note within a day — not because it changes the decision, but because it is a final, low-cost act of professionalism and, occasionally, an opportunity to clarify something you wish you had said better.

Chapter 14 — Editing, Style, and Revision: A Closing Note

Joseph Williams’ Style: Lessons in Clarity and Grace is the book every engineer should keep within arm’s reach. Its central insight is that clarity is not a matter of “simplifying” or “dumbing down” but of aligning sentence structure with reader expectations. Williams’ two headline principles are that readers expect the subject of a sentence to be the character who is acting, and they expect the verb to name that character’s main action. Technical writers systematically violate both principles by hiding actions inside noun phrases (“the implementation of the algorithm was performed” instead of “we implemented the algorithm”) and by using abstract subjects (“the determination was made” instead of “the committee decided”). Fix those two patterns and roughly half of your prose becomes clearer overnight.

A few further rules of thumb: prefer active voice by default but use passive voice when the actor is unknown, obvious, or beside the point; prefer short sentences but vary length enough to avoid a jackhammer rhythm; put old information at the beginning of a sentence and new information at the end, so each sentence hands the reader a thread to pull on; use transition words (“however,” “therefore,” “in contrast”) sparingly and only when the logical relationship they name is real. Avoid empty intensifiers (“very,” “really,” “clearly”) that weaken the claim they modify. Avoid hedging stacks (“it would perhaps seem that it might possibly be the case that”) that drain a sentence of force. Purdue OWL has a deep catalogue of exercises on these patterns.

Revision, finally, is where technical writing becomes good. First drafts are for discovering what you think; second drafts are for saying it to yourself clearly; third drafts are for saying it to the reader clearly. Build time for all three into your schedule. Read drafts aloud — your ear catches what your eye glides over. Put the draft away for a day if you can; you will return as a different, more critical reader. Ask a colleague to read and mark the places where they paused, reread, or got confused; those are the places to rewrite, not the places where they disagreed with your conclusion. Keep a personal list of your own recurring errors and scan for them before submitting anything important.

The habits this course asks you to build — honest rhetoric, careful evidence, deliberate audience analysis, clean visual design, genuinely collaborative teamwork, ruthless revision — are the same habits that will make you a better engineer. The technical and the communicative are not separate competences. They are the same competence, practiced on different material. The engineer who can design a good circuit can, with a little work, write a good memo; and the engineer who can write a good memo will, over a career, design better circuits, because they will understand their own reasoning well enough to explain it, defend it, and revise it in the face of what others understand. That is the whole course in one sentence, and the rest of the term is practice.