Principles of Clarity

Summary

Clarity is the first pillar of effective communication. This chapter teaches you the Feynman Technique — a four-step method for simplifying any complex idea — along with principles of plain language, cognitive load management, and precision in language. You will learn to recognize and eliminate jargon, reduce ambiguity, and use concrete language to make your ideas accessible to any audience. These clarity principles form the foundation for every framework that follows.

Concepts Covered

This chapter covers the following 17 concepts from the learning graph:

Clarity
Simplicity
Jargon
Plain Language
Feynman Technique
Feynman Step One Teach
Feynman Step Two Identify
Feynman Step Three Simplify
Feynman Step Four Analogies
Cognitive Load
Working Memory Limits
Chunking Information
Signal to Noise Ratio
Precision in Language
Ambiguity
Concrete Language
Abstract Language

Prerequisites

This chapter builds on concepts from:

Chapter 1: Communication Foundations

What Is Clarity and Why Does It Matter?

In Chapter 1, you learned that communication succeeds only when the receiver decodes the message as the sender intended. Clarity is the quality of a message that makes this successful decoding likely. A clear message is one that the intended audience can understand on the first reading or hearing, without needing to ask follow-up questions, re-read paragraphs, or guess at the author's meaning.

Clarity is not about dumbing things down. It is about removing every obstacle between your idea and the reader's understanding. A clear explanation of a complex algorithm is not less rigorous than an unclear one — it is more rigorous, because it demonstrates that the author understands the concept deeply enough to present it without confusion.

For engineers, clarity has direct, measurable consequences:

A clear bug report gets fixed faster than a vague one
A clear design document earns stakeholder approval with fewer revision cycles
A clear email to a cross-functional partner avoids days of back-and-forth
A clear presentation to leadership secures funding that an unclear one loses

The opposite of clarity is not complexity — it is confusion. Complex ideas can be presented clearly. Simple ideas can be presented in confusing ways. This chapter gives you the tools to ensure that your communication is always on the clarity side of that divide.

Simplicity: The Engine of Clarity

Simplicity is the practice of expressing ideas using the fewest and most straightforward elements necessary to convey the intended meaning. Simplicity does not mean leaving out important details. It means stripping away everything that does not serve the reader's understanding.

The relationship between simplicity and clarity is direct: simpler messages are easier to decode. Every extra clause, every unnecessary qualifier, every tangential detail is an opportunity for the reader's attention to wander or their comprehension to break down.

Consider two explanations of the same concept:

Version	Explanation
Complex	"The system utilizes a multi-tiered caching architecture that leverages both in-memory and distributed caching mechanisms to facilitate the optimization of data retrieval latency across heterogeneous computing environments."
Simple	"The system uses two levels of caching — one in local memory and one shared across servers — to make data retrieval faster."

Both sentences describe the same architecture. The simple version conveys the same technical content in fewer words, with familiar vocabulary, and with a structure that mirrors how someone would explain it out loud. Simplicity did not sacrifice accuracy — it increased accessibility.

Think About It

When you write something complex, ask yourself: "If I were explaining this to a smart friend over coffee, would I say it this way?" If the answer is no, your writing is more complicated than it needs to be. The goal is not to sound impressive — it is to be understood.

The Jargon Problem

Jargon is specialized vocabulary used within a particular profession, field, or group. Every technical discipline develops its own jargon: software engineers say "refactor," electrical engineers say "impedance matching," and data scientists say "feature engineering." Within the group that shares this vocabulary, jargon is efficient. It compresses complex ideas into single terms that everyone understands immediately.

The problem with jargon is not that it exists — it is that it fails silently. When you use jargon with someone who does not share your vocabulary, they do not always ask for clarification. Instead, they nod, smile, and leave the conversation with a wrong or incomplete understanding of your message. This is the most dangerous form of communication failure: the kind where neither party realizes it happened.

Jargon becomes problematic in three common situations:

Cross-functional communication: When engineers talk to product managers, designers, or business stakeholders who do not share their technical vocabulary
Interdisciplinary collaboration: When software engineers work with hardware engineers, or when computer scientists collaborate with domain experts in biology, finance, or manufacturing
Audience mismatch: When a specialist writes documentation that will be read by newcomers, students, or the general public

The solution is not to ban jargon entirely. In a room full of experienced software engineers, saying "we need to refactor the authentication module" is perfectly clear and far more efficient than explaining what refactoring means every time. The solution is audience awareness — knowing when jargon will be understood and when it will create barriers.

Plain Language: The Alternative to Jargon

Plain language is a communication approach that prioritizes the reader's ability to understand the message on the first reading. Plain language uses common words, short sentences, active voice, and logical organization. It is not informal or unprofessional — it is considerate of the reader's time and cognitive capacity.

The principles of plain language include:

Use common words instead of technical or Latin-derived alternatives ("use" instead of "utilize," "start" instead of "initiate," "about" instead of "approximately")
Prefer short sentences to long, multi-clause constructions
Use active voice ("The server processes requests") rather than passive voice ("Requests are processed by the server")
Define technical terms when you must use them
Front-load key information so the reader gets the main point first

The following table shows common jargon-to-plain-language substitutions that engineers encounter:

Jargon / Inflated Phrase	Plain Language Alternative
Utilize	Use
Facilitate	Help, enable
Leverage	Use, take advantage of
Implement a solution	Fix, build
At this point in time	Now
In order to	To
Due to the fact that	Because
Commence	Start, begin
Terminate	End, stop
Subsequent to	After

Plain language is not the enemy of precision. You can be both precise and plain. "The function returns null when the input array is empty" is plain, precise, and technical. "The function effectuates a null return value upon the occasion of an empty input array being received" is needlessly complex without adding any precision.

The Feynman Technique: A System for Achieving Clarity

The Feynman Technique is a four-step method for understanding and explaining complex ideas, named after the Nobel Prize-winning physicist Richard Feynman. Feynman was legendary not only for his contributions to quantum electrodynamics but also for his ability to explain profoundly difficult physics concepts in language that anyone could follow. His approach was not a natural gift — it was a deliberate method that anyone can learn.

The Feynman Technique works because it forces you to confront the gaps in your own understanding. Most people confuse familiarity with understanding. You can read a textbook chapter, recognize every term, and still not be able to explain the concept without looking at your notes. The Feynman Technique exposes this gap and gives you a process for closing it.

The four steps are:

Teach the concept as if explaining to someone unfamiliar with it
Identify the gaps where your explanation breaks down
Simplify by returning to the source material and rebuilding your understanding
Use Analogies to connect the concept to familiar ideas

flowchart TD
    A["Step 1: Teach It
    Explain the concept in
    plain, simple language"] --> B["Step 2: Identify Gaps
    Find where your explanation
    breaks down or gets vague"]
    B --> C["Step 3: Simplify
    Return to source material,
    rebuild understanding"]
    C --> D["Step 4: Use Analogies
    Connect to familiar concepts
    the audience already knows"]
    D -->|"Still unclear?"| B
    D -->|"Clear!"| E["Deep Understanding
    Achieved"]

Step One: Teach It

Feynman Step One: Teach requires you to explain the concept as if you are teaching it to someone who has never encountered it before. Write your explanation on paper or speak it aloud. Do not use the original source material. Do not use jargon unless you also define it. Pretend your audience is intelligent but has no background in your field.

This step works because teaching forces you to organize information into a logical sequence. You must decide what comes first, what depends on what, and how the pieces connect. When you merely read or listen, your brain can skip over these structural questions. When you teach, it cannot.

For example, suppose you need to explain how a hash table works. Instead of reciting the textbook definition, you might say: "A hash table is like a filing cabinet where each drawer is labeled with a number. When you want to store something, a formula converts the item's name into a drawer number, and you put it in that drawer. When you want to find it later, you run the same formula on the name and go directly to the right drawer instead of searching through every drawer."

Step Two: Identify the Gaps

Feynman Step Two: Identify is where the real learning happens. As you teach, you will inevitably reach moments where your explanation becomes vague, circular, or hand-wavy. You might say something like "and then the algorithm just sort of figures out the optimal path" — that "sort of figures out" is a gap. It means you do not actually understand the mechanism well enough to explain it.

Mark every place where your explanation falters. Common signs of a gap include:

You resort to jargon because you cannot think of a simpler way to say it
You skip a step in the process because you are not sure what happens there
You use filler phrases like "basically," "essentially," or "it just works"
You cannot answer a hypothetical follow-up question from your imaginary student

These gaps are not failures — they are valuable diagnostic information. They tell you exactly which parts of the concept you need to study more deeply.

Step Three: Simplify

Feynman Step Three: Simplify sends you back to the source material — the textbook, the documentation, the paper — to fill the gaps you identified. But this time, you are not reading passively. You have specific questions, and you are reading to answer them.

After filling each gap, rewrite your explanation. Make it simpler than your first attempt. If you used a three-sentence explanation before, try to do it in two. If you used a technical term, find a way to express the same idea without it. Each iteration should produce an explanation that is both more accurate and more accessible than the last.

This iterative refinement is the core of the technique. Most people stop learning after they can recognize a concept. The Feynman Technique pushes you to the level where you can reconstruct the concept from first principles.

Step Four: Use Analogies

Feynman Step Four: Analogies is the step that transforms a clear explanation into a memorable one. An analogy is a comparison between something unfamiliar and something the audience already understands. Analogies work because they give the reader a mental scaffold — a structure they already have in their memory — onto which they can attach the new concept.

Effective analogies share a structural relationship with the concept they explain. A few well-known examples in computing:

Concept	Analogy	Why It Works
CPU cache	A desk vs. a filing cabinet — you keep frequently used documents on your desk for quick access	Maps the speed-vs-capacity tradeoff directly
Recursion	Russian nesting dolls — each doll contains a smaller version of itself until you reach the smallest one	Captures the self-similar, base-case structure
API	A restaurant menu — you choose from a defined set of options without needing to know how the kitchen works	Illustrates abstraction and interface contracts
Version control	A "save game" system — you can save your progress at any point and return to it if something goes wrong	Makes branching and rollback intuitive
Encryption	A locked mailbox — anyone can drop a letter in, but only the person with the key can read it	Captures the asymmetry of public-key cryptography

Good analogies are not perfect — no analogy is. The goal is to create an entry point, not a complete mapping. Once the audience grasps the core idea through the analogy, you can introduce the nuances and edge cases where the analogy breaks down.

Cognitive Load: Why Clarity Is a Brain Science Problem

Understanding why clarity matters requires understanding how your audience's brain processes information. Cognitive load is the total amount of mental effort being used in a person's working memory at any given moment. Every sentence your reader processes, every diagram they interpret, and every term they must recall consumes cognitive load.

When cognitive load exceeds the brain's capacity, comprehension breaks down. The reader may re-read the same paragraph three times, skip sections entirely, or walk away from the document with a shallow understanding that feels complete but is full of gaps.

Cognitive load theory, developed by educational psychologist John Sweller, identifies three types of load:

Intrinsic load: The inherent difficulty of the material itself (you cannot eliminate this — some topics are genuinely hard)
Extraneous load: The difficulty added by poor presentation — confusing organization, unnecessary jargon, cluttered visuals (you can and should eliminate this)
Germane load: The productive mental effort of building understanding and connecting new knowledge to existing knowledge (you want to maximize this)

pie title "Cognitive Load Budget"
    "Intrinsic Load (Material Difficulty)" : 40
    "Extraneous Load (Poor Presentation)" : 35
    "Germane Load (Actual Learning)" : 25

The goal of clear communication is to minimize extraneous load so that more of the reader's cognitive budget is available for germane load — the work of actually understanding. Every principle in this chapter — simplicity, plain language, the Feynman Technique — is a strategy for reducing extraneous cognitive load.

Working Memory Limits

Working memory is the cognitive system responsible for holding and manipulating information in the short term. It is where your reader actively processes your message. Psychologist George Miller's classic research established that working memory can hold approximately seven items (plus or minus two) at a time. More recent research suggests the effective limit may be closer to four items for complex information.

This limit has profound implications for technical communication:

A list of 12 system requirements overwhelms working memory; a list of 4 grouped categories does not
A sentence with 6 nested clauses exceeds processing capacity; two shorter sentences do not
A diagram with 15 unlabeled components is unreadable; a diagram with 5 clearly labeled components is clear

Your audience's working memory is the bottleneck through which all your communication must pass. Respecting this limit is not optional — it is a constraint imposed by human biology.

Chunking Information

Chunking is the strategy of grouping individual pieces of information into larger, meaningful units to make them easier to hold in working memory. A phone number like 5 1 2 8 6 7 5 3 0 9 is ten separate digits — beyond working memory's capacity. Chunked as 512-867-5309, it becomes three groups, well within the limit.

Chunking works in technical communication through several mechanisms:

Headings and subheadings chunk a long document into navigable sections
Bullet points chunk a dense paragraph into scannable items
Numbered steps chunk a complex process into a sequential series
Tables chunk comparative information into a grid that reveals patterns
Diagrams chunk system relationships into a visual structure

The following diagram illustrates how chunking transforms an overwhelming list into a manageable structure:

flowchart LR
    subgraph Before["Before Chunking"]
        A1["Item 1"] ~~~ A2["Item 2"] ~~~ A3["Item 3"]
        A4["Item 4"] ~~~ A5["Item 5"] ~~~ A6["Item 6"]
        A7["Item 7"] ~~~ A8["Item 8"] ~~~ A9["Item 9"]
    end
    subgraph After["After Chunking"]
        B1["Category A"] --> B1a["Items 1-3"]
        B2["Category B"] --> B2a["Items 4-6"]
        B3["Category C"] --> B3a["Items 7-9"]
    end
    Before -->|"Group by meaning"| After

When you write a technical document, think of yourself as a chunking architect. Your job is to decide how to break the material into groups that fit within your reader's working memory window. The groupings should be meaningful — items within a chunk should be more related to each other than to items in other chunks.

Pro Tip

Before you publish any document, count the items in your longest list or the steps in your longest procedure. If any single list exceeds seven items, look for opportunities to create sub-groups. Your readers' brains will thank you.

Signal to Noise Ratio

Signal to noise ratio is a concept borrowed from electrical engineering that applies directly to communication. In its original context, signal is the information you want to transmit, and noise is everything else that interferes with that transmission. In communication, the signal is the content your reader needs, and the noise is everything that distracts from or obscures that content.

A high signal-to-noise ratio means most of what you communicate is useful information. A low signal-to-noise ratio means the reader has to wade through filler, tangents, and unnecessary detail to find the point.

Common sources of noise in technical communication include:

Redundant phrases: "In my personal opinion, I think that..." (just state the opinion)
Throat-clearing introductions: "Before we begin, it is important to note that there are several considerations that should be taken into account..." (just begin)
Excessive hedging: "It might perhaps be worth considering the possibility that..." (state the recommendation)
Irrelevant context: Three paragraphs of history when the reader needs a how-to guide
Decorative jargon: Using complex words to sound authoritative rather than to convey meaning

Every word that does not serve the reader's understanding is noise. Every sentence that does not advance the reader's knowledge is noise. Improving your signal-to-noise ratio means cutting noise ruthlessly while preserving every element that carries meaning.

The relationship between signal-to-noise ratio and the other concepts in this chapter is clear: simplicity increases signal, jargon adds noise for non-specialist audiences, chunking organizes signal into receivable units, and plain language strips away noise at the word level.

Precision in Language

Precision in language means choosing words that convey exactly the meaning you intend — no more, no less. Precision is the complement of simplicity. While simplicity asks "Can I say this with fewer or simpler words?", precision asks "Do these words say exactly what I mean?"

Imprecise language creates gaps between what the writer means and what the reader understands. In engineering, these gaps can be costly:

Imprecise Statement	Problem	Precise Alternative
"The system is fast"	How fast? Compared to what?	"The system responds in under 200ms for 95% of requests"
"We need to improve performance"	Which metric? By how much?	"We need to reduce API latency from 800ms to 200ms"
"The update will happen soon"	When exactly?	"The update deploys at 2:00 AM EST on March 15"
"The file is large"	How large?	"The file is 2.4 GB"
"Most users prefer the new design"	What percentage? Based on what?	"73% of users in our A/B test preferred the new design (n=1,200)"

Precision does not mean drowning your reader in numbers and qualifiers. It means replacing vague terms with specific ones where specificity matters. If you are writing a casual update to your team, "the deploy went smoothly" is fine. If you are writing a post-incident report, you need exact timestamps, error counts, and duration.

Ambiguity: The Enemy of Precision

Ambiguity exists when a statement can be reasonably interpreted in more than one way. Ambiguity is the single most common cause of miscommunication in engineering teams. It creates situations where two people read the same requirement, build two different things, and both believe they followed the specification correctly.

Ambiguity comes in several forms:

Lexical ambiguity: A word has multiple meanings. "The system should handle errors" — does "handle" mean log them, retry them, suppress them, or alert someone?
Syntactic ambiguity: The sentence structure allows multiple interpretations. "The manager told the engineer that she needed to update the document" — who needs to update the document, the manager or the engineer?
Referential ambiguity: A pronoun or reference is unclear. "After the server processes the request and sends it to the database, it crashes" — what crashes, the server, the request, or the database?
Scope ambiguity: The extent of a modifier is unclear. "Old men and women" — are both the men and women old, or only the men?

Eliminating ambiguity requires actively looking for alternative interpretations of your own writing. A useful technique is to ask yourself: "Could a reasonable person read this differently than I intend?" If the answer is yes, rewrite until the answer is no.

Common Pitfall

Ambiguity is hardest to spot in your own writing because your brain automatically selects the interpretation you intended. This is why peer review is so valuable. When a reviewer says "I wasn't sure what you meant here," that is diagnostic information — it means the sentence is ambiguous, even if it seems perfectly clear to you. Take their confusion seriously.

Concrete vs. Abstract Language

The final dimension of clarity is the spectrum between concrete and abstract language. Understanding when to use each type — and how to move between them — is essential for effective technical communication.

Concrete language refers to words and phrases that describe specific, observable, measurable things. Concrete language activates sensory experience and creates vivid mental images. You can point to what concrete language describes.

Abstract language refers to words and phrases that describe ideas, concepts, qualities, or categories that exist only as mental constructs. You cannot point to what abstract language describes — you can only think about it.

The following table illustrates the spectrum:

Abstract	More Concrete	Most Concrete
Performance	Response speed	47ms average latency
Security	Access control	Role-based permissions with OAuth 2.0
Scalability	Handling more users	Supporting 10,000 concurrent connections
Quality	Fewer defects	0.3 bugs per thousand lines of code
Efficiency	Faster processing	Sorting 1 million records in 0.8 seconds

Neither type is inherently better than the other. Each serves a different purpose:

Abstract language is useful for high-level summaries, strategic discussions, and introducing broad categories. "We need to improve security" sets the agenda for a conversation.
Concrete language is essential for specifications, instructions, and evidence. "We need to implement rate limiting of 100 requests per minute per API key" tells someone what to build.

The problem arises when writers stay too abstract for too long. If an entire design document discusses "performance," "scalability," and "reliability" without ever specifying numbers, thresholds, or measurable targets, it is not actionable. Readers nod along without knowing what to do.

The most effective technical communicators follow a pattern: start abstract to set context, then move quickly to the concrete to provide substance. For example: "Our goal is to improve system reliability [abstract]. Specifically, we are targeting 99.95% uptime, measured monthly, with a maximum of 22 minutes of unplanned downtime per month [concrete]."

flowchart TD
    A["Abstract: Sets Context
    'We need better performance'"] --> B["Semi-Concrete: Narrows Focus
    'Specifically, API response times'"]
    B --> C["Concrete: Provides Specifics
    'Reduce p95 latency from 800ms to 200ms
    by Q3 2026'"]
    C --> D["Actionable: Reader knows
    exactly what to do"]

Applying All 17 Principles: A Before-and-After Case Study

To see how these principles work together, consider a real-world scenario. An engineer needs to write a brief status update for a cross-functional team that includes product managers, designers, and other engineers.

Before (violates multiple clarity principles):

"Pursuant to our ongoing endeavors to effectuate a resolution vis-a-vis the latency perturbations that have been manifesting in the distributed caching subsystem, the team has been assiduously investigating the root cause and has ascertained that the etiology of the issue is attributable to cache invalidation race conditions that are precipitated by concurrent write operations in scenarios where the TTL has been exceeded. We are currently in the process of implementing a remediation strategy that leverages optimistic locking mechanisms to facilitate the elimination of the aforementioned race conditions."

This passage suffers from inflated jargon ("effectuate," "vis-a-vis," "assiduously"), extreme abstraction ("latency perturbations," "remediation strategy"), buried signals (the key information is hidden in the middle), and high extraneous cognitive load.

After (applies all 17 clarity principles):

"We found the cause of the caching slowdowns: race conditions during cache invalidation. When multiple servers write to the cache at the same time after a cache entry expires, they overwrite each other's updates. We are fixing this by adding optimistic locking, which ensures that only the most recent write takes effect. The fix will be deployed by Thursday."

This version uses plain language, eliminates unnecessary jargon, leads with the key finding, provides a concrete deadline, and respects the reader's cognitive load. The signal-to-noise ratio is dramatically higher. Both versions communicate the same technical content, but only the second version will be understood by the entire cross-functional team.

Key Takeaways

Clarity is the quality that makes successful decoding likely — it is the foundation of effective technical communication
Simplicity means using the fewest and most straightforward elements necessary, not leaving out important details
Jargon is efficient within groups that share it but fails silently when used with the wrong audience
Plain language prioritizes the reader's comprehension and is compatible with technical precision
The Feynman Technique is a four-step cycle: teach, identify gaps, simplify, and use analogies
Cognitive load is limited by working memory, which can hold approximately four to seven items at a time
Chunking groups information into meaningful units that fit within working memory limits
Signal to noise ratio measures how much of your communication is useful content versus filler
Precision means your words say exactly what you mean — no more, no less
Ambiguity is the enemy of precision and the most common cause of miscommunication in engineering
Concrete language specifies measurable, observable details; abstract language sets context and categories
The most effective communication starts abstract to set context, then moves quickly to the concrete

Chapter 2 Quiz

Next Chapter: Structuring Your Message — Learn frameworks for organizing information so your audience can follow and remember it.