Stoicism in Tech: Coping with Criticism by Adam Piercey

Marcus Aurelius faced much criticism throughout his life, both as a man and as Emperor of Rome. For example, the Historia Augusta says:

Some maintain — and held it a fault — that he was insincere and not as guileless as he seemed, indeed not as guileless as either [Antoninus] Pius or [Lucius] Verus had been. Others accused him of encouraging the arrogance of the court by keeping his friends from general social intercourse and from banquets.

In Meditations 10.36 he even says that he expects to have many people standing by his deathbed who will be glad when he’s gone because their values conflict so deeply with his own. Indeed, in 175 AD he had to put down a civil war instigated by the usurper Avidius Cassius, supported by a small faction of senators critical of Marcus’ rule.

However, Marcus welcomed criticism.

If anyone can give me good reason to think that I am going astray in my thoughts or my actions, I will gladly change my ways. For I seek the truth, which has never caused harm to anyone; no, the person who is harmed is one who persists in his self-deception and ignorance.

Meditations, 6.21

We know that Marcus was not an autocrat but frequently sought guidance from his generals, teachers, and senators. In accord with his Stoic principles, he encouraged honesty and “plain speaking” (parrhesia) at court. Decisions about his life and his rule therefore led to discussion, dialogue, and often criticism.

The world of technology and its development has many similar challenges. Design, development, prototyping and testing all take a great deal of time and effort, and throughout these you will come to key interaction points like the peer review: a time where the goal is to show your work, invite feedback and discuss your solution. Peer reviews offer an opportunity to learn from your coworkers about the efficacy of your approach. In software development, this takes the shape of code reviews. Your code is put on display and your peers are invited to review everything from structure to syntax, as well as the actual content of your code. This can be a harrowing time for any developer, whether you are a junior or even a principal architect. Whenever there are reviews there is feedback – which can lead to conflict.

Accustom yourself not to be disregarding of what someone else has to say: as far as possible enter into the mind of the speaker.

Meditations, 6.53

Software code is very personal and, just like writing prose, can show many traits of the developer writing it. Preferences towards structure, syntax, commenting styles and favorite symbology show as patterns for how someone develops their code. A person’s time and effort are also important to remember: this is work that someone has taken the time to think about, design, develop, write and now put up for review. Personal feelings towards ownership, correctness of their solution and ego can begin to cause friction in the code review process for many developers. Simple comments from peers like “there is a spelling error here”, or questions like “why did you choose this approach” can be difficult to hear – especially in any volume. So, how do we use Stoicism to handle these situations better as developers

Interpreting Feedback

When a man has done you any wrong, immediately consider on the basis of what opinion about good or evil he did wrong.

Meditations, 7.26

One of Marcus Aurelius’ most important strategies, described in The Meditations, derives from the key Socratic-Stoic concept: “Nobody does wrong willingly.” This speaks to the fact that your peers must be doing what they think is right and speaking from a place of good intentions when providing commentary on your code. Ultimately, the power of interpretation is important to identify here – you have that power. It is entirely up to you whether you interpret these comments as positive or negative, coming from a place of ill-will or good intentions, and you can start your decision-making process from this strategic point.

As Marcus says, you should: “immediately consider on the basis of what opinion about good or evil he did wrong.” If you choose to view the feedback as constructive and positive, then you can learn and proceed. The Stoics believed that we should welcome criticism in this spirit, and that our role is to make the best use of criticism. If you begin any feedback experience with the mindset that it comes from a place of good intentions, there is a significant opportunity to learn and grow.

Questions About Your Work

That if they are doing the right thing here then there is no need for us to be annoyed. If not the right thing then it is clearly involuntary and through ignorance.

Meditations, 11.18

Questions are a vital part of the development process, and can lead to some profound discoveries in terms of solutions, efficiencies and innovation. When someone begins to ask questions about code you have put up for review, it can be common to experience trepidation. Ego gets involved during this process easily, because people want to show that they are competent, and that they are of value to their peers, management and organization. Questions are a vital part of the development process though and can lead to some profound discoveries in terms of solutions, efficiencies and innovation. So, how do we approach these questions to ensure a positive collaboration and experience during this process?

Marcus Aurelius believed that we become less upset when we remember that everyone is flawed, ourselves included. Seeing people as capable of insight but imperfect and fallible allows us to accept criticism from them in a more balanced way, neither taking it too much to heart nor dismissing it out of hand. This lets us open the floor to commentary from others with the mindset that: “If they didn’t understand what I meant with my code, it must be because they didn’t know my intention.” Here we can see an application where if someone’s view is incorrect: “…then it is clearly involuntary and through ignorance.”

Both approaches have clear links to the Stoic virtue of Justice and kinship with all of humanity, and in order to take this one step further you can begin to say to yourself: “In either situation, I am going to take the time to talk to my peer and discuss solutions.” With this approach, we can hope to turn this situation into a positive one, which not only removes our own ego but also introduces a key aspect of the development process into the environment: collaboration.

Code reviews are just one of the many kinds of peer reviews that persons working in the tech development, engineering and design world must face in their careers. It can be difficult for any developer to have to face the judgement of their peers, team and management, and with development being so intrinsically personal there is no doubt that these experiences have every opportunity to become negative ones. When we take a step back from the situation and begin to understand the intent, and the possibilities of the peer review process, there is a definite opportunity for these circumstances to become positive and productive parts of the development process.

Now, what happens when you are reviewing someone else’s code? How should you approach that?

Giving Your Own Feedback

Reviewing someone else’s code can be fraught with its own challenges though: inadvertent rudeness, dismissive behavior, domineering or even destructive attitudes are all possibilities when it comes to environments where you are asked to provide feedback to a person. How can we approach this process differently in order to prevent these situations?

You have no assurance that they are doing wrong at all, for the motives of man’s actions are not always what they seem. There is generally much to learn before any judgement can be pronounced with certainty on another’s doings.

Meditations, 11.18

As a reviewer of code, one of the first things you are going to check for is the efficacy of someone’s solution; Does it work? Does it solve the problem? These questions generally lead to the next question: “How would I have solved this problem?”. This discussion is not saying that this is an incorrect investigation style, however when one approaches the code review process from this angle, many times the next logical step is to say: “Why did they do it this way?” or even: “I don’t agree with this approach”.

Before leaping to any conclusions, remember that there can be many different approaches to developing code which still provide valid solutions. and it is best to avoid situations where you downplay the efficacy of a solution simply because it is different. Why is the approach different? What efficiencies or improvements might there be in an approach like this? These are both great questions to ask and highlight the fact that you have no assurances that there Is any wrongdoing here at all – quite the contrary, this could be a rather innovative solution! Before you pass any judgement, take the time to learn about why the person went in this direction, whether this is a valid solution, and whether there is truly anything wrong here.

…but your advice must not be ironic or critical. It should be affectionate, with no hurt feelings, not a lecture or a demonstration to impress others, but the way you would talk to someone by himself irrespective of company.

Meditations, 11.18

What happens if you do find a legitimate issue in someone’s code? How do you approach the situation in a constructive manner? One of the key practices for any developer to follow is understanding that everyone on the team is purposefully trying to do the right thing. If you then approach your feedback to that person with the mindset of “I am here to help, and I want to help you”, your points are going to be received better. Tone is always going to be important, and you should focus on a positive tone, but you should also focus on structuring your feedback in a way that provides the person being reviewed with an understanding of good intentions. You are not attempting to belittle, berate or undermine this person’s work, you are trying to help. This quote from Marcus also highlights something which many developers struggle with when providing code review feedback – the demonstration of one’s own knowledge.

High-tech, high-pressure environments inevitably lead to some form of competition between co-workers; people want to show that they are of value to both their team and the organization, and this can lead to a negative atmosphere within a feedback process. It is easy to flex one’s technical knowledge during this code review process, especially if you are a veteran developer and are an expert in the development of a project. What needs to be at the forefront here, is that the priority for any developer is good product, not simply the thought of being correct. Proving that you are right and acting in a way that is detrimental to the review process is ultimately self-defeating, removing the mindset of a development team away from good product, and towards just being right.

That’s why the Stoics described their ideal as cosmopolitanism, or being “citizens of the universe” – a phrase attributed to both Socrates and Diogenes the Cynic. Stoic ethics involves cultivating a this natural affection toward other people in accord with virtues like justice, fairness and kindness.

Donald Robertson, How to Think Like a Roman Emperor, pg.41

Peer reviews are a never-ending process whenever we are working in engineering, development, design or research. As much as there is difficulty when having one’s own work reviewed, there is even more added difficulty when you are the one doing the reviewing. Feedback that you might give has the potential to support or discourage someone’s development style, and ensuring that you are on the positive end of that spectrum is not always going to be easy. Focusing on the mindset that someone is first trying to do the right thing, that you need to make sure that you understand their approach before making a judgement, and that your advice should be of a helpful tone is a great start towards that goal.

Adam Piercey is an Engineering Technologist living in Toronto, Ontario, Canada. He is currently in senior management in the world of biometric security, and has previously worked in the green energy and medical device industries. Adam has been implementing Stoic practice into his career for the last 5 years, and is a member of a small Stoic community calling themselves The Stoic Avengers, in Toronto.