English.guru
Back

Precise Technical and Professional Vocabulary

How to describe systems, decisions, and trade-offs precisely — the vocabulary that makes technical English credible.

Technical English fails not through wrong grammar but through vague verbs. "We made the system better" and "we reduced query latency by 40%" describe the same work with very different credibility.

Verbs that carry technical weight

Vague Precise
make faster optimise, accelerate, streamline
make smaller reduce, compress, consolidate
fix resolve, patch, mitigate
change refactor, migrate, restructure
check validate, verify, audit
set up configure, provision, deploy
join together integrate, consolidate, merge
find the cause diagnose, trace, isolate

We isolated the bottleneck and refactored the query layer.

Describing how parts relate

Explaining an architecture out loud needs a small set of relationship verbs, and vagueness here is what makes an otherwise good explanation hard to follow:

  • The API sits behind a load balancer.
  • The service depends on the auth layer. · Nothing else relies on it.
  • It talks to the database directly. (informal but standard)
  • The queue decouples ingestion from processing.
  • Sessions are backed by Redis.
  • That module is responsible for validation.

Note depend on and rely on both take on, and consist of takes ofthree prepositions that are fixed and frequently wrong.

Describing trade-offs

Technical discussion is largely about trade-offs, and English has fixed language for it:

  • There's a trade-off between speed and accuracy.
  • We prioritised reliability over raw performance.
  • That approach scales better, but at the cost of complexity.
  • It's a reasonable compromise given the constraints.
  • The downside is that it adds a dependency.

Hedging technical claims

Overclaiming damages credibility with technical audiences. Precision includes precision about certainty.

  • This should reduce load significantly. (expected)
  • It appears to be a race condition. (probable, not confirmed)
  • We suspect the issue originates in the cache layer.
  • As far as we can tell, the data is consistent.

Compare the overclaim: This will definitely fix it. Rarely justified, and expensive when wrong.

Explaining cause

  • The failure stems from an unhandled edge case.
  • This was triggered by a schema change.
  • The root cause turned out to be a timeout setting.
  • These issues are symptomatic of a deeper design problem.

When something breaks

Incident English is highly conventional, and using the wrong word overstates or understates the situation:

Term Means
outage it's down completely
degradation it works, but slowly or partially
intermittent it fails some of the time
regression something that worked before is now broken
workaround a temporary way around it
mitigation reduces the impact, doesn't fix the cause
rollback revert to the previous version
postmortem the write-up afterwards

We've mitigated the impact with a workaround; the root cause is still open. — that sentence tells a manager exactly where things stand.

Scoping and estimating

  • That's out of scope for this release.
  • Roughly — ballpark — two weeks.
  • We're seeing some scope creep.
  • I'd want to spike on it before committing to an estimate.
  • It's blocked on the API change.

Quantifying

Vague quantification undermines otherwise good technical English.

  • It got a lot faster.
  • Latency dropped from 800 ms to roughly 200 ms.
  • That's an improvement of around 75%.
  • Error rates fell by an order of magnitude.

Precision and confidence are separate dials. We reduced p99 latency by roughly 60%, though we haven't confirmed why is both precise and appropriately uncertain. Technical audiences trust that combination and distrust its opposite — a confident claim with no numbers in it.

An incident call

A: What are we seeing?

B: Intermittent 500s on checkout since about nine. It's degradation, not a full outage.

A: Do we know why?

B: Not yet. It appears to be connection-pool exhaustion, but that's a guess. We've rolled back the deploy as a mitigation and errors dropped by around 90%.

A: Good. Root cause can wait for the postmortem.

Every claim graded for certainty, one number, and the right incident word in each slot.

Try it yourself

The quiz below rewards precision and appropriate hedging over impressive-sounding vagueness.

Test yourself: Quiz: Technical Precision →