What we control and what we don't
How I apply modern stoicism to the decisions, constraints, and frustrations of my day-to-day work in software engineering.
I have been interested in modern stoicism for a long time. My brother taught me how to apply some of its basic principles. But recently I started spending more time with it and thinking about how to apply it to my day-to-day work.
Software engineering gives you plenty of opportunities to practise this. You make decisions with incomplete information, work within constraints you didn’t choose, and depend on people whose priorities may be different from yours. These are the three ideas I keep coming back to.
Perception: What we control and what we don’t
The first thing I try to do is separate the problem itself from my frustration with it. That gets harder when I am expected to deliver something but don’t have everything I need to do it.
Say you need to build a reporting model that preserves the history of records, including records that are later deleted from the source. The reports need to show what the data looked like at an earlier point in time. The budget is tight, so you also need to keep storage and processing costs low.
The source uses hard deletes. Once a record is deleted, it is gone from the database; your next extract cannot retrieve it. You could capture changes as they happen, but you don’t have the access needed to set that up. Another option is to take regular snapshots and keep those copies in the warehouse. That adds cost, and you can still miss a record that is created and deleted between snapshots.
This gives you a specific trade-off to explain: with the access you have, keeping periodic copies costs more and still cannot guarantee a complete history. You can estimate that cost, explain which changes might be missed, and ask the people using the reports whether those gaps are acceptable. You can also ask the source team what would be needed to get access to change data capture.
You are responsible for making those options clear and recommending an approach. You can influence the decision through the quality of your work and the way you communicate it. But you cannot guarantee that the budget will increase, that access will be granted, or that everyone will accept the same compromise.
For me, that is the useful distinction. If there is something I haven’t checked or explained properly, I still have work to do. If I have done that work and am waiting for someone else’s decision, carrying the disagreement around for the rest of the day won’t resolve it. I want to put my energy into the next thing I can actually move forward.
Action: Try the opposite
In that same example, it is easy to keep trying to make the original design work. You have already spent time on it, and you can see how it would work if you had the access or budget you need.
Try starting from the other end. What does the report actually need? Does it need every historical change, or only the state of the data at particular intervals? Could a smaller part of the source be enough? Would a different update frequency still be useful?
The answers might lead you to a simpler model. They might also confirm that the original requirement needs more budget. Either way, you have something concrete to discuss.
For me, trying the opposite means being willing to question the approach I have become attached to. The objective is to make the reporting useful. The pipeline is one way of getting there, and it should be open to change.
Will: Don’t get mad. Help
It is frustrating when a constraint comes from another team, especially when you are the one expected to deliver. You have explained what you need, and the answer is still no.
That frustration can easily shape the next conversation. You start explaining why their decision makes your job harder, and spend less time finding out what makes the request difficult for them.
Help move the problem forward. Ask what would be needed to give you access, make the request more specific, or bring an alternative they can evaluate. If the constraint stays, explain what you can deliver within it and where the gaps will be. You still need to be honest about those gaps.
I don’t think the aim is to never get frustrated. I want to get better at noticing it before it decides how I speak to someone. There is a shared problem to solve, and I want my next conversation to help.
Honestly, I think you could take useful ideas from other schools of thought too. Stoicism is the one I have been spending time with, and what I like about it is how often I can bring it back to an ordinary working day.
Understand the problem, question your approach, and help the people involved. Do the best work you can with what is available. When a decision is out of your hands, let yourself put it down until there is something useful you can do about it.