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.