- Core thesis: Stoicism is not a coping mechanism for the frustrations of software work but a philosophical framework that correctly identifies the sources of suffering in tech culture and provides a disciplined alternative
- The Stoic dichotomy of control — what is up to us versus what is not — applies with unusual precision to the specific anxieties of engineering work
- The strongest counterargument is that Stoicism's acceptance of what is beyond control is sometimes indistinguishable from learned helplessness
- Practical implication: adopt the Stoic framework for managing externals while maintaining the activist stance toward genuine injustice
Section 1 — The Problem
The burnout statistics in tech are well-documented and grim. Roughly 60% of software engineers report symptoms of burnout in regular surveys; developer turnover rates remain elevated; the mental health infrastructure at most tech companies is laughably inadequate relative to the intensity of the conditions. These are not small problems and they are not new. But their persistence in an industry staffed by highly educated, well-compensated, and generally self-aware workers demands explanation.
The explanation is not primarily about hours, though hours matter. It is about the specific structure of anxiety that software work generates. Software engineers work in an environment of radical uncertainty — about whether the code works, whether the system will scale, whether the product will find users, whether the company will survive, whether their skills will remain relevant. They operate within institutional structures — sprints, stand-ups, performance reviews, reorganizations — that are designed for coordination but that generate a constant low-level pressure to demonstrate value. And they work in domains of rapid change where yesterday's expertise depreciates faster than in almost any other professional field.
This is precisely the environment that Stoic philosophy was designed to address. Not because the Stoics anticipated software engineering — they did not — but because the structure of Stoic practice addresses the specific form of suffering that comes from confusing what is up to us with what is not.
Section 2 — The Argument
The central Stoic concept is the dichotomy of control, articulated most clearly by Epictetus in the Enchiridion: "Some things are in our control and others not. Things in our control are opinion, pursuit, desire, aversion, and, in a word, whatever are our own actions. Things not in our control are body, reputation, command, and, in one word, whatever are not our own actions."
Applied to software work, this distinction cuts through a great deal of habitual suffering. The quality of your thinking, the care you bring to your work, the honesty of your communication, the choices you make about what to learn and how to spend your time: these are in your control. Whether the product succeeds in the market, whether your manager recognizes your contribution, whether the company is acquired or fails, whether your skills remain relevant in two years, whether your PR gets merged without conflict: these are not fully in your control.
Most engineering anxiety is anxiety about the second category experienced as if it were the first. The engineer who cannot sleep because the product might fail is suffering about something that is not up to her in the way she imagines. The engineer who is demoralized because his work went unrecognized is suffering because he has indexed his well-being on something external to himself. The Stoic response is not indifference to outcomes — it is a reorientation of concern toward what is genuinely within one's power.
Marcus Aurelius, writing in the Meditations during his reign as emperor — a role beset by military crises, political machinations, and the deaths of multiple children — returns again and again to this reorientation: "You have power over your mind, not outside events. Realize this, and you will find strength." This is not platitude. It is the conclusion of a philosophical framework worked out over a lifetime of practice by someone operating under conditions of genuine pressure.
The specific anxieties of software engineering — about product outcomes, career trajectory, technological relevance, and institutional recognition — are almost entirely about things not fully within the engineer's control, and Stoic practice offers a disciplined method for redirecting concern toward what is genuinely up to us.
The Stoic practice of negative visualization is particularly useful for software workers. The Stoics recommended periodically contemplating worst-case scenarios — what if this project fails, what if I am laid off, what if the technology becomes obsolete — not to produce anxiety but to dissolve it. The anticipated disaster, clearly imagined, is almost always survivable. The perpetual low-level dread of the unexamined worry is far more corrosive than the clear-eyed contemplation of the actual risk.
The Stoic concept of amor fati — love of fate, or at minimum acceptance of what is — addresses the specific anguish of working in tech's volatile environment. You will ship features that get cut. You will build systems that get rewritten. You will develop expertise in technologies that get deprecated. These are not failures of judgment or effort — they are the nature of the environment. The Stoic response is not resignation but a reconfiguration of how these events are interpreted: as part of the work, not as impediments to it.
Section 3 — The Strongest Counterargument
The Stoic framework has a serious critic in the tradition of liberation philosophy: its emphasis on accepting what is beyond control can function as ideological cover for structural injustice. If workers are underpaid, overworked, or discriminated against, telling them to practice Stoic equanimity toward these conditions is not philosophical wisdom — it is quietism in the service of power.
The engineers who accepted poor working conditions because they had internalized Stoic-sounding advice about focusing on what they can control were not finding peace; they were failing to exercise the collective agency that might have improved their conditions. Virtue ethics requires not just inner disposition but also action in the world. Marcus Aurelius himself was an emperor who wielded enormous power — his Stoicism did not prevent him from governing, fighting wars, and making decisions that affected millions. The Stoicism-as-acceptance reading flattens a tradition that was always about action as much as acceptance.
There is also a psychological critique: research on locus of control suggests that belief in one's own agency is generally associated with better outcomes — psychological, professional, and health-related. The Stoic emphasis on the limits of control might, if applied naively, cultivate an external locus of control that is actually counterproductive.
Section 4 — Synthesis
The counterargument is important and should not be dismissed. The Stoic dichotomy of control is not an argument for passivity toward genuine injustice — it is a framework for distinguishing the anxiety that comes from trying to control what is genuinely not up to us from the legitimate engagement with what actually is. Organizing for better working conditions, pushing back on unreasonable demands, building the skills that enable genuine professional agency: all of these are fully compatible with Stoicism because they are actions, which are in our control.
The pathology is not Stoicism but the misapplication of Stoic language to situations where genuine agency exists. "I can't control whether I'm exploited, so I should focus on my inner response" is not Stoicism. It is the appropriation of Stoic language to rationalize inaction. Authentic Stoicism would ask: what actions are available to me here, and am I taking them with full effort and clarity? The equanimity is about the outcome of those actions, not about whether to take them.
Section 5 — Practical Implications
For software engineers and tech workers, Stoic practice translates into several concrete habits that are worth developing independently of whether you find the full philosophical framework compelling.
Distinguish clearly between what is within your control and what is not — and be honest about which is which. This sounds obvious; it is surprisingly difficult. Spend time writing out the sources of your work anxiety and asking which of them are actually up to you. The proportion that are genuinely external is usually larger than it feels.
Practice voluntary difficulty. The Stoics practiced voluntary discomfort — fasting, exposure to cold, rehearsing adversity — as a way of maintaining their indifference to it. The software equivalent might be deliberately working on problems outside your comfort zone, accepting projects that might fail, and not insulating yourself from the uncertainty that the work inherently involves.
Apply negative visualization to your career. What happens if your current technology stack becomes irrelevant in three years? What happens if your company fails? Thinking through these scenarios clearly, rather than anxiously avoiding them, usually reveals that the outcomes are survivable and that the preparations they suggest are actionable rather than paralyzing.
Finally, take the inner life seriously as a domain of craft. The Stoics treated philosophical practice as work requiring daily effort, not inspiration. The Meditations are notes Marcus wrote to himself — reminders of principles he found himself forgetting under pressure. Treating your own philosophical development with the same rigor you bring to technical learning is not self-indulgence. It is the precondition for the clarity that good engineering work requires.
— iBuidl Research Team