I have been studying Stoicism for more than 2 years now. The more I read Seneca, Marcus Aurelius and Epictetus, the more I realize how Stoic principles can be valuable when applied to programming. This post is a quick reminder to myself when I am writing software.
- What’s the worst that can happen?
- Imagining everything that can go horribly wrong, before I write even a single line of code.
- Errors that can happen, bugs that creep in, unexpected exceptions, off-by-one errors, null-pointers, invalid inputs. Thinking on this may enforce reliable, robust code.
- The software I am working on has failed. Why?
- The codebase is a giant ball of mud, spaghetti code everywhere.
- The software project got cancelled, and all the beautiful, clean code that I wrote using TDD is thrown away.
- As you write code, silently reflect that this might be the last line of code that you might ever write. Might force you to write better code.
Trichotomy of Control
- Things over which I have complete control: Code that I write, patterns and practices that I follow, testing the code I have written
- Things over which I have no control at all: Underlying framework(.net, jvm), 3rd party libraries, Getting fired from the company
- Things over which I have some but not complete control: Customer requirements, Management, Working in a team
- After you are exposed to a luxurious lifestyle, you might lose your ability to enjoy simple things. Embrace Discomfort.
- Realizing the fact that I am coding in a programming environment and working with tools that would have been a dream world for programmers in the 80’s. Being grateful that I don’t have to write code in binary(0110101), Assembly(mov dl dh), or even C.
- I have been programming on Visual Studio/IntelliJ/IDEs for more than 5 years now, and have almost forgotten how painful it was writing big Java programs on a Notepad(or sometimes on paper!) in my first year of college, back in 2009. So, whenever I find myself complaining about Visual Studio, open Notepad and try to code without any intellisense or compile-time errors.
- Whenever I find myself complaining about C#, fire up 8086 microprocessor simulator, and write some assembly code.
- Not trying to show off how smart you are, by writing complex code when a simple solution would suffice.
- Not trying to impress anyone, by sounding clever, by showing off how much you know, by using unnecessary complex jargon.
- Writing the code as simple and readable as possible. Reading code is difficult.
- Taking pause, and reflecting on the code that I just wrote.
- Not attaching my identity to the code/software I am building. Practicing detachment.
- Not boasting/taking unnecessary pride at my work, avoiding self-serving biases.
- Learning to enjoy the fact that I am getting paid to write software, without feeling entitled to it, and without clinging to it.
Avoiding Intense Ideology
- Not getting wrapped in the latest fad/trend/framework in technology. Agile is a software development methodology, not a religion. TDD is a practice, not a rule.
- Remembering that everything I hear is an opinion, not a fact. Everything I see is a perception, not absolute reality.
- Being willing to change my mind when new facts emerge which contradict my pre-existing beliefs. e.g. Decision to stop working with Angular/Backbone/Knockout after Aurelia was released.
- Paraphrasing Marcus Aurelius: “Waste no more time arguing about what a good programmer should be. Be one.”
- Not having opinions on things that you don’t understand. Not having opinions unless you know the other side’s argument better than they do.
Having Empathy when reading/reviewing code.
- I get frustrated when reading code written by me 2-3 years ago. I also get annoyed when reading buggy code written by other people, e.g. Poorly named variables, long methods, not enough error checking, unnecessary comments, etc.
- Some techniques I am trying to use when dealing with my/others’ mistakes, which helps me maintain my sanity :
- Never assume bad intentions when stupidity will suffice.
- Never assume stupidity when ignorance will suffice.
- Never assume ignorance when forgivable error will suffice.
- Never assume error when information you hadn’t adequately accounted for will suffice.