DEV Community: Mike Chen

Building empathy as a software developer

Mike Chen — Tue, 02 Jun 2020 20:37:07 +0000

Software developers who aren’t familiar with the name Linus Torvalds are almost certainly familiar with his work. He’s widely regarded as one of the most prolific software developers in the world due to his authorship of the Linux kernel and Git, two of the most important projects in modern software and computing.

Unfortunately, he is also well-known for his abusive language towards colleagues. In September 2018, Torvalds announced that he is taking a break from his leadership of the Linux project. In an apology email to fellow maintainers, he mentioned that he will “get some assistance on how to understand people’s emotions and respond appropriately.”

Torvalds’s behavior fuels long-standing stereotypes that leads to questions on social media such as “Why are most programmers weird? They just seem to not have any social skills.” and “Why does programming have so many negative stereotypes associated with it?”. If you look at most of the negative images surrounding software developer stereotypes (antisocial, overly technical, condescending), many of the bad qualities stem from a lack of empathy.

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 develop this vital quality.

From my years working at major Silicon Valley tech companies as a software developer, I observed empathy to be among most underrated and important skills. Here’s what empathy might look like in your career as an engineer:

Empathy for other engineers

XKCD // CC BY-NC 2.5

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 commit code that we're not proud of — maybe an impending deadline or working with a rough API made you do some questionable things. 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

XKCD // CC BY-NC 2.5

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:

You’re a user in a developing country that pays for data by the megabyte
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
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.

4 tips for increasing your programming productivity

Mike Chen — Tue, 20 Nov 2018 17:47:02 +0000

Give me six hours to chop down a tree and I will spend the first four sharpening the axe. Abraham Lincoln

I once stood over my coworker's shoulder as we were working on an issue together and watched him use ssh to log onto our production server, observing that it took a full 2 minutes to connect. I estimated that he used ssh close to 15-20 times per day, so waiting minutes for an operation that should take seconds seemed enormously wasteful. I can't imagine having a non-trivial amount of my work day consisting of waiting for ssh to connect to other machines. It took me about 45 seconds of Googling to come up with a fix for him. When I asked him why he didn't look into it at all, he told me it didn't really bother him.

I was a little shocked by this episode at the time as I never would've put up with that, but over the course of my career, I've gotten the sense that streamlining one's workflow is a relatively uncommon thing to do. I've had many other coworkers who are also willing to tolerate the most horrible inefficiencies.

Don't be these dudes.

Hakan Forss // CC-BY-NC-SA 4.0 // Source

As with any job, programming can be quite repetitive at times. You'll find yourself typing the same commands over and over or copying and pasting a bunch of stuff from one place to another. Great news though, because the machine sitting in front of you is actually tremendous at doing menial and repetitive tasks! Leveraging this ability is a fairly underrated but critical part of maximizing your output.

Carefully investing in optimizing your workflow can have a huge payoff over the course of your career. Tiny inefficiencies that manifest over and over again throughout your days and weeks add up, wasting valuable time and keystrokes that you could be putting towards building stuff instead. Having a reputation as a fast web developer can be a major selling point for you in your career, and your teammates will really appreciate your ability to churn out work.

The best part is that unlike many other aspects of programming, being faster than the average developer isn't all that difficult, but you do need to be deliberate about it. Here are a few key things to focus on.

1. Don't multitask

There have been a lot of articles and studies in the past few years about how brutal multitasking is for your brain. I used to attempt to watch TV while I programmed and I noticed a huge improvement in my productivity after I stopped. I would argue that interruptions are especially hard on programmers due to the amount of abstract thinking involved:

If you multitask, you do this to yourself dozens of times per day.

Programmer, Interrupted // CC-BY-NC-ND 2.5 // Source

This isn't a self-help blog where you'd normally find this sort of generic life advice, so I'll keep it short and just mention a few things that have particularly helped me in this area.

Putting my phone on Do Not Disturb
Using noise cancelling headphones
Closing all my email/IM tabs
Practicing the Pomodoro Technique

You'll do yourself a huge favor if you learn how to stay focused and get in the zone. A bonus is that your enjoyment will typically increase right along with your productivity.

2. Learn your code editor really, really well

What percentage of time do you you spend in your code editor when you're programming? It's pretty high, no? Why not invest some time to learn how to use that time as best as you can? A lot of developers I've seen either use what essentially amounts to a colorful version of Notepad or they use a really powerful editor as if it were a colorful version of Notepad.

I assume you made it this far in this post because you are serious about getting better, so if this describes you, I'd advise you to consider that using a powerful editor really does matter. Imagine you're a carpenter and are passionate about improving your skills. Would you buy the first $10 set of tools that you see at Walmart and stick with that your whole career? Or would you do some research and be willing to invest in the best tools possible for the job?

Good code editors make your life much easier by automating mundane things like indentation, refactoring, autocompletion, and other repetitive tasks. If no one has ever written at least a short book about your editor, you could probably do better. I don't really care which editor in particular you use, just that you choose one that has solid functionality and spend some time into understanding the power user functions. If you're still using a crappy editor, here are a few I'd recommend out of my limited knowledge of the current code editor landscape:

Vim - Shameless plug for my editor of choice. I can easily understand that it's not for everyone: none of the buttons do what you think they will and it has the steepest learning curve out of basically any programming-related skill I've developed. When I decided to use it I experienced what I can only describe as a "total loss" of productivity at first. But I love it because of how customizable and lightweight it is, how it makes me feel like a hacker, and the lack of need to move my hand to the mouse for huge chunks of my day. It's also built-in to your terminal, so using it while ssh-ed works just as well as locally, which is not the case for graphical editors. It’s not only free, it’s basically pre-installed on every computer you're going to come in contact with!
Visual Studio Code - Open-sourced by Microsoft team, VSCode has become almost a default editor among my peers. With a rich plugin ecosystem that seems particularly suited to the JavaScript community, it’s an attractive option for frontend developers. I’ve even considered switching to it from Vim, which for those who know me personally is saying a lot.
Atom - Built by the GitHub team, Atom is also relatively new. It's similar in functionality, customizability, and style to VSCode. It generated a lot of buzz and a substantial community after its release, but I’ve heard it suffers from performance issues.
Sublime Text - Becoming more of a “classic” editor these days as people move on to the newer editors on this list. It's plugin-friendly and extensible, so there is plenty of depth there as well. It's $70 to buy, but most developers I know just ignore the occasional pop-up prompting them to purchase it (support your developers please!).

Your code editor is easily the single most important tool that you use to craft code. Don't neglect it.

3. Embrace the command line

If you use Windows, I'm not sure how much this section applies to you. Feel free to move on to the next!

Your mileage may vary the most with this tip, since it's impossible for me to speak generally about everyone's workflow, but you likely spend at least part of each day on the command line starting task runners, creating and moving files and folders, installing packages and tools, and perhaps dealing with version control. I'll speak generally here and write another post on specifics, but there are two basic things that you can do to make the most of your time on the command line:

Know what tools are out there

At my first job, I was tasked with resizing a bunch of images to thumbnail versions. I naively started doing this by hand, before my mentor promptly blew my mind by telling me about ImageMagick, which allowed me to batch resize an entire directory of images with a single command. It amazed me to learn that there was a command line tool for doing image manipulation.

If you've been avoiding getting too deep into command line because of its obscure syntax and verbose documentation, you might be missing out on a whole host of tools that can make your day-to-day tasks easier. It's hard to come up with generic examples, so I'll offer some specific ones:

curl -I [some-url] will allow you to see the headers of a webpage, which is particularly useful if you want to see the status code or redirect location for a particular URL. Browsers generally offer this information but it's faster just to see it from the shell rather than opening up your browser, entering the URL in the address bar, opening the DevTools panel, clicking on the correct tab, and parsing the information in the pane to find the headers.
If you work with raw data, you can see the sorted data by typing sort [filename], or sort it and look for lines matching a pattern using sort [filename] | grep [pattern]. This can be faster than doing something similar in your text editor or some other GUI program.

These are just a few of many things you can do with the shell. I'll discuss a few more of the utilities and ways to combine them that I find useful in my follow-up post, but if you're interested in this topic, bash cookbook is a great resource for understanding what's possible with the command line.

Leveraging aliases and custom functions to type less

I use git, so I type git status (shows what's changed in a git repository) about a hundred times per day, so it was life-changing when I discovered aliases. This simple line in one of my startup files:

alias g="git status"

which allows me to just type g to mean git status, shaves 9 keystrokes off this command. This simple alias saved me hundreds of keystrokes per day and countless keystrokes over the course of my career. And it only took me a one-time investment of 10 seconds to create it!

Even if your time on the command line is limited, start paying attention to all the repetitive typing you do, and work to eliminate it as much as possible.

4. Always be automating

Commute time is a critical factor when considering where to live, so when my wife and I would look for apartments I would always copy and paste the addresses into Google Maps and get directions to our respective workplaces to see the travel times. This was incredibly annoying to do for the volume of apartments we were looking at. I did a bit of research and wrote a tiny app that takes a few addresses as input and uses the Google Maps Distance Matrix API to output our travel times from those addresses. I've gotten a ton of mileage (pun intended!) out of this app since I now use it every time I look for housing.

This example was from my personal life but there are many situations in which an automation mindset can come in handy for you at your job. A PM might need you to input a few thousand rows from an Excel document into a database that doesn't have a good upload function. You might need to manipulate a hundred files in a particular way that is too complex for your text editor to handle. If you're attentive to what the non-technical people on your team are up to, you'll find a lot of repetition in their tasks too. Everyone hates menial work, and you will win a LOT of favor with them if you free them from such tasks with your skills.

These automation scripts can be written in basically any popular scripting language, such as Ruby, Python, or Javascript. Learning how to write scripts like this is daunting at first and you might be tempted to resort to doing it manually, but don't give up! Like all things, you’ll improve as you keep doing it, and you'll usually see this effort result in substantial time savings.

It's definitely not advisable to automate every single repetitive task though. You'll naturally learn to analyze the cost-benefit involved for each task. If you're just starting out, I would advise erring on the side of attempting to automate, while still being considerate of your team's needs. You'll develop useful skills and I can guarantee the time invested will not be a waste. But go too far overboard and you'll end up like this:

My experience is usually more like the top panel, I swear...

Automation // CC BY-NC 2.5 // Source

If there's interest, I'm happy to do a follow-up post on the decision-making and specific skills involved.

Conclusion

The most important quality you can develop in pursuing more productivity is mindfulness. Coding is already a huge mental drain, so it takes a lot of energy to be vigilant about your overall process as well, but it's worth it. Think about how to make your computer work for you, and keep in mind the three virtues of a great programmer espoused by Larry Wall: laziness, impatience, and hubris. Work hard to build practices that make your job easier so you have more time to focus on building great things.