Photo by Vonecia Carswell / Unsplash

Empathy is one of those things that can help in any part of life whether it’s your family, friends, that special person and even also at work. Understanding what empathy is and how it effects people took me long time. I struggle with human interactions and I am not ashamed to admit it, so I wanted to share my experience, as to what I have found from all of it.

I am full stack javascript developer. I love code. Javascript is my favorite language and for as long as I can remember I have considered my self as a one-man-army. I get the part where you have to say this in your interviews: “I am a team player & a people person”, and I have said that. But the truth is I am not and rather I am learning as I go.

The biggest thing I have realized is throughout your experience, what will matter is the lives you have impacted. The relationships you have built. I promise you tech stacks will change and you’ll grow old eventually. Programming might not be a suitable career choice at some point for whatever reason. What will matter at the end is the relationships you’ve built along the way.

What is empathy?

Empathy is the ability to understand and share the feelings of another. It is the act of putting yourself in others’ shoes and seeing a problem from their point of view.

In my day work, I get to be a team lead and I get to be responsible for some really genuine and brilliant people. All of them are diverse and bring something unique to the table. Some are fresh in the industry others are experienced. The only way I can develop a really good and productive team who are in sync with each other and at the best of their abilities, is if I can understand their issues from their POV. Whether it is with code or something else.

What good will empathy do?

There are so many benefits of having empathy, so I’ll just state a few. The end result of it is

  • a happy team
  • a well groomed end-product
  • good work culture.

So, like many other problems we face as software engineers, we tend to solve problems by devising an algorithm. Here is “pseudo code” for empathy.

1- better understanding of your colleagues: If you understand them better., you can help them better.

2- The unsaid things: Your team might not share everything with you. Based on their body-language, tone, voice, you will have a better idea of their situation.

3- Resolving conflicts: When you understand the unsaid things, you can address them and make your team members feel heard. This is the first step of resolving a conflict.

I have always said this: the first point of solving any problem is knowing what the problem is.

4- Getting empathy back from your team: There are times when you have to be straight with the team. Maybe your team is slacking, not working effectively or maybe a deadline is closing in and you have to ask them to work overtime a bit (there are some days when the client comes first).

In such cases your team might mistrust your intentions. But if you have some inclination of their understanding behind their motivation and point of view, it becomes a bit simpler to gain their trust and convince them of your point of view.

Before you know it, you will somehow become more in tune with your team’s needs. Not a clairvoyant to be exact, but you will somehow be able to predict your team’s follow up questions and answer them better. You will also be able to understand what is holding them back from their true potential

Empathy at the workplace

It is without any doubt that empathy can help in any kind of job that involves people, and our tech industry is no exception. This is valid even if you work remotely because the messages you see in the chat room are not from bots but from actual people sitting on the other side of the computer.

One frequent situation where we can forget about empathy is during a code review, which I talk about below.

Another problem is when 2 people from different teams need to work together to solve a problem or work on a feature. This can produce an “us versus them” attitude. This can be the case if the teams are from different domains or if it’s the same team divided working from different geographic locations.

A variant of “us versus them” can be “developer versus quality assurance” or “developer versus project managers”. What happens is developers end up taking a very defensive stance against managers, and we (developers) don’t try hard enough to understand their side of story (managers/QA). Getting to know the other side would certainly help to empathize with them. If we can somehow understand what they do, why they do it, it will certainly help in building a better relationship.

Daniel Westheide has written an excellent article called “The Empathic Programmer.” Do read it at your pleasure.

Let’s start with better code reviews

Before we start off with better code reviews, it is so important to make your team realize what a “Prime Directive” is:

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.” –Norm Kerth

Once this attitude is established and realized by your team, it does 2 things: First, the person reviewing the code knows that their job is not to judge the person who wrote the code, but rather to make improvements on the code. And second, the person who is getting their code reviewed knows that the feedback they are getting is not a personal attack on them, but an opportunity for growth.

I strongly believe the only way of growing is when you get feedback.

Better shaping our words

Words, if chosen carefully, can either make this world a better place to live in or hell. It is not guns and ammo. Words are, I believe, the most dangerous weapon at our disposal. Let’s consider the following comment:

This is the wrong way to structure test, it handles way to many use cases altogether

We could instead say something like this:

I think for better readability we can divide these tests into separate modules. Here is a reference from http://some-dummy-reference/example

Another example of a more negative comment like this would be:

These 3 lines belong in a separate method.

Instead, we can tweak our words a bit and say:

What do you think of extracting these lines into a separate method, to handle calculations separately?

This gives the other person some power and makes them feel that their opinions matter and that they have a say in this matter.

It is okay to have opinions

People who know me can vouch for the fact that I argue a lot and I strongly believe in this. Being a software engineer, everything should be 0’s & 1’s. Think of yourself in The Matrix with the chosen one (Neo).

So let’s say there is a conflict about anything, perhaps deciding to go for a design pattern A rather than design pattern B, where I am in favor of the latter option. I need to come up with a reason for why I believe my suggested option will work better with the use case that is presented to us.

It is easy to accept and go with the flow, while saying NO is hard because people will argue with you about it. So you need to know why the option you support is better than the one proposed by the team. I honestly love this kind of culture where the team can have a meaningful discussion about choosing design approaches. That is what I believe engineering is all about.

Organizing Your Arguments

If the code review that you are having is about style, like tabs vs spaces or about extra white space etc, then that means your team isn’t well aware of the style guide being followed in your project. And a PR comment isn’t a valid place to have that argument.

You can maybe integrate some cool linting tools to automate this process, like EsLint. I wrote an article earlier about writing clean code called These tools will help you write clean code — check it out.

If, on the other hand, the code review comments are too high level, the commentator does have the right to clarify his opinion. But a better place to have this discussion is on a piece of paper before implementing the code itself. Final code review shouldn’t be an optimal place to discuss how to tackle the problem.

Failing to care

Another problem with code reviews is people don’t care about them (I used to be one of them, until someone wrote bad code in my code. Never again.)

I can understand. The code reviews are not the most fun part of the job. But they are the most important part. The part where it becomes really difficult is when you have a very big PR to approve — and I have put my team in that position more times then I can count. But it has been for important reasons. An ideal situation is to keep your PR as small as possible so the code review is easy and not hard on the eyes.

If a big code review needs to happen, you can let your team know before hand and do it altogether as a fun exercise. Think of it as a team building activity.

To make this problem a bit more approachable, maybe you can present the code reviews in a better way:

  • attach screenshots of before and after the PR
  • explain what the PR does and give context on the background
  • give references on your approach
  • be ready for feedback — what doesn’t break you only makes you stronger

April Wensel has a brilliant article on this called “3 Code Review Pitfalls and How to Avoid Them”.

Photo by Tom Parsons on Unsplash

So let’s promise be kind, be humble, and be the hardest working person in the room.

Wrapping up

No one is born with talent, it is all hard work. The reason someone is where they are is because they had the guts and the persistence day in and day out. If you want to be good at something you need to practice it. Empathy is like that as well. You need to practice it everyday to be good at it. Simple as that.

So let’s sum it up;

  • Put yourself in your team members’ shoes, and try to understand things from their point of view.
  • Be active in asking questions. If you see your team member down, just ask them about the issue. Asking them shows that you are invested in their well being and happiness.
  • Stop judging people. Everyone is here to work to make a good living and support themselves and their loved ones. If you get a feedback from someone, think of it as a constructive criticism and improve yourself.
  • Share the load if your team is overwhelmed. Jump in help them out. Give them an extra hand. If it is in your hands, maybe give them a day off so they can rest. This way they know that you as a team lead appreciate them for your hard work.
  • Try to learn about how to be empathetic in your free time. Personally, books have helped me a lot and there is such good content on the internet if you want to read up.
  • Be attentive and a keen listener. You don’t always have to speak. Sometimes just being there and listening helps.
  • And most of all, GIVE RESPECT! To everyone — your seniors and juniors, everyone! That includes the janitor in the same building as the CEO. Every human being deserves respect.


If you have liked this, share this with your colleagues. I love to hear your opinions. Reach me at twitter @ adeelibr