I’m Aniket Kadam. I’ve been an engineer about 5 years. In that time I’ve worked as the only developer on a team and as part of small dev teams.
The tool that’s been invaluable during my entire career, is compassion.
Now you may wonder what compassion has to do with your job if you’re a developer. Our work is all data structures and algorithms, getting what features our product managers want done, aligning with business goals.
You can begin to see the answer right there. We need to communicate with our fellow developers, we need to understand the products we’re building and why, we need clear communication with business people. Compassion is the key to effective communication.
Now you might wonder, alright, who else thinks this?
Google has a collection of studies, published under re:Work that try to discover what makes teams effective.
Think a moment, what you think that will be. What would be number 1 on this list?
It’s psychological safety
Let’s take a moment to define this since Google explicitly states that not only this is the number 1 value that matter but that it enables everything else on their list. Your team has psychological safety if team members feel safe to take risks and be vulnerable in front of each other.
It’s a measure of how freely they will ask questions if they’re in doubt, how comfortable are they expressing themselves and their ideas, without fear of being humiliated or brushed aside.
Alright, let’s say that’s not enough evidence, what other companies value psychological safety?
Microsoft
Satya Nadella Rewrites Microsoft's Code
One of Nadella’s first acts after becoming CEO, in February 2014, was to ask the company’s top executives to read Marshall Rosenberg’s Nonviolent Communication, a treatise on empathic collaboration.
So, why is Microsoft’s CEO getting people to understand how to use non-violent communication? Does he just want people to talk nicely for the heck of it? Some of you may not remember Microsoft’s difficult past, from a time when Steve Ballmer, a previous CEO, became famous for throwing chairs during meetings, but this was a combative environment for him to step into.
And what did he achieve by promoting non-violent communication?
Microsoft’s CEO has stopped infighting, restored morale, and created more than $250 billion in market value. All it took was focusing on what matters most.
Alright we’ve seen what can be achieved by a bit of compassion, let’s see the flip side of it. What happens without it.
Without Compassion
This is from the developers alliance insights report, the results of a survey of 850 people from organizations all over the world, one of the things they were looking for is, why do software projects fail.
Let’s take a look at a few of the most common reasons:
“Changing or poorly documented requirements”, “Poor team or organizational management”
“Insufficient time allocated to testing”
That’s a particularly interesting one, given how little value testing is assigned by most organizations. This is a good time to ask yourself if testing is a part of your everyday workflow or if it’s an afterthought, and what the consequences for that might be.
Looking at the rest of all the top reasons, we see that it’s all based on human interaction. The tech, that part that developers talk about so much, the 500 frameworks to be acquainted with, constitutes the least common reason for software projects to fail at dead last with 17%.
How many times have you built out a feature that your project manager requested, you get ready for a big demo day, pull it off flawlessly and the reaction you get from her is:
“Eeh, not that”
That’s the kind of impact a mismatch of communication can get you.
Why do people quit?
No one quits just because your company isn’t following the latest fad language or framework. People quit when their ideas are not heard and they feel that they can make no change to an organization.
This leads into the one of the other popular reasons why projects fail, “Developer churn and loss of key talent”.
What is your ideal team?
If you’re a senior, you might say it’s a team full entirely of all 10x developers, the best of the best, the ones you could throw into any situation and they’ll learn and pick it up.
Here’s a dirty secret of 10x performance.
10x programmers in a 0.1x environment are 1x programmers.
Conversely.
1x programmers in a 10x environment grow into 10x programmers.
Why do we care about all this? Because 10x programmers in 10x environments result in “greater than 100x” outcomes
And finally, 10x isn’t the limit.
What do you think about colleagues/applicants?
You might think:
No One:
- Wants to ask what they could do better.
- Wants to ask a question.
- Sees the big picture.
- Wants to learn because “it’s hard”.
But let’s take a moment and think about what we would do, if these were our customers?
What if your customers are bouncing off your page, or not completing their purchases, or they can’t find the item they want even though it’s clearly on your site. All they had to to was click the little menu in the top right, select filters and type in the right type electronics they were after and there it is!
We don’t blame customers. Why? Because blaming customers doesn’t get you more customers.
We ask, why?
What if we asked that of our colleagues?
We might find out,
No one wants to ask what they could do better — because they think they can’t.
No one wants to ask a question. — because you’ve created an environment where they will made to feel “they should already know” and be put down.
No one sees the big picture —when was the last time you had a town hall and explained what it was?
No one wants to learn because “it’s hard”. — because no one ever made it easy.
Care about your colleagues as much as your business cares about your customers.
One way to “build in” compassion is with code reviews.
Compassionate Code Reviews
First of all, do them. For every merge. Even for the three line ones.
Organizations that began doing code reviews for even small changes, saw a drastic drop in their error rate. [add citation from Three Code Reviews]
Machines for the mechanical corrections
Don’t use a human to do a job that could be done by a linter, a git precommit hook, or codeclimate.com which can check for copy/paste, or function length.
What is the role of humans?
The number one priority for humans, is to be kind.
You may be tempted to look at a block of code and go “That’s wrong” such an action will close off the discussion. They might listen to what you’re saying and just fix it with what you wanted, but they aren’t listening as closely anymore. Especially if this is the kind of behaviour they’ve come to expect.
You don’t want to close off the discussion.
Instead if you said “Could you explain….” the part you thought was wrong, you might learn why it had to be that way. You might learn that there’s some component of that that has to be kept while still being amended with your solution. You’ve now engaged the person and gotten them to really think about what they’re doing and what could be done better. Thus, reducing the chance that you’ll have to do it all over again some other time.
If they still haven’t gotten to that understanding you could prompt a thought with the phrase “What do you think of….” and then the solution you’re proposing. Still not closing off the conversation with an order like “do it this way”, again engaging their creative selves to understand.
Shared Ownership
One outcome of this style of code reviews, is a sense of shared ownership. With the rule that if someone writes a feature, it’s code reviewed and a bug is discovered in production, that bug is now the fault of both the author and the reviewer.
You don’t want people staking out their tiny territories in an application and saying “these functions are mine”. It’s far less satisfying to go home and say “I wrote 4 functions and some classes” than to think of as the entire product as something of yours. Its successes are your successes, its failures are your things to improve on. All code is your code and the same is true for everyone else.
This fosters a sense of community and shared success and improvements that make a job more than the bit of work you did today.
Appreciate what was done well
A code review isn’t just for finding out all the things that need improvement or modification, it can be a great chance to appreciate what was done well.
There’s always something to learn whether you’re a junior or a senior, from everyone else. When you appreciate an elegant solution, you’re encouraging people to do more of it. You could inspire them to investigate on their own the things they could improve to get their next hit of niceness.
There are more detailed suggestions on this amazing site by Vaidehi Joshi
Tone and Phrases
Before we go into this, lets remind ourselves again what we’re bothering about all this for.
People in positive work environments outperform those who work in negative ones by 10–30% — The optimistic workplace
Imagine you saying to your boss, “I could get, with the same team, 30% higher performance with no additional budget”.
Sounds like a good reason to understand how your tone can affect environments and make changes to it.
Let’s see the following phrases
Negative: Why isn’t this finished yet?
Positive: Did you run into any challenges?
Have you ever been on the way out for the day, packing up and you’re asked by a manager about your status. And that’s the only time they’ve asked all day? No one likes having that conversation.
One thing I would do when I was in charge of a commitment that involved other people, is, based on the skill levels and how likely they are to ask for help, I’d go by, maybe once every two hours and ask if they’d run into any challenges. This way I would not only be updated on their tasks, but be ready to either provide minor help and them let move on unimpeded or know early that we’d need more time because the scope was larger than I expected. This works especially well when paired with “Could I help?”
Negative: Do you need help?
Positive: Could I help?
Asking someone if they need help, can put them in a spot. They might begin to wonder “am I not capable of this? maybe I’m not good enough? do I always need help?” instead when you put the focus on yourself with “Could I help” then they merely need to think whether or not they want to take you up on this favor you’ve offered and you could have them rolling off at top speed without any self-doubt.
Double negative: This is easy , just do it this way.
Positive: One way that works for me is….
It’s ironically, easy, for us to forget the effort it took to proficient in something to the point that it feels easy for us now. If the topic you’re talking about can be difficult, never phrase it as something easy, that can just be done.
Saying something can just be done is also a really effective way to close off a conversation. Suggesting something with “One way that works for me” leaves open the possibility for change, improvement, thought. Without branding it as the one true way to do it.
Ignoring ideas.
This is a pretty big deal and something to pay particular attention to. Have you ever been in a meeting where someone suggests an idea, which gets ignored, and then 2 minutes later is restated by someone else who gets all the credit? If you’re in such a meeting and see the person being ignored, consider saying “excuse me, person x was saying something, could you tell us what it was person x?”
When you don’t do this, that person is going to be less likely to participate next time. They’re going to learn to ignore meetings, and keep their head down, and you’ll have lost a valuable voice that could’ve helped.
Avoid judgment in your tone.
It’s pretty easy to take something that should be good but make it sound condescending. A neutral “Did you run into any challenges?” could easily be made to sound like mockery with “Did you run into any challenges?”
While tone can make badly phrased orders worse, they can just as easily wreck the effect of even well phrased sentences. Be aware of how you come off.
Compassion Starts With Yourself
If you’re having a hard time being compassionate with others, it might be a sign that you aren’t being compassionate with yourself. In that case:
Acknowledge that you are already writing the best code you can write.
It doesn’t have to be the best code possible. You’re going to get there. You’re doing well and it’s already pretty good.
Improve at least a little everyday.
You don’t have to master a new book, just learn one new concept, one little idea, one small improvement to your technique everyday. You’ll be amazed with where you will have reached in 6 months. And all it takes is just a little everyday.
A lot of us might have something that we’ve been carrying around, a guilt for something we should have done or did. Something that’s pulling our focus back to the past and preventing us from seeing what we could do now.
I want you, to take a moment, close your eyes and forgive yourself.
Just do it. You don’t have to believe it for it to help.
Forgive yourself. And move on.
Now that you’ve forgiven yourself, it will be far easier to forgive others! So do just that.
Finally, begin today.
Lean in, isn’t just advice for women by Sheryl Sandberg. There are many people in tech who could benefit from leaning into their careers, taking an active interest in everything they’re doing.
You can do this by, participating in slack discussions,
attending workshops,
writing blogs,
and giving talks.
Participate in your own learning.
Tech is for Teams
You might get really far and advanced with your own learning, for instance you build out dependency injection all by yourself and rewrite all the code in your app to use it. But what happens when someone else needs to modify it and you’ve got more features to build than you can by yourself?
An effective leader grows his team to being capable enough to deal with anything side by side. And you’re going to need that to do the big things.
Here’s an (incomplete list) of people and resources that helped me put together this post and the talk. It’s always important to take help and help in return, I hope you can begin implementing these simple measures to better productivity and happier environments in your own workplaces.
@sehurlburt, @patio11, @dhh, @jasonfried, @aprilwensel, @compassioncode,@vaidehijoshi
Examples of git pre-commit hooks — Kaushik Gopal
For more in depth articles about how to practically apply compassion at work, look into the blog at CompassionateCoding.com/blog
You can reach me on Twitter at AniketSMK, I’m always open to questions about programming or anything else you’d like to talk about.
Tell me about changes you’ve managed to make in your environments.
Top comments (0)