How empathy can supercharge your programming career

Picture a “software developer” in your mind. Are they a loner, laboring away by themselves in a dark room looking at a black screen with green text? Are they being condescending and curt with their teammates when forced to interact with others?

Even if you yourself are a software developer, it can be difficult to shake this perception of programmers. And even if you don’t hold this stereotype, many people do. Why is that?

I’ve become convinced over the years that empathy is one of the more underrated qualities in software development. If you look at most of the negative images surrounding software developer stereotypes (antisocial, overly technical, condescending), many of the bad qualities are empathy-related.

At a high-level, empathy is simply the ability to put yourself in the shoes of another human being, to feel their feelings and to imagine what it would be like to have their problems and their goals. With rare exceptions, we as humans are wired to feel empathy instinctively, but by being mindful of situations where empathy is important, we can all further develop this vital quality.

Empathy for other engineers

Unless you’re only engineer on your team, you’ll almost certainly be spending a lot of time communicating with other engineers in the form of technical discussions, design docs, and most of all, code reviews. Depending on the size of your team, all this interaction can easily be one of the most time-consuming parts of the job.

Be mindful that even though responding to your comments and doing code reviews for you is a part of your fellow engineers’ jobs, asking for their input is essentially asking them for their time. You’re asking not only for their time, but for them to take their mind off their project, which can be exceedingly disruptive to their day. Consequently, it makes a lot of sense to minimize the amount of time and number of back-and-forth interactions that it takes to help you out. How can you best accomplish this?

1. Be your own critic first

You’ve just finished writing some code, and you’re about to request a review. But wait, who should be the first one to review it? You!

I can’t count how many times someone has sent me a code review and there are obvious glaring issues in the first few lines of code that I read. Issues that would most certainly have been caught had they done the very thing they are asking me to do (read their code). Before you send any code review, take the time to scan through your code for clear issues. Avoiding the need for someone else to point out obvious issues in your code is one of the key ways you can be respectful of their time.

2. Anticipate your coworkers’ questions

We’ve all had to introduce perplexing code for various reasons — maybe you have an impending deadline or you don’t have the control you need over other areas of your codebase to make your code clear. This is something of a corollary to #1, but read your own code with not only a critical eye for issues, but things that will confuse the crap out of your coworkers.

Be proactive in documenting the sacrifices in code quality you’ve had to make, and why. In other words, leave comments (in the code or in the PR, however your team decides to deal with comments) with answers to questions that you know your reviewers will have.

3. Seek first to understand

It’s safe to consider it reality that other engineers in your organization are going to disagree with you. Unless you are able to get to a point where you make all your technical decisions unilaterally, you simply have to accept this fact and learn how to deal with it productively.

Earlier in my career, I would view disagreement and debate as personal attacks. Those who have worked with me know that I hold strong opinions. As I matured in my career, I realized that it’s actually quite harmful to identify with your opinions (not only about technology, but really anything) to the point that you feel attacked when someone disagrees with you. This feeling is all about ego, for which a healthy engineering culture has little room.

Nowadays I still hold strong opinions, but I try my hardest to view disagreement as an opportunity to learn from someone else. Make every effort to understand your disagreeing coworker’s point of view. Underneath the surface is likely a goal or a premise that the two of you can agree on. Ask (as non-confrontationally as possible) why they hold their belief. Do you agree with that? If not, keep asking why until you can agree on what you’re trying to accomplish, and figure out where the disagreement stems from there.

This process almost always yields a wealth of information from your coworker’s experience that you wouldn’t be able to get if you kept your disagreement at the surface level. If you work in an environment where ideas can compete openly and the best ideas win, this means the eventual outcome will be best for your team, even if it’s not your idea. That is, unless your coworkers are just dogmatic parrots repeating something they read in a blogpost somewhere on Medium, in which case I’ve never quite figured out how to deal with that and I have no idea how to help you ¯_(ツ)_/¯

4. Be positive

Programming as an industry can be regarded as one of the most critical. You’re constantly putting your work out there to be judged by your teammates. If you’re like most engineers, myself included, your code reviews will be littered with nitpicks and things you need to improve, and rarely will you find a word of encouragement. In many ways, handling this criticism is just part of the job. We want to constantly be learning, growing, and pushing ourselves towards excellence.

However, pushing others towards greatness and providing positive reinforcement are not mutually exclusive. Is your teammate killing it with this feature they’re working on? Did they clean up some part of the codebase as part of their PR that they didn’t have to? Did they slog through your 800-line code review with you? Tell them you appreciate it!

There has been plenty of research on how the ideal ratio of positive comments to criticism should be at least 5-to-1. Building trust by offering genuine praise can help constructive feedback land much more effectively. When people know you care about them, they’ll know that your criticism comes from trying to make them better rather than trying to tear them down.

Some people in this field legitimately don’t really care about stuff like this, and that’s okay — but many do. I would be even prouder to work in an industry where we all actively work to create a culture where it’s okay or even expected to encourage one another sincerely.

Empathy for other teams

You’ll invariably end up spending a lot of time with cross-functional teams as well, e.g. coordinating with design teams to provide constraints and direction for their mocks, working with product managers to understand specs, working with marketing to build a landing page, etc. When someone makes a request or asks you for something, put yourselves in the shoes of someone who doesn’t know all the terminology and details of the issue that you might. How might they want their engineer to respond?

I find that the most valuable concept during this communication is the level of detail that your audience is interested in. Avoid technical details and jargon as much as possible. It’s typically not their job to understand the details — it’s yours.

As engineers, we tend to be in the weeds of a problem, and it can indeed be hard to zoom out a bit when explaining issues to other people. Sometimes people are genuinely interested in the details, but if that’s the case then they’ll let you know. I’d recommend starting high-level and explaining more if they express interest (and always let them know that you’re willing to talk more about it).

Above all, remember that you’re all in pursuit of the same goals. Hopefully, if someone is asking something of you, it’s in service of building a better product for your users. Remember this as you communicate with the people around you.

Empathy for your users

Last and certainly not least is that you should ideally feel the pain of your users as much as possible. Our users can often be an abstraction to us, hidden away by several layers of communication (e.g. customer service -> product managers -> us). This abstraction makes sense for many reasons — imagine trying to get anything done if customers had a direct line of communication with engineers all the time. However, it’s easy to lose sight of what we’re doing when we are allowed to avoid thinking about our users for too long.

Your users are not just metrics

Imagine you deploy a bug that breaks a critical flow, e.g. downloading a spreadsheet of the data in your app, for a tiny fraction of your users, let’s say 2%. If you’re a data-driven company, you and your team might look at the metrics and see that people have stopped being able to complete this flow. You look at usage and you say “oh people weren’t using this very often, just 2% of users. We’ll get around to fixing it sometime soon, but we have other priorities now”. However, this flow might be the thing that allows these 2% of users to do their jobs, and you might have completely ruined their ability to use your product effectively in the meantime.

I know it can be impossible to put the pain of the few before the desires/needs of many, and I’m not suggesting that your team needs to completely change their approach. The point is never to forget that there are human beings behind those screens. Maybe your team’s goals will change as a result, and maybe they won’t, but you’ll be a better engineer if you keep this in mind.

Prioritizing eliminating customer pain isn’t just an abstractly good thing to do — products live and die by advocacy. If you broke this functionality and didn’t care that much, what do you think these users would say if their friends or colleagues ask them what they feel about your product?

User experience is empathy

I won’t go into this much because User Experience (UX) is an entire field and job function on its own, but it’s worth mentioning here that cultivating your empathy will also lead to a better product for your users. Our software tends to exist to make our users’ lives easier. We should all strive to make it as simple and intuitive as possible.

Remember also that your users are likely quite different from you. How could you build your product differently as you imagine some of the following scenarios:

1. You’re a user in a developing country that pays for data by the megabyte
2. You’re a sight-disabled user who can’t see color contrast well, or a mobility-constrained user who can only navigate with the keyboard
3. You’re a user who isn’t very tech-savvy and have a hard time navigating complex interactions

It can be exceedingly difficult, if not impossible, to truly put yourself in the shoes of people who are so different from you or anyone you know. That’s why a lot of these issues are often addressed by different fields such as user research and UX design. However, even if you are lucky enough to work with people in these fields, it doesn’t let you off the hook. I guarantee that your product would be better if you take responsibility for these problems as well, rather than just letting your cross-functional partners think about them.

Conclusion

This post contains just a few examples of how you can express empathy on the job. My encouragement to you, however, is to make it a mindset rather than just behavior. Throughout your day, ask yourself about how people are experiencing your work and your actions. Make a habit of thinking about others, and you’ll do your part in creating better products, a healthy workplace culture, and a rich and fulfilling career for yourself.

5 Different Ways to Declare Functions in jQuery
How to Support Mental Health at Work Place…