How learning to code made me a better listener

A few years ago, my cousin pointed out that I had started listening to half a sentence or point, and then tuning out when I thought of a response, or worse, trying to finish the person’s sentence for them. I had gotten so used to “getting the gist” and surreptitiously supplying words for non-native-English speaking managers at work that I wasn’t giving anyone the chance to make their own point, even outside the office. Though the habit started from a place of love, it was really annoying to anyone trying to have a conversation with me. I started paying more attention to my interactions with people to find patterns in when I was making either conversation blunder, and to remind myself to listen with my whole mind. Nothing in the many ways I tried to break this habit helped more than learning coding, for these reasons:

  1. Your response needs to answer the (problem) statement

If you don’t read the instructions or requirements carefully (read: listen to someone’s entire statement, question, or story), you will expend a lot of energy on a response that does not answer the question or meet the needs of the original request. Don’t waste your time or anyone else’s — pay attention when others speak, and you will be able to make more accurate, useful replies.

2. Less is more

Most developers want to use the least code possible without sacrificing robustness — often the most elegant sytax uses the fewest lines. Similar thinking applies to listening and speaking. You can give a long-winded, meandering answer and lose your audience or conversation partner, or you can think about exactly what their point was, and how to communicate that you are interested or you relate. You are then able to continue the conversation by contributing a response that is informative, helpful, empathetic, or thought-provoking. Guess which one you’re more likely to do when you don’t pay close attention to the speaker’s point?

3. You have to use the right vocabulary

While many languages share syntax elements, there are enough differences that navigating from one to the next means paying very close attention to where those variances occur. What works for Ruby won’t necessarily translate to Python, just as using a word too far above or below the listener’s level of understanding will lose your audience. Not paying attention to word choice and tone when listening can cause your audience to reject, take offense to, or misunderstand your reply.


Coding helped me step back and reevaluate how I approached conversations, which allowed me to make deeper connections with my network. While I’m not necessarily advocating a coding session next time you’re preparing for a big pitch or meeting (though there are lots of free sites like codeacademy.com, and freecodecamp.com if you’d like to try it!), keeping these points in mind can makes an enormous difference in how you listen and read your audience.