What's the difference between 'deduce' and 'infer' in technical writing?

'Deduce' means reaching a conclusion from clearly known facts (e.g., 'From the logs, we deduce the crash happened at 3pm'). 'Infer' means reaching a conclusion indirectly or with less certainty (e.g., 'From user complaints, we can infer the feature is confusing'). In RFCs, use 'deduce' for data-driven conclusions.

When should I use 'thereby' vs 'therefore' in design docs?

'Thereby' means 'by this action' and connects a cause to its immediate effect (e.g., 'We cache the response, thereby reducing latency'). 'Therefore' introduces a logical conclusion from previous statements (e.g., 'The cache hit rate is 95%. Therefore, adding more cache nodes is unnecessary').

How do I make my RFC arguments more coherent?

Use argument verbs like 'advocate,' 'deduce,' and 'complement' to show logical relationships. Add connectives like 'thereby,' 'notwithstanding,' and 'whereby' to link ideas. Structure sections as: Problem → Evidence → Conclusion → Proposal.

Is 'utilize' better than 'use' in technical documents?

Not always. 'Utilize' is more formal but can sound pretentious if overused. Use 'utilize' when emphasizing purposeful or efficient use (e.g., 'The service utilizes connection pooling'). For simple cases, 'use' is clearer and preferred.

How do I give feedback that a design doc is unclear?

Say 'The argument in section 3 is ambiguous—could you clarify the expected behavior?' or 'The proposal would be more coherent if you moved the trade-offs section before the alternatives.' Avoid vague criticism like 'This is confusing.'

How to Write Clear and Logical Arguments in English at Work

Pronunciation Guide: Terms That Trip Up ESL Speakers

These terms from technical writing are commonly mispronounced in meetings and presentations. Practice them before your next design review.

ambiguous /æmˈbɪɡ.ju.əs/

am-BIG-you-us

Saying 'am-bi-GYOO-us' with wrong stress

coherent /koʊˈhɪr.ənt/

co-HEER-ent

Saying 'CO-her-ent' with stress on first syllable

comprehensive /ˌkɒm.prɪˈhen.sɪv/

com-pri-HEN-sive

Saying 'com-pre-HEN-sive' with wrong vowel

empirical /ɪmˈpɪr.ɪ.kəl/

em-PEER-i-cal

Saying 'EM-pir-i-cal' with stress on first syllable

notwithstanding /ˌnɒt.wɪθˈstæn.dɪŋ/

not-with-STAN-ding

Rushing through 'with' and dropping the 'th' sound

Why Logical Structure Matters in Technical Writing

When you write an RFC or design doc, your goal isn't just to share information—it's to build an argument that leads readers to your proposed solution. Senior engineers and tech leads often reject proposals not because the idea is bad, but because the reasoning is hard to follow.

Clear logical structure helps reviewers understand your thinking, anticipate objections, and approve faster. This unit covers the vocabulary and phrases that make your technical arguments coherent and persuasive.

Culture Note: The 'Why' Before the 'What'

In American and European tech companies, readers expect you to explain WHY before HOW. Start your RFC with the problem and motivation before jumping into the technical solution. This cultural expectation makes logical connectives essential.

Verbs for Presenting Arguments in RFCs and Design Docs

When structuring the argument section of an RFC, you need verbs that show how you reached your conclusions and how your work relates to existing solutions.

Verb	Meaning	Tech Example
advocate	argue in favor of something	This RFC advocates migrating to event-driven architecture.
deduce	reach a conclusion from known facts	From the latency metrics, we can deduce that the bottleneck is in the database layer.
infer	reach a conclusion indirectly	From the error logs, we inferred that memory leaks occur during peak traffic.
complement	combine well with another approach	This caching strategy complements our existing CDN configuration.
overlap	partially cover the same ground	Our proposal overlaps with the team's Q3 roadmap, so we should coordinate.

❌ Weak (Heard in Reviews)	✅ Stronger (Clearer Logic)
I think we should use Redis.	This RFC advocates using Redis for session storage.
The logs show something is wrong.	From the error patterns, we can deduce that the retry logic is failing silently.
This is kind of like what Team X did.	This approach complements Team X's work on the notification service.

Adjectives for Describing Technical Work

When reviewing a colleague's design doc or referencing existing solutions, you need precise adjectives. These help you give feedback and position your work professionally.

Adjective	Definition	When to Use It
empirical	based on observed data, not theory	The decision is empirical—we ran A/B tests for three weeks.
ambiguous	open to different interpretations	The requirements doc is ambiguous about error handling.
coherent	logically structured, easy to follow	Your argument is coherent, but the diagrams need work.
comprehensive	covering all relevant aspects	This is a comprehensive review of our auth options.
authoritative	expert and thorough	The Kubernetes docs are the authoritative source for this.

Editing Tip: Check for Coherence First

When editing a colleague's doc, ask: 'Is this coherent?' before checking grammar. If the logical flow is broken, suggest reordering sections or adding connectives like 'therefore' or 'as a result.'

Talking About Data, Metrics, and Processes

Technical documents often discuss metrics, system behavior, and processes. Use these terms to describe data accurately and avoid misleading your readers.

Term	Meaning	Tech Example
arbitrary	based on random choice, not data	The 30-second timeout is arbitrary—we should benchmark it.
deviate from the norm	different from typical values	These response times deviate from the norm; we should investigate.
distort	give a false impression	Averaging the data distorts the picture—use percentiles instead.
incidence	how often something occurs	The incidence of 500 errors has doubled since the deploy.
predominant	largest in number or most common	GET requests are predominant in our traffic profile.
in sequence	in a particular order	The migration scripts must run in sequence, not in parallel.
widespread	occurring in many places	The latency spike was widespread across all regions.

Use 'incidence' when discussing frequency of events (errors, outages, user actions).
Use 'predominant' when one category dominates others in your data.
Avoid 'arbitrary' as criticism—instead say 'The value appears arbitrary; what's the rationale?'

Formal Connectives: Slack vs. Design Doc Register

Technical documents require a more formal register than Slack messages. Here's how to upgrade your connectives when moving from casual chat to official documentation.

💬 Slack / Casual	📄 RFC / Design Doc
so	thereby (in this way)
by doing this	whereby (by which method)
but still	notwithstanding (despite this)
kind of / a bit	somewhat
really important	crucial
the opposite	the converse
for example	an instance of

Example in context: 'The service validates tokens at the gateway, thereby reducing latency for downstream services.' Compare to Slack: 'We validate tokens at the gateway, so downstream services are faster.'

Upgrading Everyday Verbs for Technical Documents

Some verbs sound too casual for RFCs and design docs. Swap them for more precise, formal alternatives to strengthen your technical writing.

Casual Verb	Formal Alternative	Example in a Design Doc
add (at the end)	append	We append the request ID to every log entry.
think up	conceive	The architecture was conceived to handle 10x current load.
go against	contradict	This approach contradicts our existing caching strategy.
show	demonstrate / indicate	The metrics demonstrate a 40% improvement in throughput.
stand for	denote	In our schema, 'U' denotes an unverified user.
wipe out / make useless	negate	This optimization would negate the benefits of the cache.
see	perceive	Users perceive the delay as a bug, not a feature.
think about	reflect upon	We should reflect upon the trade-offs before proceeding.
cause	trigger	A null pointer in the handler triggers the crash.
use	utilize	The service utilizes connection pooling for efficiency.

Don't Overdo It

Using 'utilize' instead of 'use' everywhere sounds pretentious. Reserve formal verbs for RFCs and design docs. In Slack and code comments, casual verbs are fine and often clearer.

English for Developers Bundle