.png){kind=logo}
No matter how skilled a developer may be, they can never be a team player if they lack empathy.
But why does empathy even matter?
Well, intelligence is something we are all too familiar with. And IQ is a measure of intelligence relative to the average human being. But when it comes to team building, IQ is just another basic skill.
What really differentiates one from the other is their soft skills. Because what it takes to be an active member in the team boils down to EQ — which is as important as IQ today.
Your EQ—or emotional quotient—can be a measure of how much impact your soft skills have on yourself as well as on the emotions of others.
For instance, if a person is exceptionally fluent in communication but sounds rude when they speak, then it could be a case of low EQ, especially in comparison to a person who may be unable to compose proper sentences but still comes across as pleasant.
Technically, the human body is wired to feel and respond to emotions. A person’s environment influences their emotions and emotions in turn influence how a person perceives their environment. It’s all a cycle of the domino effect emotions can have.
That’s why it’s so important to always have a finger on the emotional pulse of the people around you—which could simply be having empathy for everyone around.
Like Andrea Goulet says, defining empathy is like trying to nail Jell-O to the wall. Despite its definition being as deep as the ocean, we need to remember that it’s just water. Empathy, after all, is just the capacity to understand and reciprocate others’ emotions.
In our context, practical empathy can be understanding how others react to a particular situation and accounting for the fact that they don’t have the same IQ or EQ levels.
For most developers, empathy can seem like a distant concern. Since we all know machines very well, we understand humans less.
But this is where we fail.
Because empathy driven development is the shot a software developer has at becoming the wisest and smartest one in the room.
After all, with empathy, you don’t just feel but also share cognition with others. In software engineering and the scope for problem solving it brings, one doesn’t just work as a robot bound to its requirements.
One needs to have second thoughts, question things, and empathize with their colleagues and users.
Empathy binds people with different skill sets together and brings them all on the same page. That’s why UX designers and engineers and salespeople can all work together with a product manager to build something truly impactful.
The basic task of every developer is programming. They input steps and commands which the machines decode into tasks. But in a non-ideal world, where we work as a team, the code is written to be visible to more than just a person and one machine.
Without empathy, there is nothing separating code from ancient scripts and new team members are as good as archaeologists.
Writing clean code is not the same as writing code with empathy, for the latter is like writing a time capsule to yourself. Years later, empathetic code will still hold good. But if you find yourself annoyed (or even disgusted) by it, then you probably see the difference for yourself.
Here are the top best practices I recommend to get you started with writing code that can empathize with its stakeholders:
Avoid syntactically sugar codes if they aren’t widely appreciated. After all, that’s proof that only you like or understand that particular syntax.
Let your code communicate to the people who are likely to look at it. Meaningful comments convey the context behind your approach.
If something looks messy, modify it to become easily understandable, even if it was done by someone else! After all, empathy doesn’t come from swapping blame.
Avoid ghostly abstractions—ones that appear with no or next to no context.
Good code is the amalgamation of multiple good perspectives. So take a moment before you write it and just discuss it. This may just be the least painstaking way to save yourself large chunks of time and effort.
Sure, sometimes the code you review could be buggy. But that doesn’t mean the coders behind it lack skills. The requirements around the project play a role too. So take all of that into context before you review a piece of code.
Don’t write code to outsmart the people reviewing the code. Reserve the wow factor solely for the user. For the reviewers, try your best to enlighten and engage them.
Appreciate and welcome new ideas and codes with enthusiasm. They could bring perspective to your project that it was previously lacking.
Every developer is unique. So it follows that every piece of code is just as unique. Try to understand their styles of coding and how they handle daily tasks.
You can still learn from a junior developer. Don’t make the mistake of thinking otherwise.
Empathy is crucial for great development. As a coder, don’t just limit yourself to compiling alphanumeric statements! Network, grow, and work with the team while being in the team itself. There is so much more to coding than what we see. This article intended to get you to pause and reflect on things you might be missing out on. So give it a try.
After all, writing empathetic code has been standard practice for us at Mutual Mobile. Perhaps that’s why we have been able to juggle projects from large Fortune 500s and still have the bandwidth to work with cutting edge startups.
Empathetic code makes life easy. And a chat with one of our team members could make yours easier too. Reach out to us over here to get the conversation started. Maybe that’s the only thing between you and your next big idea.
Happy coding!
Biswa is an engineer who likes reading, singing, and playing the guitar. Some of his favorite topics to discuss include technology, finance, philosophy, and weird MCU theories.
More by this author
