Hedging Language: How to Be Professionally Uncertain in English

Software development involves constant uncertainty: estimates that might be wrong, assumptions that could change, risks that may or may not materialise. Communicating this uncertainty clearly — in English — is a skill that separates senior engineers from junior ones.

The language tool for this is called hedging: the use of specific words and phrases to make a statement less absolute, to qualify a claim, or to signal that further verification is needed.

This is not about being vague or uncommitted. It is about being accurately uncertain.

---

Why Hedging Matters in Technical Communication

Consider these two estimates in a planning meeting:

(A) “The migration will take two weeks.”
(B) “The migration should take around two weeks, assuming we don’t hit any issues with the legacy data format.”

Statement A commits you to a timeline. Statement B communicates the same estimate while naming the key risk. If the migration takes longer because of legacy data issues, statement B was accurate and transparent; statement A was simply wrong.

Hedging protects you, your team, and your stakeholders. It signals maturity — that you understand the limits of what you know.

---

The Grammar of Hedging

English has several grammatical structures for hedging. Here are the main categories:

1. Modal Verbs

Modal verbs are the most common hedging tool. Their strength varies:

Modal	Certainty level	Example
will	Near certain	”The build will fail if we skip the tests.”
should	Likely	”This should fix the race condition.”
may / might	Possible	”This may introduce a regression in the auth flow.”
could	Possible (slightly less certain than may)	“That could be a memory leak.”
would	Conditional	”That would break the API contract.”

In technical communication, prefer should, may, and might over definitive statements when you are not 100% certain.

2. Adverbs of Probability

“The performance issue is most likely caused by the N+1 query."
"The fix probably resolves the root cause, but we should monitor after deploy."
"This is unlikely to affect users on version 2.x."
"The timeout is almost certainly coming from the third-party API.”

Common hedging adverbs: probably, likely, possibly, perhaps, apparently, seemingly, presumably.

3. Verbs of Belief and Estimation

“I think the issue is in the middleware layer."
"I believe we can ship this Friday, but I want to verify the test results first."
"It appears that the cache is not being invalidated on update."
"It seems the old configuration file is being loaded instead of the new one."
"I suspect there is a race condition in the async handler.”

Note: “I think” is not a sign of weakness in English — it is an accurate signal that you are sharing a belief, not a fact. Native English speakers use it constantly. Use it.

4. Approximate Quantifiers

“Around 30% of requests are failing."
"The operation takes roughly 200ms on average."
"We have approximately two hours of error budget remaining."
"The memory usage spikes to about 2GB under load.”

---

Hedging in Common Situations

In code review comments

Too direct (can sound harsh):

“This is wrong. You should use a set, not a list.”

Hedged (professional):

“I might be missing context, but could we use a Set here? It would give O(1) lookups instead of O(n), which might matter at scale.”

“This could cause a race condition if two requests arrive simultaneously — worth checking with a load test, I think.”

“Not sure if this is intentional, but user.id could be null if the session has expired.”

In status updates and standups

“I should be able to finish the endpoint by end of day, barring any unexpected issues."
"We’re on track for the Friday release, assuming the integration tests pass."
"The root cause appears to be a misconfigured environment variable — still confirming.”

In incident communication

“The spike in errors seems to have started around 14:30 UTC — possibly related to the config push at 14:25."
"This is likely (but not confirmed) a database connection pool exhaustion."
"The service appears to have recovered, but we’re monitoring for recurrence.”

In technical proposals

“This approach should reduce latency, though it may increase memory usage."
"The migration could take 2–3 weeks depending on the complexity of the legacy data."
"This appears to be the most cost-effective option, but we would need to verify with a load test.”

---

What to Avoid

Over-hedging makes your communication weak and hard to act on:

❌ “I’m not really sure but maybe it might possibly be some kind of issue with maybe the database or possibly the API or something like that.”

Under-hedging makes you sound overconfident and sets false expectations:

❌ “I’ll finish this by Wednesday.” (when you’re not sure)
✅ “I should finish this by Wednesday — I’ll confirm after tomorrow’s progress check.”

The goal is precision: say exactly how certain you are, no more and no less.

---

Hedging in Writing vs. Speech

Hedging is used in both writing and speech, but there are differences:

In writing (docs, code review, Slack, email): you have time to choose words carefully. Use hedging wherever uncertainty exists — readers will trust explicit uncertainty more than false confidence.

In speech (standups, meetings, calls): hedging comes through more naturally. Practice the phrases until they feel natural at speaking speed. Key sentence starters:

• “I think…”
• “I’m not 100% sure, but…”
• “If I remember correctly…”
• “This is a rough estimate, but…”

---

Quick Reference

Situation	Hedging phrase
Estimate	”should take around X…”
Diagnosis	”appears to be / seems to be…”
Possibility	”might / may / could…”
Assumption	”assuming that… / provided that…”
Belief	”I think / I believe / I suspect…”
Incomplete knowledge	”I’m not certain, but…”
Dependency	”…barring any / …unless…”

Hedging language is one of the most immediately applicable English skills for IT professionals. Start using it in your next PR comment or standup — the clarity it adds is noticeable immediately.

Practice with our hedging language exercises →

Navigating Ambiguity: Specific Phrasing for Developer Communication

The core of “hedging language” – as we’ve discussed – is about acknowledging uncertainty gracefully in professional communication. It’s not about avoiding the discussion, but about framing it in a way that demonstrates thoughtful consideration and proactive risk management. For non-native English speakers, this can feel particularly challenging because direct translations often lack the nuanced expressions used by native speakers. The goal isn’t to sugarcoat problems; it’s to articulate them clearly and constructively, recognizing that software development is inherently about managing expectations around what can be achieved versus what will be achieved. It’s a crucial skill for code reviews, stand-up meetings, and project documentation.

Let’s consider some specific scenarios. A common situation arises during a code review when you identify a potential issue with a pull request. Instead of saying something blunt like “This is broken,” which immediately puts the author on the defensive, you could say, “I noticed this area might benefit from further investigation regarding [specific aspect]. It appears there’s a slight possibility that [potential problem] could arise under [certain conditions], and I’d recommend exploring [suggested solution or next steps].” This phrasing acknowledges your observation without directly accusing the author of error. Similarly, in Slack conversations discussing feature prioritization, avoiding definitive statements like “This must be done” is vital. Saying something like, “It would be valuable to explore this further, given the potential impact on [related system] and the current resources available, before committing to a timeline” allows for discussion of feasibility and trade-offs. The key is to introduce qualifiers – “might,” “potentially,” “appears,” “could” – combined with explanations of why you’re raising the concern.

Another area where hedging language becomes critical is in PR descriptions. A developer might initially draft a description stating, “This feature implements user authentication.” That’s technically correct, but it doesn’t convey the level of effort or potential challenges involved. A more nuanced approach would be: “This PR introduces basic user authentication functionality using [technology - e.g., JWT]. While functional, further work is needed to address scalability considerations for larger user bases and integrate with our existing security protocols.” Again, this acknowledges the completion of a task while simultaneously highlighting areas needing attention. Recognizing that your initial assumptions might be incomplete is a sign of professional maturity.

Finally, remember that hedging isn’t about weakness; it’s about strategic communication. It demonstrates you’ve thought through the implications and are proactively seeking to mitigate risks. The ability to express uncertainty professionally builds trust with colleagues and stakeholders – a vital asset in any development environment.

# Example: Using `git status` to assess potential conflicts

git status