☀️ Hello!
I’m really excited to publish this article to you my readers. This is the second in a series examining the complex emotional layers of software code reviews and how you and your team can practice mindfulness to improve your relational dynamics. Even though this is an overview of a very complex and important topic, it provides very concrete and helpful recommendations that can help you and your team feel much calmer and more confident about the implicit emotions felt during code reviews. I encourage you to use it as a starting point to begin learning about it and then go much deeper with the plethora of other online resources.
I asked my friend and former Canonical colleague Andrew McLeod to write the second part in this series. Andrew is an incredibly wise and experienced engineer exploring the intersection of mindfulness and technology. Currently, Andrew designs and creates software infrastructure systems for his clients. And when he’s not doing that, he’s coaching engineers and friends on mindfulness and applying it into their daily lives.
If you missed part 1 of the series, I highly recommend reading it first.
Redefining the problem with code reviews
Mindfulness is a word that has perhaps been overused or misused recently. It’s part of the wellness trend that we see being implemented in businesses - sometimes with genuine compassionate intent, and other times to tick a box somewhere for HR, B Corp certifications and the like.
We can look up the definition of mindfulness ourselves, but the first question I want to ask is “what is the problem being solved here?” and the problem is, fortunately easily, unmindful code reviews.
First let's consider how much your team or company cares about code reviews. Let’s be mindful of how we feel about them. That means let's be very honest with ourselves. Are code reviews on our team something that happen purely because that's the process we’re supposed to follow?
“You must have your PR approved before you can merge it.”
But we’ve all seen situations where our PR’s aren't read before they’re approved. So, if we are mindful of our own approach to PRs, and our team’s approach, we can notice:
Are we happy with it? Does it make us uncomfortable? Is the ONLY reason we do this because of process?
By asking these questions and noticing how we feel (in our bodies), about the answers, we can see if we need to continue being mindful.
Subscribe to the Relational Technologist newsletter so you don’t miss any future software engineering career insights, technical software guides and training/workshop opportunities.
Noticing more
Wait, what? How I feel in my body? In some sense mindfulness might be a slight mistranslation from the original Pali word Sati - retention of mindfulness or awareness. The problem is that we don’t just want to be “aware of the mind.” We want to be aware of all things that the mind can be aware of.
When each of us receives information, it is processed by multiple different biological systems within our physical bodies - different brain regions evaluate the information based on different needs, and different physical systems play a role in this processing as well. If you google “CEOs and gut instinct,” you will find a plethora of articles talking about how successful CEOs listen to their gut. This literally means paying attention to the sensations in and around your stomach. We also have physical reactions to emotional situations which can be felt in the chest, and similarly, communication-related processing often becomes perceptible in the throat area in many tangible ways. So we might even want to consider this as bodifullness - being aware of the information we receive, and how different parts of our brain and bodies are responding to every piece of information.
An example of noticing more
To make this a bit more tangible, say for example, someone might offer us a free vacation and our emotional response might be positive, our mental response might be to start thinking about what to pack, and our gut response might be something more along the lines of “this seems suspicious.” If we are aware of all of our different body and mind outputs, we can use them to more effectively synthesise a decision from all of our different processing systems.
Each of us do this all the time without really paying close attention - unless you’re counting calories, you don’t choose your meal with your intellect, you use other parts of your body to inform your choice subconsciously. Similarly, when making a major purchase such as a house, we may have a list of “intellectual” items (the price, number of rooms, etc.), but more often than not, a house is purchased because it “feels right.” We don’t have to listen to any one output in particular - we get to choose.
Application to code reviews
So now that we have an idea of how to practically apply mindfulness in a situation, let’s test it out on a code review.
In a non-mindful scenario, we see a PR from Kevin. Two weeks ago, Kevin said something to you that you took offense to and you never cleared it up. Now you’re looking at his PR, and your irritation is being transferred from the previous incident to the PR. This PR is irritating you think. What a dumb PR. Why did he do THAT? No, I’m going to push back on this PR with all this irritation. You comment on a line of code that may or may not really require adjustment and your words come across as being irritated. Kevin reads your comments and he feels irritated. He never realised he offended you in the previous incident, and not being particularly mindful, he assumes it's just a problem you have with his code. In fact, Kevin is a new developer and doesn’t have a lot of confidence, so he assumes your review is a personal judgement on his software development ability. Kevin feels irritated and upset.
Let's apply the light of mindfulness to this example.
You see Kevin’s PR and you notice you feel irritation in your body. You allow the irritation to be there while holding your attention on it momentarily, and the memory of the offensive incident comes into your mind. You feel that the irritation arose then. Now you’re in a position where you can choose your course of action. You read the PR and notice a small mistake, but you can comment on it without adding irritation. You also choose to go and tell Kevin about the offense he caused you and try to resolve the situation. Kevin offers you an apology and you feel better. Now you’re able to be more clear emotionally - you discuss the small issue in his PR, he fixes it and you move on. It’s likely that Kevin feels better at this point as well and your applying mindfulness grew the quality of your working relationship with Kevin.
Why does this matter to me?
This may seem like a little bit of a morning cartoon-style story with morals and values and ethics, but really it’s up to you what moral and ethical codes you apply in your mindfulness. You don’t have to go make friends with Kevin, but, you do want to work on a team that performs optimally. Why? Because then you don’t have to carry all the weight, work gets done quicker which makes everyone on the team look good, you generally have better connection with your teammates, and you enjoy the work you do. You can use mindfulness to be aware of how your moral and ethical attitudes affect your teamwork.
I don’t want anyone to think this is “all be happy and love everyone and everything will be good” kind of ideal - this isn’t a realistic ideal. There will be disagreements, arguments and perhaps fights. With mindfulness, we can deal with challenging relational dynamics more effectively and stop them hanging around and creating a bad atmosphere. We can limit the impact of hard emotional realties which nobody is immune from experiencing.
Sometimes, someone will submit a PR that is technically not great without mindfulness, we may respond with shock or astonishment and just react. We may immediately berate the proposer of the review, laugh at them, or whatever automatically comes up. But remember, if we want an effective code base, we need an effective team to cooperate to create one. You won’t get a large system, composed of many small moving parts, made well by a team of people who can’t communicate effectively with each other.
So in a situation where we receive a bad code review, we can apply mindfulness to how we initially feel about it (is it purely for technical reasons that this seems like bad code?), our feelings about the proposer (did we recently have a disagreement?), and why you believe it needs improving.
Remember bad code (we all have it) you may have submitted once somewhere earlier (or last week) in your career. Code is in a way an expression of who we are - at least technically - as developers. If someone says something bad about your code, you might very well take that personally. We might think that in an ideal world we would never take anything personally, but I must disagree. Taking things personally often means we are more passionate about them, more driven to make them succeed, and more happy to own things and take responsibility. Our job is to remember to give ourselves a break as often as we’re able to and to give the same to others. This is a skill that can be practiced as part of mindfulness.
So now we can be aware of whether code reviews are taken seriously in our organisation (and whether it's important - if we are the only developer then perhaps not…), and if they’re not taken seriously, be clear in ourself on why this is a problem.
Mindful code reviews are really about human-to-human relationships.
Writing software is about humans communicating
Many developers don’t want to consider that their code has anything to do with a human relationship, because we learned coding as a very isolated and personal practice. But eventually, someone else (a human) is going to use that piece of code, and that forms a human relationship. If we have to work on a team with other developers, then we have more relationships. We may want to work alone and in isolation, and we may believe we are, but it is never actually true unless the code we’re writing just gets deleted and never used. And what developer doesn’t want their code to actually ship to at least one real user?
We all know letting bad code into a system causes more issues, tech debt and low morale, so we should be considering all potential negative effects when performing and requesting a code review.
This all might sound difficult and quite often it can be - relating to people means facing our own human-relational demons. For example, quite often it can be difficult to say how we really feel about someone or something because of how that has been received in the past. But to be able to really express novel ideas in your team, you need to not be afraid of speaking out. Note that a fear of speaking out is always an emotional issue which we can become more mindful of. We can notice our anxiety and apprehension, let it be there, and then decide to do it anyway. Mindfulness is not about ‘fixing’ something, getting rid of something, changing something. It’s about being aware of how things actually are so that we can move in reality to our next objective, rather than trying to force something onto someone else and move from one imaginary place to another.
Be mindful of your relationship to others, yourself, your code, your team and your company. And if you want some help in this for yourself or your team, feel free to book some time together to discuss.
Thanks! 🙏
If you enjoyed this guest post from Andrew McLeod, please let us know in the comments - I’ll happily ask him to write some more on the topic of mindfulness and software/tech.
As always, thank you so much for reading!
Please enjoy!