This is the original content I wanted to present at ApexConnect 2019 about compassionate coding – until I did my first dry-run and landed at over 20 minutes instead of the 10 of my lighning-talk slot. Fortunately, Twitter came up with the great suggestion to have a reduced talk and a follow-up blog-post, which goes into the details I had to strip out due to time.
“Compassionate Coding” is a term coined by April Wensel and really a matter close to my heart since I learned about it a bit more than a year ago. If you need more information, go check her website and follow her on Twitter – she’s the real expert and is available for workshops and talks.
So, why compassionate coding? What is it all about
Suffering in Tech
There is a lot of suffering, especially in the tech industry, but also caused by the tech industry. We can witness this suffering on several levels every day:
One of the most prominent recent examples of suffering caused by tech is probably facebook and its immoral treatment of private data, like selling phone numbers to advertisers which were meant for two-factor authentication.
Speaking of social media, studiesshow that the use of social media and most likely its optimization to keep peoples attention leads to an increased acceptance of racist and other extreme views. One study even suggests a link between the use of social media and hate crime against minorities, in this case refugees in Germany.
Last December, Gillian Brockell wrote a heartbreaking open letter to tech companies in which she asked them to stop showing her pregnancy ads after her child was stillborn.
While the personal assistants in our smartphones are able to make ironic jokes, organize our calendar and guide us anywhere we want, their answer to sentences like “I was raped” or “I was beaten up by my husband” is “I don’t know what you mean”
Suffering exists on other levels, too, even on a very personal level. Think of the language we often use in our job:
- “Luser”
- “RTFM!”
- “Too stupid to use it”
- “If you don’t get this, you have no business in coding”
- “This codebase is a nightmare”
- PEBKAC (Problem Exists Between Keyboard And Chair)
I could continue the list endlessly. There are dozens of examples for suffering in tech, even to the point where the term “nerd” is used to describe the stereotype of an unempathetic jerk.
What is compassion?
How does this relate to compassionate coding? What has compassion to do with suffering? What is compassion?
“The feeling that arises when you are confronted with another’s suffering and feel motivated to relieve that suffering.”
This is the definition of compassion by Berkeley (via April Wensel). In short, compassion is about reducing suffering and compassionate coding is about reducing suffering in tech
This definition shows that compassion consists of two aspects:
To see or notice suffering – “are confronted” – and to take action to change it – “feel motivated to relieve”.
I love how this first aspect embraces a mentality of curiosity, of constant learning and exploration, something we developers are pretty used to. We love exploring things, we are used to learn constantly and increase our knowledge about a variety of topics.
To see and be confronted with another’s suffering requires us to learn to notice suffering first. This often means walking in each other’s shoes, it means to develop a sense for how other people feel and experience situations. It also means to understand why we feel the way we do
After being confronted, compassion wants to take action – this is again very natural to developers from my experience.
Some examples:
- I see the suffering of new colleagues when they need to understand my code and take action by documenting it.
- I see the suffering of people who have to maintain my code – which can also be my future self – and take action by applying good coding practices and simple design.
- I see the suffering of my customer when facing bugs in my software and take action by establishing automated self-tests. (Oh yes, testing is compassionate!)
One step further:
- I see and understand the underlying suffering of that specific request of my customer, which helps me to take the right action and develop a fitting solution.
Where to begin with compassionate coding?
“I wanted to change the world. But I have found that the only thing one can be sure of changing is oneself.”
Aldous Huxley
It all starts with ourselves, with practicing self-compassion.
There are many situations which can cause suffering in us. Let’s assume we made a mistake and are now beating ourselves up, often using a language which is very judgmental and overall negative.
“I’m so stupid, what the hell did I think when I wrote that, this is all just bullshit.”
I don’t know how many of you know the prime directive of the agile retrospective (via April Wensel). For those who don’t, it reads quite interesting
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
This directive contains some very significant aspects:
- It assumes positive intent.
- It accepts failure as part of an ongoing journey and assumes growth and change
- It defines very clear boundaries, because it acknowledges that there are things which are not under our control like the resources available or the situation at hand.
Boundaries
Let’s look at this specific aspect of boundaries, because it is – in my opinion – a very crucial and not so obvious part of compassion.
Boundaries define our fields of responsibility. Like a fence around a garden, they define what we own, what we are responsible for and what we are not responsible for. We are responsible for what we can control.
In order to become self-compassionate, we first need to clarify what is inside and outside of our boundaries:
Can we control the situation at hand? Can we control the resources – do we own them? Maybe.
But do you know what we have absolutely no control over?
Past events and actions!
They are completely out of our control, we can’t change them and the agile prime directive embraces this fact very nicely. The past is not inside our boundaries, we can’t change it.
This does not mean that we are not responsible for the consequences of our actions but it helps us to clarify our possibilities.
What is inside our boundaries are the steps we take from the things that happened. We can own up to those actions and take over control.
Understanding our boundaries can be exceptionally relieving and is also very effective, because it helps us to focus on the things we can control and change.
When we embrace this mindset, the language in which we talk to ourselves will probably change from a judgmental to an observational tone.
Yes, we did the best we could, given the circumstances. How can we improve the situation so we are able to do differently in the future? What additional resources can be acquired? How can we improve our knowledge or skills? Which things are inside our boundaries and can be changed? Where can we ask for help when something is not inside our boundaries?
Compassion towards others
Let’s try to adapt the principles of compassion to others:
I recently had a challenging situation when Pavel, whom I like very much – and don’t worry, I asked for his permission to share this example – one of the main contributors of utPLSQL version 3, became active again after a break and wanted to contribute to the java-api.
Since I took over responsibility for the java-api a year ago, I’ve spent a lot of my free time adding new features and refactoring parts of the code.
Pavel’s suggestion was something along the lines of
“The current Java-API contains several code-smells and we should rework the whole thing”.
This did something with me. I felt a massive amount of anger and was totally unwilling to accept any suggestions at this point. I had the immense urge to go all in and justify everything I had done, push back on where he had been during the last year – you probably get it.
The question is: why?
He didn’t offend me personally or my work specifically, but he wasn’t very compassionate.
I guess most of us used the term “code-smell” in some form or other – I for sure did and was convinced to be very objective and professional by using it. But if we look closely, “code-smell” is not objective at all without additional context – it is not even clear. It’s a judgment, not an observation and most humans don’t react very well to judgments
Consider this alternative:
“If we make sure these classes are immutable we can reduce the risk of unexpected change of state. I also have some ideas how we could change the architecture to increase the usability of the public API”
I am pretty sure this wouldn’t have triggered the same reaction..
“But Samuel, you are so sensitive! You are so easily offended…
…learn to handle radical and critical feedback!”
This might be true. The thing is: it doesn’t matter.
Whether I am overly sensitive or not does not matter, it doesn’t change the way I feel. Other people might experience things differently, react differently, but that has no impact on my feelings in this situation. This is especially true in situations in which we feel attacked, where our analytical thinking is naturally oppressed.
How others take our feedback is nothing we can control. If we upset someone, we do so, no matter if we are right or if it was our intent to upset someone, or if we think our counterpart is acting overly sensitive.
If we choose not to be compassionate, we must be aware that we are often actively lowering our chances to get what we want. Compassion and kindness do not only reduce suffering, they also boost the likeliness to get what we want
So can we agree that it was all Pavel’s fault that I got angry and it’s obvious that utPLSQL’s java-api will never ever get a change anymore
Let’s talk about boundaries again.
Are my feelings inside Pavel’s boundaries? They are not. They are inside my boundaries. I am responsible for my anger. What’s not inside my boundaries are other people. We can’t control other people, we can’t choose that other people treat us the way we want. But we can choose how to react and what actions to take.
I have to admit that I’m not very good at understanding my feelings and keep calm and reflected. Being in an asynchronous conversation helped me immensely to deal with this situation, because I had time.
I found out that the thing that mainly caused my anger was not the “code-smell” but the suggestion that “we” should “rewrite the whole thing”. I noticed that I felt that my boundaries of the time I am willing to invest had been violated.
My answer – due to the extra time I could take – was something like this:
“I appreciate your motivation to contribute. However, I think I don’t get your vision, but I’m looking forward to see your implementation of the changes you have in mind.”
After understanding the cause of my suffering I could set boundaries in a way that made clear I wouldn’t invest my time into Pavel’s ideas as long as I couldn’t share his vision.
Saying “No”
We often think that compassion and kindness equals saying yes to everything. But that’s not true:
Compassion means to say “No” if we can’t say “Yes” without resentment.
Does this sound egoistic? Think about it this way:
There is so much relief when you can be sure that the person you ask for something will help you freely and without resentment, without attached debt, out of pity or in a condescending way – or just honestly say “No” or “Not now”!
That’s also the reason why being compassionate is not being fake-nice. Fake-nice can’t say no, compassion can. But it does so in a way which minimizes suffering.
What they want to forbid
When I told my best friend about that idea of compassionate coding and passed him an article by April about why it’s time to retire RTFM – a great article, I highly recommend it – his reaction was like
“Look! They want to forbid us to use RFTM, too! That’s so social justice warrior!”
I can see the suffering behind his fear – no one wants to give up on things that they’re used to and we are also very likely to repeat what we experienced ourselves. But the article doesn’t forbid anything, it just explains why the use of RTFM is probably harmful for all participants and that there are more effective alternatives to achieve the goals you usually want to achieve by using “RTFM”.
The truth is: compassionate coding won’t forbid anything, because it won’t force an opinion upon you. It’s not a political agenda, it’s not about judgment and “you are wrong”. It’s actually the opposite of dogma.
Compassionate coding might, however, educate you to notice things you did not notice in the past. It might eventually show you how some of your actions cause suffering for others or for yourself. And it will be honest about that. It might even start to change you. Which can be very scary
Empathy and compassion can be grown by practice.
Maybe, by practicing, we will begin to care for things which were not in our focus before. Maybe we will be able to make a difference so people who gave birth to a stillborn will not receive pregnancy ads. Maybe we will be able to improve the help that suffering people get from our apps. Maybe our ability to see the suffering of the world around us will encourage us to invest our energy into projects like FABE
Compassionate coding can be dangerous and scary, because it can widen our horizon and raise the urge to take action.
But I want to encourage you: Compassionate coding is not about being perfect, otherwise I would’ve given up already. It is about trying and learning, about change and curiosity.
If I caught your interest, I would love to connect with you and share experiences.
Top comments (0)