Tony St. Pierre

Code. Reflect. Evolve.

Day 162: The Silent Weight of Expectations

Summary

What we expect shapes how we suffer. Let go of what should happen and meet what is with clarity, calm, and control.

Show me a man whose will is always the same, no matter what happens. – Epictetus

Reflection

Expectations are quiet builders.
They shape how we write code, how we review, how we respond, and how we judge ourselves when the dust settles.

Most days, we don't even notice them.
Then something breaks. A comment hits wrong. A plan slips.
And suddenly, that invisible weight comes crashing down.

In software, expectations run deep.
This release will be smooth.
The code will be clean.
The feedback will be fair.
The sprint will stay on track.

But software lives in reality, not in planning tools.

A test fails.
Someone doesn't reply.
The estimate was wrong.
None of it is strange unless we thought it would go another way.

That's where the sting begins.
Not in the moment but in the gap between what happened and what we believed should have happened.

The Stoics saw this.
Epictetus reminded us that it's not the event itself that troubles us but how we interpret it.

A missed deadline is just a missed deadline.
Thinking it shouldn't have happened is where the pain lives.

You can write perfect specs.
Someone might still misunderstand them.
You can map your day.
But life may take another branch.

Disappointment often reveals a deeper habit. We keep trying to control what was never in our hands. A steady engineer doesn't need every merge to be flawless.
They work clearly. Expect surprises. Respond with calm.
They log what failed, learn what matters, and move on.

That's the craft of seeing your assumptions and choosing not to bow to them.

Today's Insight

You don't find peace by getting everything right.
It begins when you stop needing it to go your way.

You don't need the plan to hold.
You need the strength to meet whatever comes.

Action Steps

  1. Track what you're expecting - Start your day by writing down what you expect from your work, your team, and yourself, then revisit it at the end and notice what held, what didn't, and what that taught you.
  2. Write for what might break - Code as if the input will fail, the edge case will happen, and the system will be misused, and let your thinking reflect that same quiet resilience.
  3. Play out what could go wrong - Before a meeting, deployment, or demo, walk through what might fail, not to fear it, but to face it so you're steady if it happens.
  4. Listen to how you speak to yourself - Catch the mental scripts, such as "I should be further" or "They should know better," and then ask if they're accurate, helpful, or worth keeping.
  5. Assume less, ask more - In code and teams, assumptions fail silently, so trade them for clear questions, honest offers, and the discipline to release what isn't yours.

Consider This

What would today feel like without the weight of should?
What if you met it as it is not as you hoped it would be?