Notes on stoicism as an engineer

5 minute read

Are people in complete control of how they react to the situations they are put in? After passively reading through a few beginner books on philosophy, I found Seneca and Marcus Aurelius.

Humans aren’t naturally inclined to accept the process of death, or prepare for the worst. I have found value in some of these stoic virtues, and I have tried to embed them in my life where possible.

marcusaurelius

Stop worrying about what you can’t control

“To make the best of what is in our power, and take the rest as it occurs. He is a wise man who does not grieve for the things which he has not, but rejoices for those which he has.” Epictetus

As a junior first line support engineer at the start of my career, I realised that my ideas to improve the large organisation I was working for just weren’t going to get visibility.

Learning to stop worrying about what I can change helped me become a happier person at and outside of work.

No amount of worry or anger fixes a problem.

Practice misfortune

“It is in times of security that the spirit should be preparing itself for difficult times; while fortune is bestowing favours on, it is then the time for it to be strengthened against her rebuffs.” Seneca

Your builds are going to break. Your infrastructure will fail at some point. You will need those backups. There will be portions of your security regression tests that fail eventually.

Preparing for the worst is easy if it’s part of your thought process. If your acceptance criteria outlines the depth of your documentation, and backups and disaster recovery scenarios aren’t just “nice to haves”, you are already part way through the first hurdle and not leaving a pile of technical debt behind you.

Pair and Learn

“Take a good hard look at people’s ruling principle, especially of the wise, what they run away from and what they seek out.” Marcus Aurelius

I’ve had the fortune of working with some of the best engineers in the industry. Anytime I jump on a new project, I like to pair with engineers and developers as often as I can. I make notes on their workflows, what tools they use, which shortcuts they use, if they have any reading lists they maintain.

I’ve found myself not only enjoying working with these engineers when I pay attention to their habits, I’ve also found it easier to see things from their side and as a result, built better relationships in the team.

Not all team members interact in the same way. Sometimes they’re more than happy to share their experiences, and other times it’s easier to watch them work. Like most things, engineer-watching is something you get better at as you work with more diverse skillsets.

Cutting work down

“In practice it is the negative that’s used by the pros, those selected by evolution: chess grandmasters usually win by not losing; people become rich by not going bust (particularly when others do); religions are mostly about interdicts; the learning of life is about what to avoid. You reduce most of your personal risks of accident thanks to a small number of measures.” Nassim Nicholas Taleb

Sometimes being productive means not doing the thing you’re being asked to do. Let me clarify.

You pick up a ticket where the solution requires a process you have followed multiple times. This is toil - Avoid it.

This might not be possible, especially if the process you’re following unblocks someone, or is in the way of a production system. The idea is to reduce toil. And reducing toil means cutting out mechanisms that cause the toil in the first place.

So, start by

  • Improving alerting and monitoring
  • Defining toil as a bug
  • Calculating the time wasted on this task
  • Making toil visible to the stakeholders

So the next time you have to do this repetitive, potentially automatable task, just say no if you can.

Journal

“Keep constant watch over yourself, and most importantly, put each day up for review” Seneca

This one is simple. You need to document what you’re doing right and what you’re doing wrong. That is the only way to build proper feedback loops.

It is also the only way to prioritise correctly.

Adapt

“To be interested in the changing seasons is a happier state of mind than to be hopelessly in love with spring.” Santayana

The right kind of feedback loops don’t only make you happier and more productive, they change the way your teams work.

The best performing teams pivot naturally, and the long prioritisation sessions become shorter as the individual members synchronise.

Adapting to team dynamics is a “soft skill”. That’s a reductive term for what is one of the most important skills an engineer can have. Empathise with your team, be patient and be ready to have an open mind. You will see your productivity increase, and your work improve as a result.