Philosophy is not about beautiful phrases, metaphors, or clever quotations. Real philosophy is an instruction manual for a happy life. If it does not help you act, make decisions, and maintain clarity of thought, it is useless.
This article was inspired by Seneca’s Letters to Lucilius. Stoicism is exactly this kind of philosophy: practical, demanding, applied. It is a framework for a happy and focused life. That is precisely why it maps so naturally onto software development.
Software development is not only about code. It is about attention, responsibility, pressure, uncertainty, and long-term thinking. Stoicism offers a mental model that helps a developer remain effective without burning out, focused without becoming rigid, and calm without slipping into indifference.
This article is an attempt to bring Stoic values directly into the daily work of a developer. Without moralising. Without mysticism. As an engineering discipline of thought.
Control as the Basis of Engineering Clarity
Stoicism begins with a fundamental distinction: there are things that depend on you, and things that do not. Everything else follows from this.
A developer does not control the market, the customer, management, deadlines, other people’s architectural decisions in legacy code, business priorities, or user behaviour. Trying to emotionally control these things leads only to frustration and burnout.
What a developer does fully control is the quality of their own code, the clarity of their decisions, their response to defects, their willingness to learn, and their honesty about the current state of the system.
Stoic thinking brings the developer back into the zone of real influence. You stop complaining about reality and start working with it. This is not resignation. It is professionalism.
Focus and the “Hats” Metaphor
One of the most practical Stoic ideas is this: at any given moment, be fully who you are right now.
At every moment, a person has a role. You can think of these roles as hats. At one moment, you are a programmer. At another, a husband. At another, a son. Problems arise not because there are many roles, but because they get mixed.
Writing code while listening to music and half-following it. Fixing a defect while constantly checking social media. Being physically at home while mentally stuck in production. This is not multitasking — it is absence.
Stoicism demands presence. If you are programming, then you are only a programmer. Not a visionary, not a philosopher, not the saviour of the project. When you switch roles, you consciously switch hats.
This focus directly improves both code quality and quality of life. Loss of focus is the source of most defects — technical and human alike.
Defects as the Normal State of Reality
A Stoic starts from the assumption that the world is imperfect. Therefore, defects are not anomalies or personal failures — they are the natural state of any system.
While working on code, a developer expects defects to appear. Understanding this, they take deliberate steps to minimise both the probability and the impact of defects: tests, small changes, clear design, feedback loops.
A mature developer is not offended by a defect. They do not treat it as an attack on their competence or self-worth. They treat it as input data.
This attitude dramatically reduces emotional noise and increases recovery speed. Stoicism here acts as an antidote to professional immaturity.
Virtue as the Quality of Action
Stoic virtue is not abstract morality. It is the quality of a concrete action performed in a concrete role. You practise virtue as a developer, not “in general”.
The four classical virtues translate into engineering practice with surprising precision.
Practical Wisdom
Practical wisdom is the ability to see reality without self-deception.
To admit that the code is complex.
To admit that a solution is temporary.
To admit that “we’ll fix it later” means technical debt.
Practical wisdom means choosing a simple solution even when it looks less impressive. Writing a test even when “it’s obvious”. Not rewriting the whole system when a local reduction of complexity is sufficient.
This is the core of engineering thinking. Without it, the other virtues turn into decoration.
Justice
Justice is correct behaviour towards other people and towards the system as a whole.
Honest code reviews without self-assertion.
Clear responsibility without shifting blame for defects.
Respect for other people’s time through readable, maintainable code.
A just developer does not write code for their present self, but for the next person who will work with it — even if they will never meet
Courage
In Stoicism, courage is not heroism and not overwork. It is the ability to act correctly despite fear.
In software development, fear is usually rational: fear of breaking something, fear of missing a deadline, fear of touching a fragile part of the system. That is why engineering courage cannot be emotional. It must be structurally supported.
When a system is covered by tests, refactoring is no longer a leap into the dark. You can change the design because you have feedback. Courage is not the absence of fear, but the fact that fear no longer dictates behaviour.
Courage is not a goal. It is a side effect. It emerges when the environment no longer punishes reasonable change. Tests, small steps, and continuous integration create conditions in which courage becomes normal rather than heroic.
Temperance
Temperance is the most underestimated virtue in IT.
It is the ability not to do unnecessary things. Not to optimise prematurely. Not to introduce a new framework “because it’s interesting”. Not to turn every task into an architectural experiment.
Temperance means stopping in time. Closing the task. Accepting that “good enough” is, in fact, good enough.
In practice, temperance is what separates a mature engineer from a talented but dangerous one.
Conclusion
Stoicism in software development is not a philosophy of endurance. It is a philosophy of engineering clarity.
Do what you are doing — and do it fully.
Control only what truly depends on you.
Treat defects without emotional noise.
Have the courage to act because you are prepared.
Practise virtue not in words, but in code and decisions.
Strip away the philosophical terminology, and a Stoic is simply an adult developer — one who does not lie to themselves and does not lose focus.
And, ultimately, that is what a practical philosophy of development really is.
