Grammar: Modal Verbs for Expressing Technical Uncertainty

Software engineers deal with uncertainty constantly — estimates, root cause investigations, risk assessments, performance predictions. In English, modal verbs are the primary tool for expressing different degrees of certainty and possibility. Using them correctly makes your technical communication more precise, professional, and honest.

---

What Are Modal Verbs?

Modal verbs are auxiliary verbs that express possibility, ability, permission, necessity, or certainty. The main modal verbs in English are:

can / could / may / might / will / would / should / must / ought to / shall

They are followed by the bare infinitive (the verb without “to”):

“This could cause a race condition.” (not “could to cause”)
“The service might be timing out.” (not “might to be”)

---

Expressing Degrees of Certainty

This is the most important use of modals in technical communication:

Certainty level	Modal	Example
Almost certain	must	”The server must be overloaded — response times are at 30 seconds.”
Highly likely	should	”The deployment should complete in about 10 minutes.”
Possible	may	”This change may affect users in the EU region.”
Uncertain possibility	might / could	”The issue might be related to the recent config change.”
Very uncertain	might	”There might be a memory leak somewhere in the session handling.”

In practice:

“The cache must be stale — we’re seeing data that should have been invalidated two hours ago.”
→ High confidence deduction from evidence.

“The latency spike could be related to the database migration we ran this morning.”
→ A hypothesis, not a confirmed cause.

“The fix might take longer than expected if the issue turns out to be in the third-party library.”
→ Acknowledging an uncertain dependency.

---

Expressing Recommendations and Advice

Use should and ought to for recommendations:

“You should add error handling before this call — if the API is down, the request will silently fail.”

“We should discuss this with the security team before deploying.”

“The tests ought to cover this edge case — let me add them before we merge.”

Should is also used for expected behaviour:

“The endpoint should return a 404 if the resource doesn’t exist.”
→ This is the expected design behaviour.

“This test should pass — I’m not sure why it’s failing.”
→ Expectation that is currently violated.

---

Expressing Necessity and Requirements

Use must and have to for requirements:

“All API requests must include a valid token in the Authorization header.”
(Technical requirement — no exceptions)

“We have to fix this before the release — it’s a data integrity issue.”
(Practical necessity)

Use need to in more conversational contexts:

“We need to revisit this design before it goes to production.”

Note: In technical documentation, must is stronger and more formal than should:

• “The field must be present.” — required, no exceptions
• “The field should be present.” — recommended, but the system may tolerate its absence

---

Expressing Permission and Ability

Can expresses ability or permission:

“You can authenticate with either an API key or OAuth 2.0.”
(Permission/ability — both are allowed)

“The service can handle up to 10,000 concurrent connections.”
(Ability/capacity)

Could expresses past ability or polite possibility:

“Could you take a look at this PR when you have a moment?”
(Polite request — more formal than “Can you…?”)

“In theory, we could implement this in the frontend, but it would expose sensitive logic.”
(Possibility being evaluated)

---

Past Modal Constructions for Technical Analysis

When analysing past events (incidents, bugs), modals + have + past participle express what was possible, likely, or certain in the past:

Structure	Meaning	Example
must have	Almost certain past deduction	”The process must have run out of memory — it was killed by OOM killer.”
could have	Past possibility	”The cache could have been invalidated too early.”
might have	Uncertain past possibility	”The timeout might have been caused by a slow query.”
should have	Past expectation (unfulfilled)	“The test should have caught this — I’ll investigate why it didn’t.”
would have	Conditional past	”Without the circuit breaker, the failure would have cascaded to all services.”

---

Common Mistakes to Avoid

Using “will” when you mean “should”:

“The function will return null if the user is not found.”
→ Use this only if you are certain this is the behaviour.

“The function should return null if the user is not found.”
→ Better if you are stating expected design or haven’t verified.

Overusing “can” for requirements:

“You can set the timeout in the config file.”
→ This sounds optional. If it’s recommended, use “should”; if required, use “must”.

“May” vs. “might” — both are acceptable for possibility, but “might” suggests slightly lower certainty:

“This may introduce a breaking change.” — possible
”This might introduce a breaking change.” — slightly less certain

---

Quick Reference Table

Modal	Primary use in tech English	Example
must	Requirement; high-certainty deduction	”Passwords must be hashed.”
should	Recommendation; expected behaviour	”The API should return 200 on success.”
may	Possibility	”This may affect performance.”
might / could	Lower-certainty possibility	”This might cause a race condition.”
can	Ability; permission	”Users can reset their password via email.”
will	Certain future; definite prediction	”The cache will expire after 60 seconds.”
would	Conditional	”This would be faster with an index.”

---

Precise use of modal verbs marks you as a careful communicator. In technical contexts, the difference between “this will fail” and “this might fail” matters enormously — and using the right modal ensures your meaning is never misunderstood.

In Practice: Navigating Uncertainty with Nuance

The beauty – and sometimes the frustration – of software development lies in its inherent uncertainty. We’re constantly dealing with estimations, potential issues, and shifting requirements. Using modal verbs correctly isn’t just about adhering to grammatical rules; it’s about conveying precision and responsibility within a technical context. For non-native English speakers, this can be particularly challenging because the subtle shades of meaning associated with “might,” “could,” “should,” and “would” aren’t always directly transferable from other languages.

Let’s consider a common scenario: code reviews. Imagine receiving a comment on a pull request describing a newly implemented feature. Instead of simply stating “This is not ideal,” a developer could say, “Could you explore implementing caching here to mitigate potential performance bottlenecks? It might be beneficial if the API calls are frequently repeated.” The use of “could” and “might” immediately softens the criticism while proposing a concrete alternative. The difference isn’t just stylistic; it subtly shifts the tone from a directive to a collaborative suggestion, acknowledging that there might be other valid approaches. Similarly, in Slack conversations discussing a critical bug report, saying “We should investigate this thoroughly” carries more weight than “This is bad.” It implies an obligation and sets expectations for a detailed examination.

Furthermore, when documenting technical risks or proposing solutions, modal verbs are crucial for framing recommendations. A PR description might read: “The team will implement a rollback mechanism in case the new database schema introduces compatibility issues. We would appreciate feedback on this approach before proceeding further.” Notice how “will” denotes an action being taken and a clear responsibility, while “would” expresses a desire for input—a crucial element of collaborative development. It’s not just about saying something can be done; it’s about stating what should or might be done, along with the rationale behind it. Don’t underestimate the power of carefully choosing your modal verb – it directly impacts how your ideas are perceived and acted upon.

Finally, remember that context is everything. The specific phrasing will vary depending on the audience (e.g., a senior architect versus a junior developer) and the formality of the communication. However, understanding the core distinctions between these verbs—their implications for possibility, obligation, recommendation, and speculation—is fundamental to clear and effective technical communication.

# Example: Using `grep` in a command line to search for potential issues
grep -i "error" /var/log/application.log | head -n 5