Should for Recommendations and Expected Behavior

By the end of this lesson, you will be able to...

• Use should to express a technical recommendation without making it sound like a hard requirement.

• Use should to describe expected system behavior while keeping uncertainty visible.

• Compare should with must, have to, and might in short engineering comments.

Idea in one sentence: Use should when something is recommended or expected, but the sentence is not as strong as a contract, rule, or confirmed fact.

Core Insight

The last two lessons were strong.

Lesson 007 used must for a rule:

Every request must include an idempotency key.

Lesson 008 used have to for work forced by an external condition:

We have to rotate the key before Friday.

Now we need a softer but very useful word:

The alert should fire before users notice.

Should has two common jobs in technical English.

First, it gives advice or a recommendation:

We should add a dashboard for payment failures.

Second, it describes expected behavior:

The alert should fire before users notice.

Both jobs are weaker than must.

That weakness is not a problem. It is the point. Should lets you say "this is the right direction" or "this is what we expect" without pretending the sentence is a strict contract or a proven fact.

The trade-off is that should can sound too soft when the system really needs a hard rule. It can also sound too confident when the behavior has not been tested. Good technical writing makes the strength visible.

The Small Situation

Imagine a payment service.

Most payments succeed. A few fail for normal reasons: expired cards, bank declines, invalid input. That is expected.

One day, a deployment changes how the service calls the payment provider. The error rate jumps from 1 percent to 12 percent. Users can still open the checkout page, but many cannot finish payment.

The team wants an alert.

A teammate writes:

The alert must fire before users notice.

That sounds strong, but it may be too strong. Can an alert truly guarantee that no user notices first? Not always.

Users may notice immediately if the failure is sharp. Monitoring may evaluate every minute. Logs may arrive late. The alerting system may need two consecutive bad windows before it fires.

So a more natural design expectation is:

The alert should fire before users notice.

This sentence says the desired behavior. It does not promise magic.

If the team wants a hard rule, make the measurable rule explicit:

The alert must fire within five minutes of the payment error rate exceeding 5 percent.

Now must fits better because the sentence names a testable requirement.

Should is useful before the hard rule is fully specified, or when you are describing the expected outcome in plain language.

The Two Jobs of Should

The first job is recommendation.

We should add a dashboard for payment failures.

This means the speaker thinks the action is a good idea. It is advice. It may become a task, but the sentence itself is not yet a strict requirement.

The second job is expected behavior.

The alert should fire before users notice.

This means the speaker expects the system to behave this way if the design works. It is not a proof. It is an expectation.

Here is the difference:

The same word can do both jobs, so the surrounding sentence matters.

If the subject is a person or team, should often sounds like advice:

We should check the provider errors before rolling back.

If the subject is a system component, should often sounds like expected behavior:

The alert should fire when the error rate stays above 5 percent for two minutes.

This is not a grammar law. It is a strong practical pattern.

A Worked Alert Trace

Let us make the alert example inspectable.

The service tracks payment attempts every minute.

Now read the sentence again:

The alert should fire before users notice.

That sentence is a plain-language expectation. It says what the alert is for.

But a reviewer may need something more exact:

The alert should fire when the payment error rate stays above 5 percent for two minutes.

This is better. It still uses should, but the expected behavior is now visible.

If the alert policy is a required production rule, use must:

The payment error alert must fire within five minutes when the error rate stays above 5 percent for two consecutive minutes.

Now the sentence is a requirement. A team can test it. A runbook can check it. An incident review can ask whether it happened.

So the path is:

Plain expectation:
The alert should fire before users notice.

More precise expectation:
The alert should fire when the payment error rate stays above 5 percent for two minutes.

Hard requirement:
The payment error alert must fire within five minutes when the error rate stays above 5 percent for two consecutive minutes.

Should is not worse than must. It is doing a different job.

Where the Naive Idea Breaks

The naive idea is:

should = must, but more polite

Sometimes that is close enough in casual conversation, but it breaks in technical writing.

If a pull request says:

The API should reject invalid tokens.

What does that mean?

It could mean:

• "I recommend that the API reject invalid tokens."
• "I expect the API to reject invalid tokens."
• "The API is required to reject invalid tokens, but I wrote it softly."

Those are not the same.

If the token behavior is part of the security contract, must is clearer:

The API must reject invalid tokens.

If you are giving advice during design review, should is fine:

The API should reject invalid tokens before it reads user data.

The sentence is still strong advice, but it is not written as a formal contract.

Check: In an API security specification, which sentence is stronger?

A. The API should reject invalid tokens.
B. The API must reject invalid tokens.

Think first, then reveal.

Answer: B is stronger. Must states a requirement. Should can be advice or expected behavior, so it may be too soft for a security contract.

Should vs Must, Have To, and Might

The track now has a useful commitment ladder.

The spike might be related to the deploy.
The alert should fire before users notice.
Every request must include an idempotency key.
We have to rotate the key before Friday.

They all help, but they do different work.

Use might when the evidence is incomplete.

Use should when you are recommending a direction or describing expected behavior.

Use must when the design has a hard rule.

Use have to when the work is required because of a deadline, policy, platform rule, or current situation.

The difference matters because the modal verb tells the reader how much confidence, duty, or authority the sentence carries.

Should Can Hide Uncertainty

Should can also mean "I expect this, but I am not fully certain."

For example:

The cache should expire within five minutes.

This may mean the TTL is configured for five minutes. It may also mean the speaker believes the cache expires in five minutes but has not checked.

If you are reporting confirmed behavior, do not hide behind should:

Confirmed:
The cache expires after five minutes.

If you are reporting an expectation that still needs verification, make that visible:

The cache should expire within five minutes, but we need to confirm the CDN setting.

This is a clean technical sentence. It gives the expectation and the uncertainty.

Check: Which sentence is best when you have not confirmed the CDN setting?

A. The cache expires after five minutes.
B. The cache should expire within five minutes, but we need to confirm the CDN setting.

Think first, then reveal.

Answer: B is better. It uses should for expected behavior and names the missing evidence.

A Review Comment Before and After

Here is a vague review comment:

Add an alert.

It is short, but it does not say what the alert should do.

Step 1: turn it into a recommendation.

We should add an alert for payment failures.

Now the reader knows the suggested action.

Step 2: name the expected behavior.

The alert should fire before users notice a payment outage.

Now the reader knows why the alert matters.

Step 3: add a measurable condition.

The alert should fire when the payment error rate stays above 5 percent for two minutes.

Now the reader can evaluate the alert.

Step 4: decide whether it is advice or a requirement.

If this is an early design review, keep should:

We should add an alert that fires when the payment error rate stays above 5 percent for two minutes.

If this is a production readiness checklist, use must:

The payment error alert must fire when the error rate stays above 5 percent for two consecutive minutes.

The grammar change tells the reader that the sentence moved from recommendation to requirement.

Tone in Code Review

Should is useful in code review because it can be firm without sounding like a command.

Compare:

Add an alert for payment failures.
We should add an alert for payment failures.

The first sentence is direct. Sometimes direct is fine, especially in a checklist or paired debugging session. But in a written review, it can sound abrupt if the reason is not visible.

The second sentence sounds more collaborative:

We should add an alert for payment failures.

It includes the reviewer in the decision. It says "this is the direction I recommend" instead of "obey this instruction."

But politeness should not make the technical claim fuzzy. A stronger review comment includes the reason:

We should add an alert for payment failures so the on-call engineer sees the issue before support tickets arrive.

Now should carries advice, and the rest of the sentence carries the technical reason.

This is the useful pattern:

We should + action + because / so + technical reason.

For example:

We should move the retry after the idempotency check so duplicate requests do not create duplicate payments.

That sentence is softer than must, but it is not vague. It gives a concrete recommendation and a concrete reason.

Common Confusions

Confusion: Should Always Means Weak

Why it is tempting:

Should is softer than must, so learners sometimes treat it as unimportant.

Better model:

Should can still be serious. It often means "this is the recommended or expected path." In design review, that can be enough to guide a change.

We should move the retry after the idempotency check.

That is not a random preference. It is technical advice.

Confusion: Should Proves the System Works

Why it is tempting:

In everyday English, people often say "it should work" when they feel confident.

Better model:

In technical English, should may hide unverified expectation. If the behavior is confirmed, say it as a fact. If it is not confirmed, name the missing evidence.

The alert should fire within two minutes, but we have not tested the paging route yet.

Confusion: Should and Have To Are the Same

Why it is tempting:

Both can point toward action.

Better model:

Should recommends or describes expected behavior. Have to says the work is required by a deadline, policy, or external situation.

We should add an alert for payment failures.
We have to rotate the key before Friday.

The first is a recommendation. The second is required work.

Practice: Choose the Strength

Pick the sentence that fits the situation.

Situation 1: You are writing an early design review.

A. We should add an alert for payment failures.
B. We have to add an alert because Friday exists.

Better: A. It is a recommendation.

Situation 2: You are writing a hard production readiness rule.

A. The alert should fire sometime.
B. The payment error alert must fire within five minutes when the error rate stays above 5 percent.

Better: B. The rule is measurable and strong.

Situation 3: You expect cache expiry, but you have not checked the setting.

A. The cache should expire within five minutes, but we need to confirm the CDN setting.
B. The cache expires after five minutes.

Better: A. It keeps the expectation and the missing evidence visible.

Daily Practice Lines

Repeat these three lines during the day:

The alert should fire before users notice.
We have to rotate the key before Friday.
Every request must include an idempotency key.

Then change one technical noun or condition:

alert -> dashboard -> fallback -> retry
users notice -> support tickets arrive -> the queue grows -> the error budget burns

Keep the sentence small. Should is most useful when the recommendation or expected behavior is easy to see.

Resources

• [ARTICLE] Cambridge Dictionary Grammar: Should - Use it to compare advice, expectation, and obligation in standard English.
• [ARTICLE] Microsoft Writing Style Guide - Use it for clear technical wording and reader-friendly sentence choices.
• [ARTICLE] Google SRE Book: Monitoring Distributed Systems - Use it as technical context for alert behavior, user impact, and actionable monitoring language.

Key Takeaways

• Use should for recommendations and expected behavior, not for hard rules that need must.
• Should can be serious, but it is softer than must and different from have to.
• If should hides uncertainty, add the missing evidence: The cache should expire within five minutes, but we need to confirm the CDN setting.