My time at a software company has shown me how much focus there is on the new: new smartphone and laptop models, new revs, new development boards, new languages, and so on. But what about the old? I’m talking really old, like “two millennia before the Unix-Epoch†old. The Stoic philosophers Zeno of Citium, Epictetus, and Seneca spoke at length about logic, control, and truth–all terms we discuss as programmers, but with very different meanings and applications. Still, Stoic works have lasted for thousands of years. What lessons do the ancient Greeks have for an industry with an obsession for the newest, latest thing?



_Via Negativa_–The Negative Way

“All philosophy lies in two words, sustain and abstain.†–Epictetus

Via Negativa is a Latin phrase usually associated with Christian theology, but it also describes a tenet of Stoic philosophy. It means removing what is bad or unnecessary in order to focus on what is good. Um, duh. This seems completely obvious, yet it’s difficult to implement. We often look to fix problems (physical, financial, interpersonal, software, etc.) by positive action: adding more systems, rules, tracking, effort, and to-dos. This adds complication and leads to bugs, burnout, and failed New Year’s resolutions, but it’s familiar to us. The idea of fixing or improving things by taking away is counterintuitive and foreign to us. What via negativa offers us is simplicity. A real-life example of adding vs. taking way might look like treating a medical condition by adding medication (via positiva), rather than removing stressors, possible allergens, etc. (via negativa). Adding medication might be beneficial, but it also adds a host of potential side effects, as well as hard-to-predict interaction with other medications. Of course, this is a simplified example (and I’m not a doctor), but the idea still holds: Our bias toward positive action and adding things to fix problems can add unforeseen complexity and consequences. Sound familiar? The idea of _via negativa _doesn’t mean “do nothing.†Instead, it means striving toward simplicity and asking, “What can I take away?†So, how does this apply to software? More lines of code mean more bugs. Conversely, “No code is faster than no code,†as posited by software blog Coding Horror and others. The idea of simplicity crops up all over the place in software. Loose coupling in systems, called “orthogonality†in _The Pragmatic Programmer_, reduces dependency between different parts of a system. A push for reduced complexity is also seen in ideas like the Single Responsibility Principle and Separation of Concerns. The Don’t Repeat Yourself (or DRY) principle teaches that you should avoid duplication of logic, and that “every piece of knowledge must have a single, unambiguous, authoritative representation within a system.†Most of us know that simplicity is a good idea: “less is more,†“keep it simple, stupid,†etc. Simple isn’t easy, though, as we have to be cognizant of our tendency toward positive action and more.


Zeno of Citium

_Premeditation Malorum_–Negative Visualization

(Literally, “premeditation of evilsâ€)

“Begin each day by telling yourself: Today I shall be meeting with interference, ingratitude, insolence, disloyalty, ill-will, and selfishness–all of them due to the offenders’ ignorance of what is good or evil.†–Marcus Aurelius

The Stoics regularly thought, “What’s the worst that could happen?†This ranges from a daily expectation of meeting commonplace difficulty and vice, to contemplating personal catastrophes, even meditating on one’s own death. While this isn’t the kind of attitude that gets you invited to parties, the point is to be prepared, rather than surprised, if–or, let’s be honest–when bad things happen.

“What is quite unlooked for is more crushing in its effect, and unexpectedness adds to the weight of a disaster. The fact that it was unforeseen has never failed to intensify a person’s grief. This is a reason for ensuring that nothing ever takes us by surprise. We should project our thoughts ahead of us at every turn and have in mind every possible eventuality instead of only the usual course of events.†–Seneca, Letters from a Stoic

To the Stoic philosopher Epictetus, such catastrophic events were were “dispreferred indifferent,†meaning that it would be better if they didn’t happen, but if they did, well…it wouldn’t be the end of the world, and it wouldn’t overwhelm one’s strength of character. This idea is also taught in Cognitive Behavior Therapy as “de-catastrophizing.†Imagining things going wrong allows you to feel these emotions in advance, which takes some of the sting away if (or when) something bad happens. This creates psychological resilience.

Can We Get Back to Software, Please?

Phew, heavy stuff. While this might be a little too “Eeyore†for most of us, especially given the inherent optimism of most developers, preparing for the worst (and hoping for the best) is an attitude that acknowledges the realities of our job. Schedules change, bugs crop up at the most inopportune times, and so on. To be responsible consultants, we have to continually ask ourselves, “What’s the worst that could happen–and how do I prepare for it?†Test-driven development is a huge part of our culture at Atomic. We have to test the “happy path†in our code, but we also test a myriad of different ways that things could go wrong. This isn’t an afterthought–we need to imagine these scenarios at the beginning of development and design our systems to support this testing. Forcing yourself to imagine what could go wrong at the outset means that you can write your code in such a way to gracefully handle all (or almost all) that could go wrong.